feat(installer): ask for the target disk when the configured one is missing - #263
QuentinCazier wants to merge 3 commits into
Conversation
…issing When the disk set in securix.self.mainDisk does not exist on the machine, autoinstall-terminal now lists the unused disks, asks which one to install on and points the configured path at it with a symlink. The partitioning scripts generated by disko keep working unchanged, since they address the partitions by label and only use the disk path for partitioning. Floppy, loop and optical devices are left out, as well as disks holding a mounted filesystem such as the installer medium. Closes cloud-gouv#131 Signed-off-by: Quentin Cazier <cazierquentin@gmail.com>
Boots an installer configured for a disk that does not exist in the VM, answers the prompt and checks that the installation lands on the chosen disk. A second run must not ask again. Signed-off-by: Quentin Cazier <cazierquentin@gmail.com>
jdauphant-dinum
added
the
status: awaiting-maintainers
| testScript = '' | ||
| import textwrap | ||
|
|
||
| first_run = textwrap.dedent("""\ |
There was a problem hiding this comment.
This is not super maintainable, can the expect code be extracted into a let binding?
There was a problem hiding this comment.
Done, the expect scripts are now let bindings built by a small helper that also waits for the end of the installation.
| users.users.root.initialPassword = "test"; | ||
| fileSystems."/".device = "/dev/mapper/securix-root"; | ||
| fileSystems."/".fsType = "ext4"; | ||
| boot.loader.grub.enable = false; |
There was a problem hiding this comment.
No. These four lines were copied from idempotent-autoinstall.nix. Like that test, the previous version replaced the install step with an echo, so the target system was never built, and the test derivation was exactly the same with or without them. They are gone now that the target is a real bootable system. The same lines are still in idempotent-autoinstall.nix, I left that test alone.
rlahfa-dinum
left a comment
rlahfa-dinum
left a comment
There was a problem hiding this comment.
Looks good to me but I have a fundamental question: how does it work on the next reboot?
rlahfa-dinum
added
status: awaiting-author
The test now runs a real installation with the securix_v1 layout on the disk picked at the prompt, then boots a second VM from that disk alone and checks that root is the LUKS volume found by its partition label. This shows that the installed system does not depend on the configured disk path. The expect scripts move to let bindings, and the lines copied from the idempotent installer test are dropped since the target is now a real bootable system. Signed-off-by: Quentin Cazier <cazierquentin@gmail.com>
The installed system never looks the disk up by its path. Disko generates the fstab entries and the initrd LUKS device from the partition labels, disk-_dev_nvme0n1-ESP, -Recovery and -luks, and those labels are written on whichever disk was picked. The symlink only lives in the installer, so the disko scripts can run unchanged. I extended the test to check it. It now does a real install with the securix_v1 layout on the picked disk, then boots a second VM from that disk alone, where it shows up as /dev/vda and /dev/nvme0n1 still does not exist. The initrd waits for /dev/disk/by-partlabel/disk-_dev_nvme0n1-luks, unlocks it, and root ends up on /dev/mapper/croot backed by /dev/vda3. Two differences with a real Sécurix: the test uses systemd-boot instead of lanzaboote, and unlocks LUKS with a key file in the initrd instead of FIDO2. Neither changes how the disk is found. One side effect worth knowing: the labels keep the configured name, so a SATA disk ends up with disk-_dev_nvme0n1-* partitions. It works, but the inventory should be updated after such an install, otherwise a reinstall will ask again. |
This branch has not been deployed
3 participants
Closes #131
When
securix.self.mainDiskdoes not exist on the machine,autoinstall-terminalused to runwipefsand the disko format script on a missing path and fail, which meant rebuilding the ISO with the right disk.The installer now checks the configured disk before anything is written. When it is missing, it lists the disks that are not in use (floppy, loop and optical devices are excluded, as well as any disk holding a mounted filesystem such as the installer medium), asks which one to use with
gum choose, and creates a symlink from the configured path to the chosen disk. The disko scripts then run unchanged: they only use the disk path for partitioning and address the partitions by label, so the installed system and the partition labels are the same as with a matching configuration. The filesystem layouts and existing installations are not touched.When the configured disk exists, nothing changes.
Test
tests/autoinstall-missing-disk.nixboots an installer configured for/dev/nvme0n1in a VM that only has/dev/vdb, answers the prompt, and checks that/dev/nvme0n1points to/dev/vdb, that the partitions were created there, and that a second run does not ask again.tests/idempotent-autoinstall.nixstill passes.