| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These files should never be mixed into the same directories as source
code, since source code should be backed up by filesystem snapshot, and
these should not.
This change includes file renames in this repository and in two of its
submodules.
|
|
This material wasn't removed in the original commit removing gpg,
because it seemed to have documentary value. This commit serves
as the documentation index. Some of this functionality should be
reimplemented.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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'.
|
|
|
|
|
|
|
|
|
|
Thanks https://bbs.archlinux.org/viewtopic.php?id=94780
libncurses should change error string from 'unknown' to '$TERM is unset'!
|
|
|
|
|
|
The luks.secret is stored per block device, and any existing
/dev/mapper/samizdatcrypt is removed before we try to create
that device.
This makes it more possible to recover from a failed menu-select
from the emergency console.
|
|
Try to make menu-select slightly more robust to being run a second time
after a failed run.
|
|
When partvi writes directly to a boot medium, it shouldn't
copy part files, because these involve copying the unused
parts of the filesystems. Instead, it should create a new
filesystem on the target and copy files into it.
This change moves in that direction.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The second call to grub-install, which installs an EFI bootloader, fails on this
machine. No need to fail the whole process for that, since I am not using EFI.
|
|
fixed race condition in kpartx
fix for sfdisk kernel reload ptable failure
cleaned up some code duplication
created make keymu target
amended make clean target
|
|
These commands are available in sami:
make upgrade
make emu
make key
They use partvi.
|
|
|
|
|
|
|
|
|
