The setup involves a DHCP/TFTP/NFS server which dishes out /boot/pxeboot via tftp and offers a full 9.2 installation as an NFS root path. This works (and has always worked) with physical machines, enabling them to netboot into a FreeBSD 9.2 installation. Up till VirtualBox 4.3.8 (I believe), it was also possible to netboot a VirtualBox client machine with exactly this setup. However, starting with 4.3.10 (I believe), but surely with the switch to iPXE by VirtualBox, this does not work any more and hangs at the pxeboot stage: ---------- snip ---------- net0: 00:50:56:29:08:01 using pcnet32 on PCI00:03.0 (open) [Link:up, TX:0 TXE:0 BX:0 BXE:0] DHCP (net0 00:50:56:29:08:01)...... ok net0: 192.168.1.165/255.255.255.0 gw 192.168.1.5 Next server: 192.168.1.5 Filename: /pxeboot Root path: 192.168.1.5:/d/5s3e/ Ignoring unsupported root path tftp://192.168.1.5//pxeboot... ok PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard PXE version 2.1, real mode entry point @9cfa:03e9 BIOS 627kB/2095624kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (root@v902.xyzzy, Sat Oct 5 14:31:42 CEST 2013) ---------- snip ---------- And there it hangs. Using tcpdump I can see that the VM periodically sends DHCP discover packets which are duly answered by the DHCP server (otherwise we wouldn't even have gotten so far), but that's it. The VM produces a constant load of 1, most likely meaning that it does busy waiting. Miscellaneous info: - The DHCP/TFTP/NFS server runs 9.2 i386 single core (no SMP) - The VirtualBox host runs 9.2 amd64 SMP - The client environment (never reached unless by a physical machine) is 9.2 i386 SMP Fix: Since the netboot setup still works nicely with physical machines, there seems to be some incompatibility with the new iPXE code incorporated in VirtualBox. How-To-Repeat: Try to netboot a VirtualBox diskless client.
Responsible Changed From-To: freebsd-ports-bugs->vbox Over to maintainer (via the GNATS Auto Assign Tool)
This issue can be closed. After further investigation, it turned out the the VirtualBox iPXE client sets the DHCP client-id (equal to the mac address), whereas FreeBSD's pxeboot does not set it at all. This causes the ISC dhcp server to create two entries: one for the initial request based on the client-id, and then another for the request by pxeboot (based on the mac address). Unfortunately, even though iPXE sets the client-id to the mac address, this is still seen by ISC DHCP as two different things. Because the addresses assigned to these two entries differ, pxeboot does not receive anything any more (I did not research why this is so), causing further netboot/NFS exchanges to hang. The problem can be fixed by installed ISC DHCPD 4.3 and using its new ignore-client-uids flag. If this is set to true, PXE booting of VBox instances works again. Refs: https://lists.isc.org/pipermail/dhcp-users/2014-April/017782.html Next I'll try to attach a log of the DHCP exchanges before using ignore-client-uids.
Created attachment 144221 [details] DHCP log before setting ignore-client-uids to true
Also come up to this problem with qemu/libvirt vm and pxe boot PXE boot cfg: label FreeBSD9.2 menu label ^FreeBSD9.2-i386 pxe path/to/image/FreeBSD9.2/boot/pxeboot I can provide libvirt/qemu logs if necessary.
Please note that in comment #2 I have already stated that this issue can be closed, and also explained why.
Please close this issue.
9.2 is EOL. VBox has 5.2.4. I think this could closed.
See comment #2 and #5 :-)