Gigabyte UEFI not starting systemd-boot unless logo is disabled

itaranto · 2024-02-18 00:54:46

Hello,

First of all, this is very likely *not* an Arch Linux issue, but anyway I'd like to hear your opinion on this.

I have this Gigabyte motherboard and I have a dual-boot setup with Windows 10 LTSC.

The problem is, if I set the systemd-boot entry as default, then the BIOS hangs at the stupid Gigabyte "logo screen". This _does not_ happen when Windows is set as the default boot manager, in such case the BIOS shows its logo screen as part of the Windows loading screen.

The sysytemd-boot boot entry (and also the Windows one) works fine when selecting it manually form the BIOS boot menu.

Everything was working fine until I updated to the latest firmware version. If I disable the logo display from the BIOS settings ("Full Screen LOGO Show"), then the problem is gone.

Did anybody experienced something similar with Gigabyte motherboards?

I have no idea whose fault it is, it's either a Gigabyte bug or a systemd-boot one.

Should I report this to systemd first? Should I report this to Gigabyte (probably useless) ?

Last edited by itaranto (2024-02-18 01:45:42)

itaranto · 2024-02-18 01:46:14

I've just succeeded at reproducing this when using the Arch ISO which has the GRUB boot loader, so I guess this is a Gigabyte issue most likely.

Last edited by itaranto (2024-02-18 23:58:40)

cryptearth · 2024-02-18 11:25:53

As a bios flash usually resets it to default settings:
- Have you checked if SecureBoot got re-enabled?
- Have you checked the boot entry via efibootmgr?
- How have you confirmed, that the BIOS gets stuck?
- As you tried a GRUB boot: Did the menu come up?
As the bios flash also could have carried over old settings: Have you tried to clear CMOS / reset it by loading defaults?
I could be some messed up configuration.

itaranto · 2024-02-18 18:05:52

cryptearth wrote:

- Have you checked if SecureBoot got re-enabled?

I don't have secure boot enabled.

cryptearth wrote:

- Have you checked the boot entry via efibootmgr?

I ran efibootmgr and I found something interesting:

Timeout: 1 seconds
BootOrder: 0000,0003
Boot0000  Windows Boot Manager	HD(1,GPT,718b3859-45e2-c140-b810-d79f486a612a,0x800,0xfa000)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d0000004d000100000010000000040000007fff0400
Boot0003  Linux Boot Manager	HD(1,GPT,718b3859-45e2-c140-b810-d79f486a612a,0x800,0xfa000)/\EFI\SYSTEMD\SYSTEMD-BOOTX64.EFI

Notice the huge line for the Windows entry, I believe it should be just:

\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI

It almost looks like that's stored in a malformed string (not null terminated C string) since it seems to have garbage at the end.

cryptearth wrote:

- How have you confirmed, that the BIOS gets stuck?

Well, the logo screen stays frozen, keys like Ctrl+Alt+Supr don't work. The only thing I can do is to power off or reboot.

cryptearth wrote:

- As you tried a GRUB boot: Did the menu come up?

Yes, I posted an update saying I tested this using the Arch ISO through an USB thumb drive. If I set as default, the same thing happens.

cryptearth wrote:

As the bios flash also could have carried over old settings: Have you tried to clear CMOS / reset it by loading defaults?

I haven't tried clearing the CMOS through physical means but I did reset the BIOS to the default using the UEFI GUI.

Last edited by itaranto (2024-02-18 18:07:10)

itaranto · 2024-02-18 18:13:02

itaranto wrote:

It almost looks like that's stored in a malformed string (not null terminated C string) since it seems to have garbage at the end.

I may be wrong about what I said there, I'm not an expert in UEFI nor UEFI variables. After running efibootmgr -v I can infer the "extra" part I see is some sort of "data" segment:

Timeout: 1 seconds
BootOrder: 0000,0003
Boot0000  Windows Boot Manager	HD(1,GPT,718b3859-45e2-c140-b810-d79f486a612a,0x800,0xfa000)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d0000004d000100000010000000040000007fff0400
      dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 a0 0f 00 00 00 00 00 59 38 8b 71 e2 45 40 c1 b8 10 d7 9f 48 6a 61 2a 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 49 00 43 00 52 00 4f 00 53 00 4f 00 46 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 4d 00 47 00 46 00 57 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
    data: 57 49 4e 44 4f 57 53 00 01 00 00 00 88 00 00 00 78 00 00 00 42 00 43 00 44 00 4f 00 42 00 4a 00 45 00 43 00 54 00 3d 00 7b 00 39 00 64 00 65 00 61 00 38 00 36 00 32 00 63 00 2d 00 35 00 63 00 64 00 64 00 2d 00 34 00 65 00 37 00 30 00 2d 00 61 00 63 00 63 00 31 00 2d 00 66 00 33 00 32 00 62 00 33 00 34 00 34 00 64 00 34 00 37 00 39 00 35 00 7d 00 00 00 4d 00 01 00 00 00 10 00 00 00 04 00 00 00 7f ff 04 00
