Bug 13605

Summary:	System does not boot after Update from Core Update 182 to 183 (RAID1)
Product:	IPFire	Reporter:	Dirk Sihling <dsihling>
Component:	grub	Assignee:	Arne.F <arne.fitzenreiter>
Status:	MODIFIED ---	QA Contact:
Severity:	Major Usability
Priority:	Will affect all users	CC:	michael.tremer
Version:	2
Hardware:	x86_64
OS:	Linux

Description Dirk Sihling 2024-02-27 15:30:34 UTC

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.

Comment 1 Michael Tremer 2024-02-28 16:07:11 UTC

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 ***

Comment 2 Dirk Sihling 2024-03-04 17:20:33 UTC

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.

Comment 3 Michael Tremer 2024-03-11 11:26:37 UTC

(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?