Bootloader (or UEFI) broke after system update?

Ask Fedora
1

Used Claude to summarize the situation and the performed actions:

Boot Failure Report: Avell B.ON Lite New (MN000046) Version 3

Hardware

  • Model: Avell B.ON Lite New i5 (MN000046)
  • CPU: Intel Core i5-1235U (Alder Lake, 12th generation)
  • GPU: Intel Iris Xe Graphics G7 (80 EUs)
  • RAM: 8GB DDR4 3200MHz
  • Storage: NVMe SSD 256GB (HFS256GEJ9X108N)
  • Firmware: Insyde H2O BIOS 1.07.06TBN (Avell B.ON)
  • KBC/EC: 1.07.05
  • ME FW: 16.1.25.1991

Disk Layout

  • hd0,gpt1: FAT32, ESP, UUID …, 614400KiB
  • hd0,gpt2: ext4, /boot, UUID …
  • hd0,gpt3: btrfs, label fedora, UUID …, subvolumes root and home

Kernels present in gpt2:

  • vmlinuz-6.17.1-300.fc43.x86_64 with initramfs-6.17.1-300.fc43.x86_64.img
  • vmlinuz-6.18.16-200.fc43.x86_64 with initramfs-6.18.16-200.fc43.x86_64.img
  • vmlinuz-0-rescue-0735cd3bb4af4c868d54824eaaf02672 with corresponding initramfs

Event Context

Operating system: Fedora 43, previously installed. The system worked normally before a package update via dnf. No distribution version upgrade occurred. The specific package that triggered the regression was not identified. Primary candidates in order of probability:

  1. shim update writing a MOK/UEFI variable incompatible with Insyde firmware 1.07.06TBN
  2. grub2 update modifying EFI entries in NVRAM
  3. New kernel (6.17 or 6.18)
  4. fwupd update

Avell does not register firmwares on LVFS. Automatic firmware update via fwupd is ruled out. No firmware update occurred. The probable mechanism is a UEFI variable written by shim or grub2 that structurally corrupted the variable storage region in the Insyde firmware NVRAM. Insyde H2O 1.07.06TBN has a fixed and limited allocation for UEFI variables. A MOK or boot variable written in an unexpected format or size may have corrupted the internal variable table upon storage, without modifying the firmware itself.

Symptom

After the package update, all kernels fail to boot. The behavior is identical in all cases: after selection in GRUB, the screen displays a single static _ character and the system hangs indefinitely. No additional output, visible panic, or error message of any kind.

Tests Performed and Results

Secure Boot:

  • “Erase all Secure Boot Settings” executed (clears PK, KEK, db, dbx)
  • “Enforce Secure Boot” disabled
  • Resulting state: Setup mode, enforcement off
  • Result: no change in boot behavior

Kernel parameters via GRUB editor:

All applied with removal of quiet and rhgb. Identical result in all cases: static _.

  • nomodeset
  • nomodeset video=efifb:off
  • nomodeset initcall_blacklist=simpledrm_platform_driver_init
  • nomodeset video=efifb:off initcall_blacklist=simpledrm_platform_driver_init
  • nomodeset dis_ucode_ldr video=efifb:off
  • rd.info rd.debug

Manual boot from GRUB shell via legacy protocol (linux):

linux (hd0,gpt2)/vmlinuz-6.18.16-200.fc43.x86_64 root=UUID=bb3db50e-39e5-4703-be8c-6b7b4e27980f rootflags=subvol=root nomodeset dis_ucode_ldr video=efifb:off
initrd (hd0,gpt2)/initramfs-6.18.16-200.fc43.x86_64.img
boot

Result: hangs after boot.

Manual boot from GRUB shell via EFI protocol (linuxefi):

linuxefi (hd0,gpt2)/vmlinuz-6.18.16-200.fc43.x86_64 root=UUID=bb3db50e-39e5-4703-be8c-6b7b4e27980f rootflags=subvol=root nomodeset dis_ucode_ldr video=efifb:off
initrdefi (hd0,gpt2)/initramfs-6.18.16-200.fc43.x86_64.img
boot

Result: identical.

Fedora KDE 43 live ISO (external USB drive): The same ISO that previously booted without any changes fails with the same symptom. Rules out any hypothesis related to the installed system.

Windows 11 25H2 installer ISO (external USB drive, written with Rufus): Passed the static _, reached the manufacturer logo and hung for over 10 minutes. Different behavior from Linux (advanced one step) but still no complete boot. Confirms the issue affects any modern OS on this firmware.

VT-d disabled in firmware: Result: no change in behavior.

Full NVRAM reset via F9 in Setup Utility: Result: no change in behavior. The Insyde defaults reset restores configuration values but does not reformat the UEFI variable storage region if structurally corrupted.

chainloader to grubx64.efi (bypassing shim): GRUB loaded successfully. Boot behavior after kernel selection remained identical. Rules out shim as the sole point of failure in the handoff chain.

