bug: Boot menu never displays despite 10s default timeout — possible ConOut acquisition failure on INSYDE H2O firmware

[KennedySilverDollar]

Version / Commit

v0.0.28 (v0.0.28-12-g0e4452b for source reference — release binary is from the v0.0.28 tag)

What happened?

On an HP OmniBook 5 16-ag1xxx (INSYDE H2O EFI v2.9 firmware, Secure Boot disabled), the boot
menu never displays despite having two entries configured and no menu-timeout override (so it
should default to the 10s DEFAULT_MENU_TIMEOUT_SECONDS).

sprout.toml:

sprout configuration: version 1

version = 1

[entries.void-linux]
title = "Void Linux (Sprout)"
actions = ["boot-linux"]

[entries.shell]
title = "Sprout Shell (Debug)"
actions = ["shell"]

[actions.boot-linux]
chainload.path = "\vmlinuz-7.2.3_1"
chainload.linux-initrd = "\initramfs-7.2.3_1.img"
chainload.options = [
"root=UUID=f0b7c63e-f8ea-4fbf-9fb1-6f75b1a21760",
"rootfstype=bcachefs",
"rd.driver.pre=bcachefs",
"rw",
"loglevel=7"
]

[actions.shell]
shell = {}

Expected: 10s wait with "Boot Menu:" entry list printed via info!(), then fallback to default
entry if no key is pressed.

Actual: No text is displayed at any point during boot. The void-linux entry boots immediately
with no visible delay. efibootmgr -v confirms Boot0000 has no extra args (no --boot,
--force-menu, etc.), so this isn't the --boot bypass path. No LoaderConfigTimeout* EFI variables
are present in efivarfs that could override the timeout via BootloaderInterface::get_timeout().

Traced through crates/boot/src/menu.rs and crates/eficore/src/logger.rs:

• Logger::log() silently no-ops if self.output() is null:
  fn log(&self, record: &Record) {
  let Some(output) = (unsafe { self.output().as_mut() }) else {
  return;
  };
  ...
  }
• Logger::init() sets the output via uefi::system::with_stdout(...), which — per uefi-rs
  semantics — silently skips the closure if it can't acquire the SimpleTextOutputProtocol
  handle, rather than erroring.

Hypothesis: on this firmware, with_stdout may be failing to acquire ConOut (possibly related to
how INSYDE H2O hands off GOP/text console state), leaving the logger's output pointer null. The
menu's 10s wait/key-read loop would still execute correctly — it's just invisible — and after
timeout the default entry boots. This matches the observed behavior better than "menu was
skipped entirely."

At Linux kernel handoff, efifb reports the framebuffer already in native panel graphics mode:
efifb: framebuffer at 0x500000000, using 9000k, total 9000k
efifb: mode is 1920x1200x32, linelength=7680, pages=1

Would it be possible to add a fallback/warning path if ConOut/with_stdout fails to acquire,
instead of silently no-op'ing? Also curious whether INSYDE H2O is a known-problematic vendor for
SimpleTextOutputProtocol acquisition. Happy to test diagnostic builds or provide further
firmware/DMI details on request.

Log output

DMI: HP HP OmniBook 5 Laptop 16-ag1xxx/8DF4, BIOS F.06 07/23/2025
efi: EFI v2.9 by INSYDE Corp.
Secure boot disabled

efibootmgr -v (relevant entry):
Boot0000* Void Linux (Sprout)  HD(1,GPT,14333a45-2132-45cd-bfaf-8b64a85d4106,0x800,0x200000)/\EFI\BOOT\sprout.efi
(no extra boot option data / args present)

dmesg (graphics init at kernel handoff):
[    0.374353] efifb: probing for efifb
[    0.374360] efifb: framebuffer at 0x500000000, using 9000k, total 9000k
[    0.374362] efifb: mode is 1920x1200x32, linelength=7680, pages=1
[    0.374363] efifb: scrolling: redraw
[    0.374363] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

Code of Conduct

• I agree to follow the Sprout Code of Conduct.