Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP
I used "Guided - use entire disk and set up encrypted LVM" On April 25, 2023 12:55:27 PM CDT, Pascal Hambourg wrote: >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. -- Sent from my iPod. Please excuse my brevity.
Processed: Re: Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP
Processing control commands: > tags -1 patch Bug #1034812 [installation-reports] installation-reports: Unbootable after install: UEFI installed to wrong ESP Added tag(s) patch. -- 1034812: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034812 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP
Control: tags -1 patch On 25/04/2023 at 19:55, Pascal Hambourg wrote: 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. Patch attached for the partman-auto-lvm part.From 1d6b590b418184d1f5b92126542f33c90dfda945 Mon Sep 17 00:00:00 2001 From: Pascal Hambourg Date: Thu, 27 Apr 2023 08:53:05 +0200 Subject: [PATCH] Call clean_method again The call to clean_method was lost with commit cfc6797f. As a result, if existing swap and EFI partitions on other disks were marked used (which is the default), swap partitions will be used (and get new UUIDs, which is bad if they belong to another system) and any EFI partition on another disk may be used instead of the newly created one (#1034812). This patch fixes the issue for swap partitions but fixing the issue for EFI partitions also requires a change in partman-efi (same as #1034208). --- autopartition-lvm | 3 +++ 1 file changed, 3 insertions(+) diff --git a/autopartition-lvm b/autopartition-lvm index e081beb..40026c3 100755 --- a/autopartition-lvm +++ b/autopartition-lvm @@ -5,6 +5,9 @@ devs="$*" method="lvm" +# Ensure we have no pre-existing partitions marked as swap and efi +clean_method + auto_lvm_prepare "$devs" $method || exit $? auto_lvm_perform || exit 1 -- 2.30.2
Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP
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.
Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP
Package: installation-reports Severity: normal X-Debbugs-Cc: a...@hax0rbana.org (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: USB Image version: Bullseye Date: 04/23/2023 Machine: Home built PC Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on udevdevtmpfs 39688200 3968820 0% /dev tmpfs tmpfs 799096 1360797736 1% /run /dev/mapper/thumbdrive--vg-root ext4 116178928 28347284 81883844 26% / tmpfs tmpfs 39954720 3995472 0% /dev/shm tmpfs tmpfs 51204 5116 1% /run/lock /dev/sda2 ext2481642 118611338046 26% /boot /dev/sda1 vfat52324436784486460 8% /boot/efi tmpfs tmpfs 799092 76799016 1% /run/user/1000 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [O] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[E] Comments/Problems: 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 This matches the fact that it left my nvme drive unbootable unless I manually go into the boot menu and select the nvme drive every time. Failing to do so results in a grub failure. I have also repeated this on another computer (mac mini 2019) and was able to reproduce these results, so I can confirm that it is not an issue unique to my BIOS. That left a second computer unbootable short of manually going into the boot menu and selecting the desired device on every boot. I marked this as "normal" because installing onto a thumb drive and having another disk in the computer which has an ESP is not a common use case. It may be reasonable to increase the severity considering it overwrites a disk that should not have been touched, leaving two systems unbootable (in my case: the nvme drive and the USB drive). -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u7+b1" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux thumbdrive 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] lspci -knn: 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] lspci -knn: 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] lspci -knn: 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] lspci -knn: Kernel
