Core update 182 caused Grub boot failure

Hello Arne,

I’ve never seen a graphical problem with this hardware before. It has only happened twice and both times were in the last week with this grub update.

EDIT: The graphical problem is now consistent. I just applied Update 182 again and rebooted and the graphical corruption is still happening.

I’m afraid that the patch you linked, does not mean anything to me.

If I remember correctly the graphical glitch only occour in legacy mode on baytrail boards. (on your first screenshot the system was in uEFI mode.

If you force grub to textmode it may should also boot. Try to add “vga=ask” to the kernel commandline. (or remove the gfxmode modules before the kernel)

1 Like

Thanks again Arne,

Until Update 182 IPFire used BIOS/Legacy boot on my system. Since then it has failed to boot. I do not know why it appears to only be attempting EFI boot now.

My system is capable of doing UEFI boot, which I’ve proven with various USB sticks.

My system is fireinfo.ipfire.org - Profile 12a8c1b37699b320895097608705c5cc374254a9 which you’re right is Baytrail.

To modify the kernel commandline I’ll need to update the grub.cfg files in /etc and rebuild grub right? Either that or I’ll have to do it through Supergrub as I cannot get in to grub at all on a normal boot.

EDIT: Attempting to add vga=ask to the end of GRUB_CMDLINE_LINUX in /etc/defaut/grub and re-running the install-bootloader script.

It’s working!!!

I modified the IPFire update version back to 181, ran an update and this time before rebooting ran the /usr/bin/install-bootloader script (I had been assuming that this ran anyway).

While I had added vga=ask to the GRUB_CMDLINE_LINUX variable, after it booted the first time I removed this and re-ran the procedure again. The system is now booting properly. Even the graphical corruption is gone.

I’ve updated the bugzilla ticket and asked what I need to prepare for when grub is upgraded again in future.

Thanks!!

EDIT: Here’s a snippet of the bootlog. I think it confirms legacy/BIOS boot, but could you please confirm? Various online guides suggested other ways of finding if a system used EFI boot and I cannot get a clear answer.

[    0.000000] microcode: microcode updated early to revision 0x90d, date = 2019-07-10
[    0.000000] Linux version 6.1.61-ipfire (root@x86-01.haj.ipfire.org) (gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.41) #1 SMP 
PREEMPT_DYNAMIC Tue Nov 21 17:34:19 GMT 2023
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.1.61-ipfire root=UUID=6aef81a5-4a87-4c4d-bded-71320c47231a ro panic=10 rd.a
uto
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000003efff] usable
[    0.000000] BIOS-e820: [mem 0x000000000003f000-0x000000000003ffff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001effffff] usable
[    0.000000] BIOS-e820: [mem 0x000000001f000000-0x000000001f0fffff] reserved
[    0.000000] BIOS-e820: [mem 0x000000001f100000-0x000000001fffffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000200fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000020100000-0x00000000b9348fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000b9349000-0x00000000b9378fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000b9379000-0x00000000b9388fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000b9389000-0x00000000b988ffff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000b9890000-0x00000000b9b15fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000b9b16000-0x00000000b9b6bfff] type 20
[    0.000000] BIOS-e820: [mem 0x00000000b9b6c000-0x00000000b9b6cfff] usable
[    0.000000] BIOS-e820: [mem 0x00000000b9b6d000-0x00000000b9baefff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000b9baf000-0x00000000b9d24fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000b9d25000-0x00000000b9ff9fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000b9ffa000-0x00000000b9ffffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000e00f8000-0x00000000e00f8fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed08000-0x00000000fed08fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] efi: EFI v2.40 by American Megatrends
[    0.000000] efi: ESRT=0xb9b12298 ACPI=0xb937c000 ACPI 2.0=0xb937c000 SMBIOS=0xf05b0 SMBIOS 3.0=0xb9a39000 
[    0.000000] SMBIOS 3.0.0 present.
[    0.000000] DMI: Default string Default string/Aptio CRB, BIOS 5.6.5 08/01/2021
[    0.000000] tsc: Detected 2000.000 MHz processor
[    0.001576] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.001585] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.001605] last_pfn = 0x140000 max_arch_pfn = 0x400000000
[    0.001665] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[    0.001914] total RAM covered: 4000M
[    0.002334] Found optimal setting for mtrr clean up
[    0.002336]  gran_size: 64K  chunk_size: 128M        num_reg: 5      lose cover RAM: 0G
[    0.002423] e820: update [mem 0xba000000-0xffffffff] usable ==> reserved
[    0.002435] last_pfn = 0xba000 max_arch_pfn = 0x400000000
[    0.009089] found SMP MP-table at [mem 0x000fd920-0x000fd92f]
[    0.009120] esrt: Reserving ESRT space from 0x00000000b9b12298 to 0x00000000b9b122d0.
[    0.011395] Secure boot disabled
[    0.011397] RAMDISK: [mem 0x33901000-0x35c77fff]
[    0.011411] ACPI: Early table checksum verification disabled
[    0.011417] ACPI: RSDP 0x00000000B937C000 000024 (v02 ALASKA)
[    0.011427] ACPI: XSDT 0x00000000B937C080 000084 (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.011440] ACPI: FACP 0x00000000B9387930 00010C (v05 ALASKA A M I    01072009 AMI  00010013)
[    0.011452] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20220331/tbfadt-564)
...

This problem has been resolved by the IPFire developers.

Although I have not been told the details, I understand that update 182 was re-released with the older version of Grub again to resolve the problem.

Anyone with the same problem had to:

  • change the /opt/pakfire/db/core/mine to contain 181
  • update pakfire and upgrade to update 182
  • Run the /usr/bin/install-bootloader script, before rebooting

I have recently tested update 183 which I understand re-introduces the grub update. This is also working on my system also (it now boots EFI). See: 13509 – Grub Boot failure after update 182

Thank you everyone for the discussion in this thread!

3 Likes