Visor freezes before menu/log initialization on Gigabyte B550M DS3H AC

[ArchitB17976]

Visor consistently freezes during startup on my system. No menu or error message is displayed, and the machine remains stuck until I manually reboot it.

The same behaviour occurs both when Visor is launched directly by the motherboard firmware and when it is chainloaded through systemd-boot.

No boot.log file is created after any failed launch.

System information

• Motherboard: Gigabyte B550M DS3H AC
• BIOS version: F15 KV
• BIOS release date: 2022-10-03
• Operating system: Pop!_OS 24.04 LTS
• Architecture: x86-64 UEFI
• Secure Boot: Disabled
• ESP mount point: /boot/efi
• ESP filesystem: FAT/VFAT
• Visor binary SHA-256:

2196fe99ff9ec2287ec3a6fa4a9583e08a12970be2dfd55b0b07722b9d20908f

Observed behaviour

When Visor is selected:

1. The system begins attempting to launch it.
2. No Visor menu, text output, or error message appears.
3. The system appears frozen indefinitely.
4. A manual reboot is required.
5. After booting Pop!_OS through the motherboard boot menu, no Visor boot.log exists.

The normal Pop!_OS systemd-boot entry continues to work correctly from the same EFI System Partition.

Tests performed

1. Direct firmware launch

Visor was registered as a UEFI boot entry pointing to:

\EFI\VISOR\VISOR_X64.EFI

Result:

Freeze before any visible menu or error message.
No boot.log created.

2. Chainload through systemd-boot

I created a temporary systemd-boot entry:

title Visor diagnostic test
efi   /EFI/visor/visor_x64.efi

I selected this entry from the systemd-boot menu.

Result:

Same freeze as direct firmware launch.
No boot.log created.

This appears to rule out the Visor NVRAM entry itself as the cause.

3. Removed boot.conf

The installed boot.conf contained only the bundled commented examples and no active boot entries.

I moved it out of the way so that Visor could use its automatic detection path:

sudo mv /boot/efi/EFI/visor/boot.conf \
    /boot/efi/EFI/visor/boot.conf.disabled

Result:

Same freeze.
No boot.log created.

The failure therefore does not appear to depend on configuration parsing or configured boot entries.

4. Secure Boot verification

Both tools report that Secure Boot is disabled:

$ sudo sbctl status
Setup Mode:  Disabled
Secure Boot: Disabled
Vendor Keys: microsoft builtin-PK

$ mokutil --sb-state
SecureBoot disabled

The installed Visor binary is unsigned, but because Secure Boot is disabled, signature enforcement should not be involved in this failure.

5. EFI binary and path verification

The binary exists at:

/boot/efi/EFI/visor/visor_x64.efi

file identifies it as:

PE32+ executable (EFI application) x86-64

The Visor and Pop!_OS firmware entries both reference the same EFI System Partition.

The Visor entry was:

Boot0004* Visor
HD(1,GPT,...)/File(\EFI\VISOR\VISOR_X64.EFI)

The normal Pop!_OS entry successfully launches:

\EFI\SYSTEMD\SYSTEMD-BOOTX64.EFI

Visor status before testing

CLI path: /usr/local/bin/visor
Source dir: /root/.cache/visor/source
Source commit: unavailable
ESP: /boot/efi
Installed binary: /boot/efi/EFI/visor/visor_x64.efi
Installed sha256: 2196fe99ff9ec2287ec3a6fa4a9583e08a12970be2dfd55b0b07722b9d20908f
Config: /boot/efi/EFI/visor/boot.conf
Boot log: missing
UEFI entry: present

EFI directory contents after failure

backgrounds/
boot.conf.disabled
boot.conf.pre-debug
icons/
visor_x64.efi

There is no boot.log.

Expected behaviour

Visor should display either:

• the graphical boot menu;
• the text fallback menu;
• or an error/log indicating which initialization step failed.

Actual behaviour

The system freezes before displaying any output and before creating boot.log.

Additional observations

Because the freeze also happens when Visor is chainloaded through systemd-boot, I suspect the problem occurs inside the Visor EFI executable or during very early initialization, rather than in the motherboard NVRAM boot entry.

The absence of boot.log may indicate that execution does not reach the logging initialization, or that the failure occurs during an early console or filesystem operation.

[IO-ZetZor]

Thanks for the extremely methodical report — the chainload test and the missing boot.log are both useful signals.
I can't reproduce this without the hardware, but the evidence points somewhere specific. The freeze happens before any output and before boot.log exists. The very first thing Visor did after console setup was rotate the log file — which deletes and recreates boot.log on the ESP. Write-path bugs in some AMI FAT drivers are a known hazard, and a hang inside that rotation would look exactly like what you're seeing: no output, no log, frozen machine.

To split the possibilities, master now prints Visor loading... to the console before touching the ESP. Could you rebuild from master and try again? The outcome tells us a lot:

• Visor loading... appears, then it freezes → the hang is in the log rotation / ESP write path. Workaround while I fix it properly: I can add a no_log escape hatch (or you can test by making the ESP effectively read-only). Confirming this is the branch is the important part.
• Still freezes with no text at all → it's dying even earlier (console/ClearScreen/gnu-efi init), which is a different and rarer beast — I'd then send you a debug build that beeps/stalls at each init step to bisect it.

One more independent data point that would help: does the text fallback trigger if you temporarily disable CSM/enable it, or change the primary display (iGPU vs dGPU) in BIOS? A GOP quirk on that board is my second suspect after the FAT driver.

[nwgat]

perhaps updating bios might help, its seem to be 4 years old

[MartinTeunisse]

i have the same issue on an old optiplex 7040! i dont get a log file.