ISOs tested via Ventoy (Debian 12, Ubuntu 22.04, SystemRescue): All fail at the same point: menu loads correctly, any kernel selection hangs immediately. Kernels 5.15, 6.1, and 6.17+ all exhibit identical behavior. Rules out kernel version as the variable.

What Has Been Ruled Out

  • Corrupted kernel: multiple different kernels with identical behavior
  • Corrupted initramfs: hang occurs before any initramfs access
  • GRUB configuration: direct manual boot from shell with minimal parameters fails identically
  • Secure Boot: disabled and keys cleared with no effect
  • Disk read failure: GRUB reads all files correctly from shell
  • OS-specific issue: live ISOs and Windows installer fail identically
  • Firmware update: Avell does not use LVFS, no firmware update occurred
  • VT-d/IOMMU: disabled with no effect
  • NVRAM reset via F9: no effect
  • shim as sole failure point: bypassing shim via chainloader to grubx64.efi produced no change

Probable Root Cause

Structural corruption of the UEFI variable table in the NVRAM of Insyde H2O firmware 1.07.06TBN, caused by an incompatible variable write by shim or grub2 during a Fedora 43 package update. The firmware initializes and displays GRUB correctly, but when preparing the EFI environment to transfer control to the kernel, it accesses the corrupted region and hangs. The F9 defaults reset does not resolve this because it restores configuration values only and does not rewrite the variable storage region.

I’m posting here since it happened when the OS in use was Fedora. I can cat the dnf log files from the GRUB shell to try to find what packages were updated, however it takes an eternity, like 1 line per second and the command is very limited (no tail, nothing, just cat FILE). Unfortunately an NVME adapter is not available. The PC is not mine. It happened yesterday (2026-03-31) around 9:00 pm

2

Forgot to mention that with Debian, for example, it boots to Calamares, but gets stuck when any option is selected. Same thing with SystemRescue or any lightweight and old kernel distros.

3

HI there, :waving_hand: Could you briefly tell us what happened in your own words? I see this body of text, but context is sometimes more effective to getting a solution here. What I can deduce is you had an issue during an update and you went to Claude for help?

Could you give us more context?

4

Used Claude to summarize mainly because english isn’t my first language. Basically, after a system update yesterday, ~9:00pm, on Fedora 43, everything broke. Can’t boot the system or any image. Might be bad firmware from Avell, and after the update GRUB or shim made some changes to the UEFI, I don’t know (not a computer expert). I can cat the dnf log files from the grub shell, but it takes SOOO long…

SGCAM_20260401_103931065
SGCAM_20260401_1039310653840×2160 874 KB

Also, with Debian, I can get to this page, but it gets stuck with every option.

1 Like
5

SGCAM_20260401_105009995
SGCAM_20260401_1050099951920×1080 336 KB

Actually, the grub shell from debian is much faster. However I can’t pipe other commands or truncate

1 Like
6

Have you run a memory test?

1 Like
7

Well, I can’t boot any system and the bios or whatever doesn’t provide tools to run a memory test. Do you have any suggestions? I’m trying to access these https://memtest.org/ binaries (located in the usb) from the grub shell

8

Ah, more logs:

SGCAM_20260401_111104502
SGCAM_20260401_1111045021920×1080 288 KB

SGCAM_20260401_111244859
SGCAM_20260401_1112448591920×1080 262 KB

SGCAM_20260401_111548939
SGCAM_20260401_1115489391920×1080 291 KB

9

SGCAM_20260401_111754276
SGCAM_20260401_1117542761920×1080 300 KB

10

Can you download the firmware and “update” it (even if it is to the same version you already have)? Maybe that would clear out the NVRAM.

11

The manufacturer doesn’t provide public firmware files. The pc is probably dead.

12

Have you tried booting a Live USB Installer using UEFI rather than grub?

13

Yes, windows

14

Not sure what you mean. Do you have Windows installed and able to boot or are you
booting a Windows USB installer? If you have a Fedora Live USB installer you should be able to boot it from UEFI.

15

Can you boot directly from the USB? Whether that works will depend on how you wrote the image to the USB stick, but there should be instructions on the website.

If you suspect the bad memory might be at low enough addresses that it is preventing your memory tester from loading, one thing you could try is swapping the order of the RAM sticks in your PC. Also, just reseating your memory sticks might fix the problem.

16

Only Fedora 43 is installed. Tried to boot Debian, SystemRescue, Ubuntu, Windows, etc, nothing works

17

If I try to boot the memtest.efi directly it doesn’t load anything, just black screen. Might open it later and reseat the ram.

1 Like
18

I had the exact same issue with a Gigabyte laptop. The (official) fix was to reinstall the BIOS from a USB drive using the UEFI Shell.

From what I understood, it was caused by an update to the secure boot keys, which was bigger than what the BIOS could handle and overrided parts of it. I had the same behaviors as you. I couldn’t boot anything (except FreeBSD for some reason).

2 Likes
19

Interesting.

The manufacturer provides the files or you had to find some workaround?

20

They were or course provided by Gigabyte. I find it really strange for a manufacturer to not publish the BIOS files. Did you tried to send them a mail explaining your problem and asking them for the BIOS ?