On Feb 26th 2024 I ran the update on a system running Core Update 182. At the end of the update process the web interface was stuck and didn't respond anymore. I was able to start apache again from an already established ssh connection. The last lines of the update-core-upgrade-183.log: dracut: *** Constructing GenuineIntel.bin *** dracut: *** Store current command line parameters *** dracut: *** Creating image file '/boot/initramfs-6.6.15-ipfire.img' *** dracut: *** Creating initramfs image file '/boot/initramfs-6.6.15-ipfire.img' done *** Found bootloader device: /dev/md127 Updating configuration... Installing GRUB on /dev/sda... Could not install GRUB on /dev/sda Installing GRUB on /dev/sdb... Could not install GRUB on /dev/sdb The installation is on a RAID1 (mdraid) After reboot the system stops with the messages: Loading Linux 6.6.15-ipfire ... error: symbol `grub_is_shim_lock_enabled' not found. Loading initial ramdisk ... error: symbol `grub_is_shim_lock_enabled' not found. I tried to assign root file system, kernel and initrd on the grub shell, but the errors stayed the same. Currently the system boots in UEFI mode, which became necessary after my update from CU169 to CU170 (https://bugzilla.ipfire.org/show_bug.cgi?id=12941). Updates have been working ever since up to CU182. Is there a chance to get the installed system running again, or do I need to do a fresh install with CU183? Thanks in advance.
This problem seems to have been reported before and seemed to be a bug in the UEFI BIOS. *** This bug has been marked as a duplicate of bug 13507 ***
After taking a closer look I found a solution for this problem: The call to grub-install in line 135 of /usr/bin/install-bootloader fails because of missing parameters to the internal call to efibootmgr: "efibootmgr: option requires an argument -- 'd'" The existing entry for IPFire did not specify a file and location of the bootloader, just the partition (unfortunately I didn't take a note of this entry). After creating the entries for both RAID1 disks the system booted again: "efibootmgr --create --disk /dev/sda --part 3 --label "IPFire - Manual Fix" --loader \\EFI\\ipfire\\grubx64.efi" (and the same call for /dev/sdb). The entries now look like this: Boot0002* IPFire - Manual Fix HD(3,GPT,9b320297-b9e7-4afb-8e12-2f016289780c,0x42800,0x10000)/File(\EFI\ipfire\grubx64.efi) Boot0003* IPFire - Manual Fix HD(3,GPT,9b320297-b9e7-4afb-8e12-2f016289780c,0x42800,0x10000)/File(\EFI\ipfire\grubx64.efi) The devies are: [root@ipfire ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 931.5G 0 disk └─md127 9:127 0 931.5G 0 raid1 ├─md127p1 259:0 0 4M 0 part ├─md127p2 259:1 0 128M 0 part /boot ├─md127p3 259:2 0 32M 0 part /boot/efi ├─md127p4 259:3 0 1G 0 part [SWAP] └─md127p5 259:4 0 930.3G 0 part / sdb 8:16 0 931.5G 0 disk └─md127 9:127 0 931.5G 0 raid1 ├─md127p1 259:0 0 4M 0 part ├─md127p2 259:1 0 128M 0 part /boot ├─md127p3 259:2 0 32M 0 part /boot/efi ├─md127p4 259:3 0 1G 0 part [SWAP] └─md127p5 259:4 0 930.3G 0 part / To me it looks like install-bootloader needs additional code for UEFI boot. I would like to open the ticket again so people will notice. If that is not the correct response then please let me know and close the ticket again.
(In reply to Dirk Sihling from comment #2) > I would like to open the ticket again so people will notice. If that is not > the correct response then please let me know and close the ticket again. I believe it is correct to re-open this ticket. This seems to be a long-standing bug in GRUB: > https://bugzilla.redhat.com/show_bug.cgi?id=1758621 @Arne, could you please have a look what we can do here?