I'm confused. If the VM won't launch iPXE from ROM, doesn't that make
the EFI builds in this package moot?
Yes, if I boot an iPXE upstream build from USB it works just fine.
Again, that kind of defeats the purpose of having it in the ROM in the
first place.
On 1/30/25 09:28, Sven Geuer wrote:
Hi Kevin,
On Tue, 2025-01-28 at 22:09 -0500, Kevin Otte wrote:
I was using the kernel and initrd from the netinstaller tree on the mirrors:
wget
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
wget
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz
Just tried these which booted flawlessly in my test environment, in the
same way as the ones used with my previous tests.
I also rolled back to ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1, the
version you reported the bug with, and could boot successfully from the
same initrds and kernels.
I vaguely remember trying a known good EFI binary also to no avail, but
my memory is uncertain.
Unfortunately I am not able to get my test environment for this going
after these years. When I start a VM from a trixie host with OVMF it
attempts its own HTTP boot rather than invoking iPXE as it once did.
That's due to now applying upstream's configuration for qemu when
building the ROMs. The packaging up to version 1.0.0+git-
20190125.36a4c85-5.2 did not consider this configuration. For a
pristine iPXE experience you can ether chain-load ipxe.efi or boot from
ipxe.iso, both available from the ipxe binary package.
To sum up, I still cannot reproduce what you observed back in 2022.
Any idea how to proceed?
Sven
