On Mon, Apr 6, 2026 at 6:22 AM Ozymandias42 <[email protected]> wrote: > > Greetings OpenBSD community, > > there seems to be a bug in the UEFI Bootloader in PXE context. > > Setup: > - OpenWRT with dnsmasq as DHCP and TFTP Server > - BOOTX64.EFI and bsd.rd in the same TFTP root-directory > - Testmachines: > Proxmox VE9.1 VMs with pc-q35-10.1 platform > and OVMF UEFI Firmware 4.2025.05-2 > Beelink S3 Mini with N95 Quad-CPU > > --- > > Expected behaviour: > Machine Boots, UEFI goes through PXE Boot and loads BOOTx64.EFI > from the TFTP Server and executes it and boots. > > --- > > Observed behaviour: > Machine Boots, UEFI goes through PXE Boot, loads BOOTX64.EFI, > executes it and crashes into a reboot. > > This happens on both VMs and on real hardware. > > --- > > What was tried: > Loading iPXE.efi instead of BOOTX64.EFI > to then `chain BOOTX64.EFI` from the iPXE Shell > > This succeeds in loading BOOTX64.EFI but fails > in then being unable to get bsd.rd from the TFTP server. > > This only worked on the VM as iPXE was unusable > on the real hardware due to missing USB input. > > --- > > Discovery of the Bug: > After experimenting a bit with trying to load miniroot.img > and cd78.iso via PXE directly, I noticed that sometimes > loading of BOOTX64.EFI did succeed and was able to boot bsd.rd > > After narrowing down all hardware changes it became apparent > that for some reason BOOTX64.EFI, while not having an issue > with missing cd drives when booted from cd78.iso or miniroot.img, > it DOES crash out without an cd-drive when coming from PXE > > Trying to substitute an empty cd-drive with an ide or sata disk > did not work. > > However once an empty ide-cd-drive was present it kept working > reproducibly. > > Further testing showed that it wasn't actually the cd drive > but the presence of a second item in the uefi's boot order. > This could be an scsi drive or an ide cd drive. > If that boot option was removed, despite it only being for > the UEFI, BOOTX64.EFI crashed upon load from TFTP. > As to why it crashed on real hardware, I assume that it is due to > the nature of WHAT entry the next one is. Real hardware sometimes > has invalid entries pre-set and if one of those is the next one > after PXE boot then this crash happens. > After changing the boot-order on my real HW testmachine, > it kept working reliably there too. > > --- > > Closing words: > I assume this behaviour would be present when booted locally too > if that was possible to do with no local device in the uefi boot-order. > ...might be doable if the UEFI shell is the only entry > and BOOTX64.EFI was chainloaded from there. > > As it stands this is a pretty strange bug, as beyond impacting PXE > it might also make diskless operation of OpenBSD on UEFI impossible. > On BIOS with the pxeboot binary this does not happen.
confirmed this on my end, adding an empty SATA CDROM drive to my libvirt configuration and enabling it as part of the boot order makes BOOTX64.EFI work thru PXE boot. disabling it in libvirt's boot device order shows the old behavior of simply resetting the vm instead of booting. > > > Best regards, > Ozymandias42 >
