PXEboot issues

[A Former User]

Soooo… iPXE successfully build (missed out on liblzma-dev), copied undionly.kpxe to /tftpboot/ (backed up the old one), and now I’m stuck here:

fogtest1 with vmxnet3, registered and download task created:

it sits in a loop there. as soon as Ctrl+B disappears, it starts at those messages at the top of the screen.

fogtest2 with vmxnet3, registered and download task created:

Both VMDKs are clean without OS. Interesting that the older VM

[Wayne Workman]

Can you take a look at this?

https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution

They recommend that if you’re using a static IP, to use the static IP instead of 127.0.1.1

In your original post, right when the system uses 127.0.1.1, that’s the exact moment you start having problems in little China…

[Wayne Workman]

I have full confidence that if you simply used Debian 7, that everything would just work and you wouldn’t have any more of these problems.

FOG does not officially support Debian 8 yet, but the senior developer might get with you to make that happen if you’re willing and he has time.

Those are your two paths. I apologize for not being of more assistance, but it’s just new territory to me and I’ve never seen your exact problem before and with you using Debian 8, it could be any number of things that are wrong.

[A Former User]

Switching to Debian 7 means reinstall which often solves everything. I’m not all too inclined to add another VM to manage, especially with different software versions.

Entering the static lease for the FQDN into the hostsfile didn’t help either, seemingly the problem is not the 127.0.1.1 IP anymore.

Using the iPXE commandline it seems that it doesn’t get the root-path: http://ipxe.org/err/2d03e1

hah. now they stuck at

iPXE recommends to use the command route to check the IP and GW… voila:

now… why does it show the gateway as inaccessible? my workstation-VM is on that same host which has fine connectivity to everything. Also FOG including storage is on the very same subnet without firewalls in between. I’ll just try vmotioning the FOG VM over to the test-host…

[A Former User]

I actually got it working on 2 test-VMs with the vmxnet3 NIC type. It netboots, it images, it reboots to windows without being stuck in PXE voodo etc pp. I’ve just pointed the clients to ipxe.pxe instead of undipxe.kpxe.

Altough when I’m switching to the e1000e vNIC type, it gets stuck at the following screen when a task is set:

while the percentage can be anything, I’ve seen 7 to 85% already. No task = no trouble again.

[Tom Elliott]

@marbus90 what boot file are you using? If you’re using Intel.pxe.

[A Former User]

I’m using ipxe.pxe for that as well without any modifications. The other clients didn’t require any changes, no matter the NIC type. I’ve had Atheros, Intel, Realtek in the clients to be imaged, giving each its own static lease with another bootfile is not all that feasible as some of them are only temporary.

e1000e in VMware translates to Intel 82574L, then we’ve got a few clients with I217LM, majority is Realtek RTL8111E based.

It does seem like some tftpd timeout per file, which interestingly only applies to the e1000e vNIC type. Maybe vmxnet3 is faster, who knows. In one test on e1000e it actually got as far as loading the init.xz for 77% after loading the bzimage completely with ipxe.pxe.

[Tom Elliott]

@marbus90 said:

I’m using ipxe.pxe for that as well without any modifications. The other clients didn’t require any changes, no matter the NIC type. I’ve had Atheros, Intel, Realtek in the clients to be imaged, giving each its own static lease with another bootfile is not all that feasible as some of them are only temporary.

e1000e in VMware translates to Intel 82574L, then we’ve got a few clients with I217LM, majority is Realtek RTL8111E based.

It does seem like some tftpd timeout per file, which interestingly only applies to the e1000e vNIC type. Maybe vmxnet3 is faster, who knows. In one test on e1000e it actually got as far as loading the init.xz for 77% after loading the bzimage completely with ipxe.pxe.

Oh the stories I could tell about VMNic’s and ipxe.

I’ve found that the undionly.kkpxe serves all of my test systems well. I have YET to find a pxe file, however, that works well with the vmxnet3 drivers. I personally use intel.pxe on my systems as I set all my vm nics to e1000 and I have no issues booting my VMs at all.

[Junkhacker]

judging from the boot.php via browser showing 127.0.1.1, you likely need to change the FOG_WEB_HOST value to the correct IP in FOG Configuration>FOG Settings>Web Server
you also may have the wrong IP set in the /tftpboot/default.ipxe file

[A Former User]

boot.php issues have been solved. Problems lie elsewhere.

vmxnet3 -> ipxe.pxe -> 100%, imaging, rebooting to windows without being stuck
82574L -> undionly.kpxe.INTEL -> 100%, imaging, rebooting to windows without being stuck
i217LM -> undionly.kpxe.INTEL -> 100%, imaging, rebooting to windows without being stuck
Realtek -> undionly.kpxe.INTEL -> 90%, imaging, rebooting to windows without being stuck - doesn’t seem to run all that smooth, but that may be due to Realtek being crappy.
ipxe.org/040ee119 is listed as error handler, which points to missing DHCP configuration - it just needs 3 tries it seems, also DHCP isn’t all that fast before PXE is even loaded.

^ and somehow it started imaging after a few seconds. shrug

I think the undionly.kpxe file is somewhat broken. I’ll set up another ubuntu box, install FOG on there and copy over all the things to the production system.