summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-06-20removed unusedgnupggnupgAndrew Cady
2023-06-19Replace resolv.conf hack with new hackAndrew Cady
We need working DNS resolution to download the firmware for two Debian wireless firmware packages. Previously this was accomplished by copying resolv.conf into the chroot, which was bad, because it leaked data about the build system into the chroot. Now the resolv.conf is bind-mounted in the chroot so it won't affect the install target root filesystem.
2023-06-18fix git submodule urlAndrew Cady
2023-06-17"make efi" targetAndrew Cady
2023-06-17remove documentary comments from partviAndrew Cady
2023-06-17fetch/extract BOOTX64.EFI before depending on itAndrew Cady
2023-06-17update submoduleAndrew Cady
2023-06-17add submodule import-grub-bootx64-efiAndrew Cady
2023-06-17"fix" efi booting with disgusting hack and out-of-repo binaryAndrew Cady
it turns out all that we need to do to make EFI booting work is to replace the BOOTX64.EFI file that is produced by GRUB's "grub-install" command with the version of that file from Ventoy's upstream source of the same file: <https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk/>. Ventoy claims that to be their source here: <https://github.com/ventoy/Ventoy/blob/master/DOC/BuildVentoyFromSource.txt> """ 5.10 UEFIinSecureBoot https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk/releases Super-UEFIinSecureBoot-Disk_minimal_v3.zip unzip it and get Super-UEFIinSecureBoot-Disk_minimal.img, extract the img by 7zip. INSTALL/EFI/BOOT/BOOTX64.EFI --> EFI/BOOT/BOOTX64.EFI SHA-256: 475552c7476ad45e42344eee8b30d44c264d200ac2468428aa86fc8795fb6e34 """ That SHA-256 matches what we have downloaded and are using. I have created a separate repo containing the code that pulls down the .zip file and extract the BOOTX64.EFI file from it. That code verifies the SHA-256 hash. It can be added as a sami.git submodule. This code is not usable without that file generated by that code. This commit should be amended with a git submodule added with that code too.
2023-06-16"make" targets for EFI boot testingAndrew Cady
2023-06-14makefile variable determines size of persist.imgAndrew Cady
2023-06-14fixup! experimental grub simplificationAndrew Cady
2023-06-13experimental grub simplificationSteven
2022-10-27Don't install submodules with 'make install'Ella Grapp
It is important than 'make key' not build the submodules unnecessarily. It would make sense to rename the current 'install' target for use as dependency, re-introduce an 'install' target that does both for manual use at the command line.
2022-01-11bump fsmgrAndrew Cady
2022-01-11ugly hack fix, not rightAndrew Cady
2022-01-10add target: make muAndrew Cady
2022-01-10switch to C ficlonerange instead of PythonAndrew Cady
2022-01-10fixup! bump fsmgr, with fixes for Debian "bullseye" releaseAndrew Cady
2022-01-10rootfs fixes & improvements; now using Debian bullseyeu
Probably breaks Debian buster, which probably won't be fixed.
2022-01-10bump fsmgr, with fixes for Debian "bullseye" releaseu
2022-01-10rootfs: update build-deps.yaml for bullseyeu
2022-01-10partvi: show grub-install runtimeu
2022-01-10Makefile: avoid mv interactive prompt with -fu
2022-01-10install grub-efi instead of grub-pcx
2022-01-10add "cleanmu" make targetx
2022-01-10remove cruftYour Name
2022-01-09drop openssh patchAndrew Cady
2022-01-09Revert "rootfs: upgrade openssh to 8.4p1-5 and now get its dependencies from ↵Andrew Cady
sid" This reverts commit a8710d9fb1e4ed2c12d406b2b7d0f1f6c1ffbc74.
2021-10-06Makefile: use apt instead of apt-get when availableAndrew Cady
2021-09-25avoid lsb_releaseu
2021-03-22bump fsmgrAndrew Cady
2021-03-13This is obsoleted by (and conflicts with) fsmgr support for apt-update: trueAndrew Cady
2021-03-13initrd: improve messagingAndrew Cady
2021-03-13make cleanerAndrew Cady
2021-03-13samizdat.patchfs.btrfs was missing dependency on samizdat.seed.btrfsAndrew Cady
2021-03-13rootfs: upgrade openssh to 8.4p1-5 and now get its dependencies from sidAndrew Cady
2021-03-13bump fsmgrAndrew Cady
2021-03-13Specify REWRITE_SOURCES_LIST=y for samizdat.btrfsAndrew Cady
This means it is always on, but there is no sid access until "apt-update" is specified true.
2021-03-13Makefile: improve core command-line interface targetsAndrew Cady
2021-03-13also generate .verity file for .patch.btrfs fileAndrew Cady
2021-03-13firstboot: do not attempt to eject samizdat medium when booting to ramAndrew Cady
2021-03-12try to fix efi boot with alternative grub-install commandefi-testAndrew Cady
2021-03-11new make targets: total-destroy and testinitrdAndrew Cady
2021-03-11initrd: umount /mnt/* before bootingAndrew Cady
2021-03-11calling umount slightly sooner is more correctAndrew Cady
2021-03-03automatically make the boot medium ejectableAndrew Cady
2021-03-02Fix to make the btrfs install method work.Andrew Cady
Just figured this out. We must change the fsuid after removing the devices, because btrfs MODIFIES the READ-ONLY SEED DEVICES to mark them unavailable after when remove them from the read-write device. When we reboot with the UNMODIFIED, IMMUTABLE seed image, btrfs cannot handle the duplicate fsuid. We detect this situation (kind of) and call btrfstune -m to change the fsuid of the /dev/mapper/samizdatcrypt single device fs. Now it just works. It would be much better to call this on the booted system on the running rootfs, but btrfs can't, so we instead call it on the initrd mount time. A more proper fix might use the partition table to mark the partition as in need of 'btrfstune -m'.
2021-03-02include btrfstune and sfdisk on initrdAndrew Cady
2021-03-02simplify samizdat-eject.shAndrew Cady
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-18 11:13:19 +0000