Re: HTTP boot failed on timeout

Laszlo Ersek

On 02/17/20 11:52, wrote:
Hi Laszlo,

Thank you for the quick and detailed response. Some answers to your questions:
- Since I'm running the VMs as part of GNS3 project I'm not having full control over the VM startup command. I will try to run the VM outside GNS3 context just to make sure I'm having cleaner and more controlled environment.
- I'm using qcow2 drive file which is the HDD on which the net installation should run. The drive is empty waiting for the installation after boot completion.

I've used your suggestion for adding a 'romfile=""' property. I did it this way as I can't edit the device properties (GNS3...):
-global virtio-net-pci.romfile=""

Can you explain what is the meaning of setting this property and why it is related to my problem?
It is not necessarily related to your problem; it *could* be related.

The romfile property tells QEMU what PCI expansion ROM to load into the
device's PCI option ROM BAR. By default the ROM in question is built
from the iPXE project. This means that the Simple Network Protocol
driver that talks to the virtio-net-pci device directly in OVMF comes
from the iPXE project.

OVMF has a built-in driver (VirtioNetDxe) for the same device however,
it just has lower priority. So if you want VirtioNetDxe to take control
of the device, you need to prevent the loading of the expansion ROM
described above. That's what romfile='' does.

And this could be relevant to your problem because the SNP driver lies
at the bottom of the edk2 network stack (in OVMF anyway). If there is a
problem in your iPXE SNP driver, then that could affect the dependent
TCP connection, and hang your HTTP boot. Switching in the VirtioNetDxe
driver might show a difference here.

Note: I'm not blindly blaming the iPXE driver; I'm just saying it
*could* be related. Seeing how your QEMU binary is ancient (4+ years
old), there could be old iPXE issues affecting your iPXE expansion ROM
too, that have been fixed since, up-stream.

Also, if not suggested to use -bios what are the alternatives?
You should use the split build of OVMF (OVMF_CODE.fd and OVMF_VARS.fd).
OVMF_CODE.fd is the firmware executable. OVMF_VARS.fd is a *template*
file for creating actual variable store files from, when defining a new
domain. Once you define a new domain, the varstore file that was
originally copied from OVMF_VARS.fd should be considered basically
another "data disk" for the domain. The varstore file is where
persistent (non-volatile) UEFI variables are stored, for the domain.

With "-bios", you get a varstore emulation that's not spec-conformant.
It suffers from various obscure problems. Don't use it.

The related (traditional) QEMU cmdline options are shown below. There is
a more recent, more modern, format for the same, but that format
requires a newer QEMU release. (For details, check out
But honestly, the best idea is to just use libvirt.)

So, the original options are:

-drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=guest-vars.fd \

where "guest-vars.fd" is specific to the guest in question, and was
originally copied from OVMF_VARS.fd.

If your distro doesn't package OVMF_CODE.fd and OVMF_VARS.fd separately,
then it's too old.

Is there an option for me to also skip 'Start PXE over IPv4' part from happening in the boot process?
No, there's not. While you can influence the UEFI boot order from the
QEMU command line, for example with:

-device virtio-net-pci,[other options],bootindex=0

the QEMU <-> firmware interface that exposes this to the firmware --
specifically, the "bootorder" fw_cfg file -- is not expressive enough to
tell apart PXE boot on a given NIC from HTTPv4 boot on the same NIC. You
can specify a particular NIC, but given that NIC, you'll have to stick
with the edk2-default boot order for a NIC.

If you can go into the firmware setup TUI once, and manually reorder the
PXE vs. HTTPv4 boot options, then OVMF will generally stick with that
order for you (until / unless you instruct OVMF to drop netboot from the
boot order altogether). But that requires you to interact with the guest

This suggestion worked well! and I was able to fully download the file. Thank you!
Oh wow. :) So, it *is* related to the iPXE SNP driver.

For reference, can you search your installed package set for packages
that have "ipxe" in the name? Can you list their names and versions?

Basically now I expect that you are using your distro's very outdated
iPXE package, whose issues have long been fixed up-stream.

The only problem now, is that I get kernel panic on the next step - who said life are simple..... ;-)

I'll continue to debug the kernel panic.

I've attached qemu.log just in case.

Join to automatically receive all group messages.