Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
Pascal Hambourg wrote: > > You can run grub-install with --no-nvram to install GRUB without writing > EFI boot variables. The Debian installer also has an option for this in > expert mode. Then you can create a custom boot entry with efibootmgr. Thanks, this is very nice => I am definitely going to test adding the following to my pressed: d-i grub2/update_nvram boolean false It could help me simplify my "preseed/late_command" script that currently deletes the default EFI entry and then creates my custom one. I guess my NVRAM will also be very grateful to you:). Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
On 17/05/2024 at 13:22, Jmkr wrote: Pascal Hambourg wrote: You can set an alternative name and location by running grub-install with --bootloader-id= or with GRUB_DISTRIBUTOR= in /etc/default/grub. It also affects the directory name in the ESP. But depending on the grub package version, monolithic GRUB images (signed for secure boot) do not support being installed in another location than /EFI/debian (I have been advocating to fix this but no luck so far). Thanks for this as well as the other info you provided - it is nice to know even if I may end up not using it (as I probably want to use "/EFI/debian" directory for GRUB with just custom EFI boot entry names). You can run grub-install with --no-nvram to install GRUB without writing EFI boot variables. The Debian installer also has an option for this in expert mode. Then you can create a custom boot entry with efibootmgr.
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
Pascal Hambourg wrote: > > You can set an alternative name and location by running grub-install > with --bootloader-id= or with GRUB_DISTRIBUTOR= in > /etc/default/grub. It also affects the directory name in the ESP. But > depending on the grub package version, monolithic GRUB images (signed > for secure boot) do not support being installed in another location than > /EFI/debian (I have been advocating to fix this but no luck so far). Thanks for this as well as the other info you provided - it is nice to know even if I may end up not using it (as I probably want to use "/EFI/debian" directory for GRUB with just custom EFI boot entry names). Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
On 10/05/2024 at 00:52, Jmkr wrote: Pascal Hambourg wrote: You could just run grub-install to reinstall GRUB into the new ESP and register it in EFI boot variables. I wanted to try the manual way to learn + to create my EFI boot entry with a customized name. I think GRUB installation can only create EFI boot entry with the name "debian", or is it possible to change that? You can set an alternative name and location by running grub-install with --bootloader-id= or with GRUB_DISTRIBUTOR= in /etc/default/grub. It also affects the directory name in the ESP. But depending on the grub package version, monolithic GRUB images (signed for secure boot) do not support being installed in another location than /EFI/debian (I have been advocating to fix this but no luck so far). No, because in manual partitioning it is up to the user to decide which ESP(s) is/are suitable for the installation, and set the others as "do not use". But is there a reason why DI partitioning does not set all (or previously existing) ESPs by default to "do not use" and let the user change that manually I don't know why it was designed this way. (perhaps with a reminder message if the user forgets to set the ESP in UEFI mode)? The installer already warns if the partitioning does set an ESP. Maybe it would be more intuitive + it could avoid/minimize user errors? Or is a shared ESP so common that DI partitioning needs its current defaults? Yes, the ESP is designed to be shared by all boot loaders.
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
Pascal Hambourg wrote: > > You could just run grub-install to reinstall GRUB into the new ESP and > register it in EFI boot variables. I wanted to try the manual way to learn + to create my EFI boot entry with a customized name. I think GRUB installation can only create EFI boot entry with the name "debian", or is it possible to change that? > No, because in manual partitioning it is up to the user to decide which > ESP(s) is/are suitable for the installation, and set the others as "do > not use". So I must have forgotten to set the other ESP as "do not use", stupid me (I switched from MBR + BIOS to GPT + UEFI setup not so long ago and I guess it shows:). But is there a reason why DI partitioning does not set all (or previously existing) ESPs by default to "do not use" and let the user change that manually (perhaps with a reminder message if the user forgets to set the ESP in UEFI mode)? Maybe it would be more intuitive + it could avoid/minimize user errors? Or is a shared ESP so common that DI partitioning needs its current defaults? Anyway, thanks for such a quick reply. Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
On 09/05/2024 at 12:42, Jmkr wrote: - I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/ Archive.tar". - Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to "/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again. - Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/ sdb1". - Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and created a new entry for ESP on "/dev/sdb1". You could just run grub-install to reinstall GRUB into the new ESP and register it in EFI boot variables. Do the fixes mentioned above also address the manual partitioning case? No, because in manual partitioning it is up to the user to decide which ESP(s) is/are suitable for the installation, and set the others as "do not use".
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
Sorry about the wrong order/formatting of last two messages. The webmail interface of Seznam.cz has totally idiotic and unconfigurable defaults and I keep forgetting to click their "Plain Text" button and keep forgetting to remove unnecessary "Quoted Reply Texts" that their idiotic interface forces on me. I will fix my Thunderbird profile to save myself from Seznam's idiotic webmail interface as soon as I have time for it. Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
I had a similar problem with my customized Debian 10 installer. I have not customized PARTMAN related UDEB packages yet, so these are at Debian 10 versions. What I did was I installed my Debian in one of my test laptops that also had another SSD with some Windows 11 installation that I plan to nuke later:). All was working and booting, but when I added ESP capacity monitoring to my CONKY configurations, I noticed that this laptop had different ESP space occupied than my other laptops with the same hardware. After checking what is going on I found that: - The ESP created by me during manual disk partitioning on the SSD that is used for my Debian system was empty and not used at all (not mounted at "/ boot/efi" and not mentioned in "/etc/fstab"). - Instead the ESP from the other SSD with the Windows 11 installation was used. It was mounted at "/boot/efi", its UUID was in "/etc/fstab" and DI/ GRUB installed the "EFI/debian/grubx64.efi" file there right next to the "Microsoft" and "Boot" directories that contained the Windows garbage. Thankfully I did not boot that Windows 11 installation, so Windows were not able to mess around with the Debian files that rudely appeared on "their" disk. I was able to (hopefully) fix the situation when I noticed it: - I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/ Archive.tar". - Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to "/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again. - Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/ sdb1". - Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and created a new entry for ESP on "/dev/sdb1". - Then, I tested that the system boots as before using the new EFI and FSTAB entries and correct ESP. Did I forget something (that will cause problems in the future) by not reinstalling GRUB or some other stuff? Do the fixes mentioned above also address the manual partitioning case? If not perhaps you could check that case also. I will keep the Windows 11 installation (as this laptop is for testing anyway) = if you want I could test the fixed PARTMAN files, if these are provided so that my script for customizing the Debian Netinst ISO can include them (after I modify it to extract a new PARTMAN TAR or copy new PARTMAN files directly to the extracted Debian Netinst ISO). (In the future I plan to learn how to create DI ISO from scratch to be able to include modified UDEB packages etc. => if that is needed for testing and you can provide some starting instructions for me I could try that also.) Regards, Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
By the way at "https://www.reddit.com/r/debian/comments/wfk4xt/debian_keeps_installing_bootloader_in_wrong_disk/; other people mention similar problems that are/could be related to this bug. Jmkr -- Původní e-mail -- Od: Jmkr Komu: 1034...@bugs.debian.org, pas...@plouf.fr.eu.org, k...@debian.org, deb...@jamesie.de, a...@hax0rbana.org Datum: 9. 5. 2024 10:42:41 Předmět: Re: Bug#1034812: Unbootable after install: UEFI installed to wrong ESP I had a similar problem with my customized Debian 10 installer. I have not customized PARTMAN related UDEB packages yet, so these are at Debian 10 versions. What I did was I installed my Debian in one of my test laptops that also had another SSD with some Windows 11 installation that I plan to nuke later:). All was working and booting, but when I added ESP capacity monitoring to my CONKY configurations, I noticed that this laptop had different ESP space occupied than my other laptops with the same hardware. After checking what is going on I found that: - The ESP created by me during manual disk partitioning on the SSD that is used for my Debian system was empty and not used at all (not mounted at "/boot/efi" and not mentioned in "/etc/fstab"). - Instead the ESP from the other SSD with the Windows 11 installation was used. It was mounted at "/boot/efi", its UUID was in "/etc/fstab" and DI/GRUB installed the "EFI/debian/grubx64.efi" file there right next to the "Microsoft" and "Boot" directories that contained the Windows garbage. Thankfully I did not boot that Windows 11 installation, so Windows were not able to mess around with the Debian files that rudely appeared on "their" disk. I was able to (hopefully) fix the situation when I noticed it: - I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/Archive.tar". - Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to "/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again. - Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/sdb1". - Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and created a new entry for ESP on "/dev/sdb1". - Then, I tested that the system boots as before using the new EFI and FSTAB entries and correct ESP. Did I forget something (that will cause problems in the future) by not reinstalling GRUB or some other stuff? Do the fixes mentioned above also address the manual partitioning case? If not perhaps you could check that case also. I will keep the Windows 11 installation (as this laptop is for testing anyway) = if you want I could test the fixed PARTMAN files, if these are provided so that my script for customizing the Debian Netinst ISO can include them (after I modify it to extract a new PARTMAN TAR or copy new PARTMAN files directly to the extracted Debian Netinst ISO). (In the future I plan to learn how to create DI ISO from scratch to be able to include modified UDEB packages etc. => if that is needed for testing and you can provide some starting instructions for me I could try that also.) Regards, Jmkr