Boot0003  Linux Boot Manager	HD(1,GPT,718b3859-45e2-c140-b810-d79f486a612a,0x800,0xfa000)/\EFI\SYSTEMD\SYSTEMD-BOOTX64.EFI
      dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 a0 0f 00 00 00 00 00 59 38 8b 71 e2 45 40 c1 b8 10 d7 9f 48 6a 61 2a 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 53 00 59 00 53 00 54 00 45 00 4d 00 44 00 5c 00 53 00 59 00 53 00 54 00 45 00 4d 00 44 00 2d 00 42 00 4f 00 4f 00 54 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00

So, it's unlikely that entry is corrupted.

Last edited by itaranto (2024-02-18 18:13:32)

cryptearth · 2024-02-18 20:08:36

The additional data shouldn't affect anything - what they're for? I don't know.
Interesting gigabyte supports such an old board with such a recent update. I have a msi b550a-pro which got it's last update in october - also to agesa 1.2.0.B.
You could try to go one version back to see if it's an issue introduced just with the most recent update.

Also: The support site lists quite some important patch notes - like for the F40 it says: "you have to update to F31 first". Or F25 and F30 which require some specific chipset driver version (and by this windows?).
I never had such restrictions - but it could very well be that for some reason if you skipped these steps that you maybe ended up with some corrupted bios no longer working properly. I guess best is to request help from gigabyte support as all we can offer is guessing unless you can give us specific informations about such details.
T52d lists: "set fTPM to enabled by default as requirement for Win11" - it's likely that also secureboot was changed to enabled by default.

itaranto · 2024-02-18 23:56:01

cryptearth wrote:

You could try to go one version back to see if it's an issue introduced just with the most recent update.

I did precisely that

Because, if you read the changelog for the last version (F52n), it says:
- 4. Addresses potential UEFI vulnerabilities. (LogoFAIL)

Which is very very suspicious, and indeed, I downgraded to the previous version (F52i) and the issue is gone.

cryptearth wrote:

Also: The support site lists quite some important patch notes - like for the F40 it says: "you have to update to F31 first". Or F25 and F30 which require some specific chipset driver version (and by this windows?).

Don't worry about that, I updated those versions ages ago. My problem started when I went from F52h to F52n.

I'll definitely try to report this to Gigabyte.

cryptearth · 2024-02-19 19:11:42

Well, I had to read up LogoFail as I wasn't aware of it from my usual IT-news site I browse on regular basis ...
From what I found: It first was mentioned in very late november with additional information released in early december last year. The F52n was released at x-mas with the previous update F52i back in february.
Given the age of the platform and the very short time between information about the vulnerability made public and the released of the update - it's fair to guess it was likely rushed - and likely some mistakes happened causing the now corrupt F52n.
This should be reported to Gigabyte as there seems something went quite wrong when they implemented the fix that fast.

If you're lucky there hopefully will be some fixed version in some time ... if you're unlucky and this goes the way of the dodo - well, you could end up like the Far Cry 1 version on steam: Ubisoft pushed one last update to it before abandoning it - and this very last patch brought some serious issues never resolved since
a) ubisoft just abandoned the game afterwards
b) steam not rolled back the broken update
c) community patches only fixes some of the issues

On the other site - will I ever see an update for my msi b550a-pro which already seems end of life?

Quite an interesting topic - would like to know if you get any reply from gigabyte about this ...

itaranto · 2024-02-23 12:20:02

cryptearth wrote:

Well, I had to read up LogoFail as I wasn't aware of it from my usual IT-news site I browse on regular basis ...
From what I found: It first was mentioned in very late november with additional information released in early december last year. The F52n was released at x-mas with the previous update F52i back in february.
Given the age of the platform and the very short time between information about the vulnerability made public and the released of the update - it's fair to guess it was likely rushed - and likely some mistakes happened causing the now corrupt F52n.
This should be reported to Gigabyte as there seems something went quite wrong when they implemented the fix that fast.

Yes, it's likely this version has been rushed.

I already reported this to Gigabyte through their site, so let's see what they have to say (if they even respond at all).

cryptearth wrote:

