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 -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585
signature.asc
Description: This is a digitally signed message part
