Libvirt/qemu faulty bios program

drubug · September 26, 2025, 2:41pm

Hello,

the installed cachyos/qemu environment does not boot illumos-based operating systems.

#pf Page fault 
Bad kernel fault at addr=0xfffffe0604c07370 
pid=0, pc=0xfffffffffb879dea, sp=0xfffffffffbcb00e8, eflags=0x10007 
cr0: 80050011<pg,wp,et,pe>  cr4: 3000b8<smap,smep,pge,pae,pse,de> 
cr2: fffffe0604c07370  cr3: 9000000  cr8: 0 

        rdi: fffffe064a975000 rsi: fffffe0604c07370 rdx:         2d617274 
        rcx:          5ac2e4e  r8: fffffe0677f8d000  r9: fffffe0677f8d000 
        rax: fffffe064a975000 rbx:         2d617274 rbp: fffffffffbcb0170 
        r10:              18c r11:              18c r12:                0 
        r13: fffffe0648cd1640 r14:         2d617274 r15: fffffe0604c07370 
        fsb:        200000000 gsb: fffffffffbc3f000  ds:                0 
         es:                0  fs:                0  gs:                0 
        trp:                e err:                9 rip: fffffffffb879dea 
         cs:               30 rfl:            10007 rsp: fffffffffbcb00e8 
         ss:               38 

Warning - stack not written to the dump buffer 
fffffffffbcaff00 unix:die+d3 () 
fffffffffbcaffe0 unix:trap+999 () 
fffffffffbcafff0 unix:cmntrap+e9 () 
fffffffffbcb0170 unix:bcopy_altentry+55a () 
fffffffffbcb0200 unix:startup_modules+10a () 
fffffffffbcb0210 unix:startup+5a () 
fffffffffbcb0250 genunix:main+36 () 
fffffffffbcb0260 unix:\_locore_start+88 () 

skipping system dump - no dump device configured

Replacing /usr/share/qemu/bios-256k.bin, copied from a distro comparable with cachyos, those systems boot.

Unfortunately I don’t know the version-numbers of both bios-256k.bin programs but
qemu-system-x86_64 is 10.1.0.
Can someone tell where to find the (cachyos-)versions of such installed sub-components?
Thanks much in advance!

HaRo · September 26, 2025, 3:13pm

No problems to running and installing tribblix here with OS-Information: OmniOSCE Bloody.
I just booted from virtio disk.
Installed QEMU Version is 10.1.0-1

drubug · September 26, 2025, 4:02pm

Thanks HaRo,
Can you try to boot your setting with empty cdrom and no hd.
Then you see the BIOS version:
CachyOS: SeaBIOS (arch linux 1.17.0) ← Does not boot iso-image file
CachyOS: SeaBIOS (other linux 1.16.0) ← Does the boot

HaRo · September 26, 2025, 4:51pm

Welcome @drubug
The first time I booted the Tribblix system, there was no cdrom inserted.
The system boots without any problems. However, I don’t understand what you mean when you say I should boot without cdrom (or en empty one, what it is) and without a hard drive. What should the VM boot from then?
I’m using the current CachyOS kernel. That’s version 6.16.8-2.

HaRo · September 26, 2025, 5:05pm

I tried 1.17.rc7-1 (none gcc version) and I wasn’t able to enter SDDM. without having a working KDE I also wasn’t able to test the tribblix vm anyway.
I restored my last snapshot I made this morning, so my test-vm with tribblix is gone, too.

drubug · September 26, 2025, 5:11pm

If cdrom empty and no hd configured then the bios complains about no boot device found
and hangs but then you can see which bios-version tries booting.

I don’t think its a kernel issue.
Strange enough, I can boot linux-distros(for example this minimal Peropesis-3.0-live.iso)

HaRo · September 26, 2025, 5:25pm

drubug · September 26, 2025, 5:37pm

“Boot Options”: Looks like NIC/PXE is selected.
Do you boot over the network, too? If not, deselect it pls.

HaRo · September 26, 2025, 5:49pm

No, I never used this, and not even the vm configuration did:

drubug · September 26, 2025, 5:55pm

Where is the cdrom?
There should be one and empty:
IDE CDROM 1 Source path: No media selected

HaRo · September 26, 2025, 6:03pm