If you're lucky there hopefully will be some fixed version in some time ... if you're unlucky and this goes the way of the dodo - well, you could end up like the Far Cry 1 version on steam: Ubisoft pushed one last update to it before abandoning it - and this very last patch brought some serious issues never resolved since
a) ubisoft just abandoned the game afterwards
b) steam not rolled back the broken update
c) community patches only fixes some of the issues

Well, I guess Linux is not priority for Gigabyte. But, unlike other vendors, they at least acknowledge Linux exists which is something:

"Due to different Linux support condition provided by chipset vendors, please download Linux driver from chipset vendors' website or 3rd party website."

cryptearth wrote:

On the other site - will I ever see an update for my msi b550a-pro which already seems end of life?
Quite an interesting topic - would like to know if you get any reply from gigabyte about this ...

Sure, I'll keep you posted.

itaranto · 2024-02-23 21:36:15

Here's Gigabyte's response:

Dear Customer

Good day. Both BIOS are beta versions because both have a letter at the end of the version. So please use the version that works for you. As a side comment, Linux is not our main supported OS, because of too many distributions, Kernel versions, etc most of the support should be asked from the forums. This is also because the different distribution communities maintain the OS and the drivers are also complied from the different communities. It is not like Microsoft, which works closely with the chipset providers and fix any kind of microcode bug in the BIOS, and later provides the AGESA to all the manufacturers.

So please use only the version that works with the actual installation. Sometimes the distribution releases correction for the issue instead of the new release of the BIOS because the problem might be AGESA update/ correction related and the Kernel has to be updated.

If you have any comments please let me know.

Best regards.

Last edited by itaranto (2024-02-23 21:36:28)

kode54 · 2024-03-09 04:23:42

It's probably something to do with their LogoFAIL fix, possibly a bug in the fix. At least, that seems like the most likely culprit of all the changes in the latest versions.

Coincidentally, the latest BIOS for my board, the B550 Aorus Elite V2 AX, just came out a day after the post right above mine, on the 24th of February. I'll be turning off the fullscreen logo until there is a better fix.

hermanr · 2024-04-01 14:25:10

I have a similar issue with my Gigabyte AORUS Elite V2. I have boot entries for Linux and Windows set up in systemd-boot, but when I boot from the Linux partition, the boot menu never shows up and the system goes straight to Linux. This problem has persisted through various BIOS versions, including the latest stable version, installed yesterday. In my case, disabling the fullscreen logo does not change anything. I now use the BIOS boot settings to boot from either Windows or Linux, so it's not a major problem. It seems Gigabyte does something wrong here.

itaranto · 2024-04-01 14:55:29

Well, it seems the issue is fixed in the latest BIOS version F53 (2024-03-22). If I set the logo screen now, I can boot Arch just fine.

This is a new "stable" release, since Gigabyte marks their beta releases with a letter suffix.

They have also deleted the buggy release (F52n).

Also, the F53's change-log seems to be identical to F52n's.

itaranto · 2024-04-01 15:04:00

hermanr wrote:

I have a similar issue with my Gigabyte AORUS Elite V2. I have boot entries for Linux and Windows set up in systemd-boot, but when I boot from the Linux partition, the boot menu never shows up and the system goes straight to Linux. This problem has persisted through various BIOS versions, including the latest stable version, installed yesterday. In my case, disabling the fullscreen logo does not change anything. I now use the BIOS boot settings to boot from either Windows or Linux, so it's not a major problem. It seems Gigabyte does something wrong here.

I think this is a different issue. In my case the BIOS would hang when displaying the logo screen when using the Linux boot entry.

ua4000 · 2024-04-01 16:03:24

Does it make a difference, if you try the "console-mode" options in loader.conf ?

0 | 1 | 2 | auto | max | keep

https://man.archlinux.org/man/loader.conf.5

Arch Linux

#1 2024-02-18 00:54:46

Gigabyte UEFI not starting systemd-boot unless logo is disabled

#2 2024-02-18 01:46:14

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#3 2024-02-18 11:25:53

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#4 2024-02-18 18:05:52

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#5 2024-02-18 18:13:02

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#6 2024-02-18 20:08:36

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#7 2024-02-18 23:56:01

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#8 2024-02-19 19:11:42

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#9 2024-02-23 12:20:02

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#10 2024-02-23 21:36:15

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#11 2024-03-09 04:23:42

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#12 2024-04-01 14:25:10

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#13 2024-04-01 14:55:29

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#14 2024-04-01 15:04:00

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

#15 2024-04-01 16:03:24

Re: Gigabyte UEFI not starting systemd-boot unless logo is disabled

Board footer