Hello, On 25/04/2023 at 01:29, Adam wrote:
I installed from a thumb drive, to another thumb drive, on a computer that had an nvme drive that should not have been touched. The installer overwrote data on the nvme drive despite the target being /dev/sda. I manually mounted the installed system (the target thumb drive) on another computer, figured out what happened (ESP was empty) and fixed it so I could submit a bug report from the thumb drive that failed to install properly. This is similar to the other UEFI installation problems, but it did not install to the MBR, and it did not install any files on the correct ESP, thus is is a separate issue. The smoking gun for understanding what went wrong was in /etc/fstab, where there were two comments: # /boot was on /dev/sda2 during installation # /boot/efi was on /dev/nvme0n1p1 during installation
From the partition layout I assume you used guided partitioning with LVM (without encryption). Guided partitioning is supposed to not use any partitions outside the selected disk by calling clean_method() defined in partman-auto/lib/recipes.sh. This is what I observe with non-LVM schemes, but the two LVM schemes have issues. Here is a summary of my observations:
Guided - use the largest continuous free space calls clean_method() in partman-auto/autopartition does not run partman-efi/init.d/efi does not use existing EFI or swap partitions on other disks (good) Guided - use entire disk calls clean_method() in partman-auto/autopartition does not run partman-efi/init.d/efi does not use existing EFI or swap partitions on other disks (good) Guided - use entire disk and set up LVM does not call clean_method() runs partman-efi/init.d/efi uses existing EFI and swap partitions on other disks (bad) Guided - use entire disk and set up encrypted LVM calls clean_method() in partman-auto-crypto/autopartition-crypto runs partman-efi/init.d/efi uses existing EFI partitions on other disks (bad) does not use existing swap partitions on other disks (good)partman-efi/init.d/efi detects possible EFI partitions and sets method "efi" on them.
As you can see, the issue also affects swap partitions (and they will be reformatted with new UUIDs, which can be harmful if they are used by another system).
Note: partman-auto-lvm used to call clean_method() in lib/auto-lvm.sh but it was removed by commit cfc6797f6f561b87069160ba7c375c5b487b7c1e with code factoring.
Suggested fix is two-fold:1) Call clean_method() at the beginning of partman-auto-lvm/autopartition-lvm, as is done in partman-auto/autopartition and partman-auto-crypto/autopartition-crypto. This should solve the issue for swap partitions but is not enough for ESPs.
2) In partman-efi/init.d/efi, set method "efi" only once, as is done with swap partitions in partman-basicfilesystems/init.d/autouse_swap. I already submitted two patch versions for #1034208 "Partman may reset user's choice for ESP partitions use" as a follow-up to Steve's latest fixes for #834373 and #1033913.
Caveat: I don't know if these changes could have any negative impact on preseeded automatic partitioning.