I had to import the vm after I restored an earlier snapshot I made!
There is no cdrom then, but I already added one again, only to be sure that it wouldn’t change anything. I tried it but got same results as before.
After entering the vm’s bios I could enter the Boot Manager from the bios. But you can’t do anything there, not disable or delete one of the entries.

drubug · September 26, 2025, 6:46pm

How do you enter a vm bios?
There should be neither a VM nor any VirtIO Disk 1.
Just an empty ide cdrom.

HaRo · September 26, 2025, 6:53pm

I suspect this is the BIOS that virsh installs in the background to boot a specific operating system. I think this has something to do with the operating system selection, which it attempts to automatically detect when selecting an operating system ISO file. Or rather, the one that you have to enter manually to boot an unrecognized operating system.

You can access the BIOS after it attempts to boot from the network. See the first image I uploaded. Then you just press ENTER and you’re in the VM’s BIOS.

drubug · September 26, 2025, 7:24pm

Ok, if you like you can check whether your qemu usage depends on the affected bios.

Stop virt-manager and move
$ sudo mv /usr/share/qemu/bios-256k.bin /usr/share/qemu/bios-256k.bin.cachy

Start virt-manager and VM.
You might get the error message: Could not load PC BIOS

Restore
$ sudo mv /usr/share/qemu/bios-256k.bin.cachy /usr/share/qemu/bios-256k.bin

HaRo · September 26, 2025, 8:28pm

It had no effect on the VM at all.
Using lsof, I determined that qemu only uses /usr/share/edk2/x64/OVMF_CODE.4m.fd in /usr/share

drubug · September 26, 2025, 8:55pm

Thanks for helping.
You cannot reproduce it due to different configuration.
It seems that this arch binary has a subtle defect.

drubug · September 27, 2025, 3:19pm

CachyOS SeaBIOS /usr/share/qemu/bios-256k.bin

arch 1.17.0-1 ← Does not boot illumos-based iso or hd (linux- and bsd-based are fine)
fe42 1.17.0-5 ← Does boot all of above
(fedora-42 specific rebuild four times since 1.17.0-1)

How to handle such an issue? Package: extra/seabios 1.17.0-1

drubug · September 28, 2025, 3:05am

Short Roundup
/usr/share/qemu/bios-256k.bin replaced with them.
(success = boots, failed = loops, bad kernel fault)

fedora-42     1.17.0-5 success (binary)
seabios-git   1.17.0-4 success (source)
seabios-rel   1.17.0-0 success (source)
qemu-prebuild 1.17.0-0 success (binary)

cachyos  1.17.0-1  failed (binary)
cachyos  reinstall failed (binary)
arch-git 1.17.0-1  failed (source, pkgbuild)

What has been found so far are different pkg-sizes:

seabios-rel  Size 617504 seabios-1.17.0.tar.gz (browser download)
arc-pkg-git  Size 617520 seabios-1.17.0.tar.gz (pkgbuild fetch)

Source https://www.seabios.org/downloads/
Source https://gitlab.archlinux.org/archlinux/packaging/packages/seabios.git
Compiler gcc 15.2.1/ld 2.45.0

drubug · September 29, 2025, 1:02pm

PKGBUILD is the cause of this special bios boot problem

:
_debug_level=0
:
echo "CONFIG_DEBUG_LEVEL=$_debug_level" >> $pkgbase-rel-$pkgver/.config
:

All binaries are build with this level no matter what the config-file want:

$ cat config.seabios-256k
# for qemu machine types 2.0 + newer
CONFIG_QEMU=y
CONFIG_ROM_SIZE=256
CONFIG_ATA_DMA=n
CONFIG_DEBUG_LEVEL=1  # Useless! But I need this level to fix the issue

Patch PKGBUILD

_debug_level=1

Now all binaries are build with this level. NO! No! no!
Who knows why packager decided level 0 (for all pkgs)

Solution: Build new single package.
Remove all configs but keep the one you need: config.seabios-256k
Change PKGBUILD: _debug_level=1, Remove all configs/sums, too.

$ updpkgsums
$ makepkg
$ sudo cp pkg/seabios/usr/share/qemu/bios-256k.bin /usr/share/qemu/bios-256k.bin
$ qemu-system-x86_64 -cdrom ~/isos/smartos-20250918T000550Z.iso -m 4G -cpu host -enable-kvm -smp 2 -vga qxl

arch-git 1.17.0-1  success (source, pkgbuild patched)

fedora-42 and others are successful because they build with debug_level=1
(which is the default of upstream source)