default.ipxe timeout - maybe a dhcp problem? Wireshark logs inside.

[jeffzimmm]

@cml Thanks, I will try it out!

EDIT: TOTALLY WORKED!

OK, so for my own education, can you explain where that “next-server” setting is? What would I have to change in order for the default undionly.kpxe to work correctly?

@cml 's file works great, but I shouldn’t have to request a unique binary every time I reconfigure the network.

[Wayne Workman]

@jeffzimmm Thank you for being co-operative in troubleshooting with us and providing us with ample information in order to assist! This thread should stand as a role-model of how troubleshooting here should happen.

+1s for all your posts here.

[Tom Elliott]

@jeffzimmm I’m glad everything is working. Just a heads up, if you’re not too scared, you could remove the requirement of dnsmasq/proxyDHCP if you updated your routers firmware to dd-wrt. It’s 100% and just takes a little bit of time. With dd-wrt you have, essentially, enterprise grade configuration capabilities without the cost.

[Wayne Workman]

@jeffzimmm said:

@cml Thanks, I will try it out!

EDIT: TOTALLY WORKED!

OK, so for my own education, can you explain where that “next-server” setting is? What would I have to change in order for the default undionly.kpxe to work correctly?

@cml 's file works great, but I shouldn’t have to request a unique binary every time I reconfigure the network.

I was basically going to suggest the exact same thing that @Tom-Elliott said but I see that he beat me to it.

[jeffzimmm]

@Tom-Elliott

I may do that. All about the open source solutions. Wow, this is such an incredibly helpful forum!

But now there’s a new issue–possibly unrelated, because some of my hosts are behaving differently.

My test host was a Dell Inspiron One 20" all-in-one running Windows 7. That one works fine (although I find that I have to manually restart TFTP on the server first).

The real challenge are the new XPS 13 laptops. They have Dell-branded PXE-booting Ethernet-USB adapters. They are set to legacy BIOS, secureboot off.

They get as far as “IPXE Initializing Devices,” then give a beep, flash a long number for a milisecond (4.0003somethingsomething) and reboot. Unless any of that sounds familiar to you, I’ll have to do another wireshark capture.

[Wayne Workman]

@jeffzimmm said:

They get as far as “IPXE Initializing Devices,” then give a beep, flash a long number for a milisecond (4.0003somethingsomething) and reboot. Unless any of that sounds familiar to you, I’ll have to do another wireshark capture.

Try to use undionly.kkpxe for your bootfile. It works better for weird BIOS. Obviously you will need to flash your router with dd-wrt in order to switch files again… And after that - you can just turn dnsmasq off and set your DHCP up proper.

[jeffzimmm]

@Wayne-Workman

All right! I have successfully installed DD-WRT on the N66u and configured it to point to undionly.kkpxe. When all the teachers go home today, I’ll swap it in.

Just a couple questions:

1. As mentioned, I’ve got legacy BIOS Dell Inspiron Ones, and UEFI Dell XPS 13s. Should undionly.kkpxe theoretically work for both of them?

2. Dumb question. Right now, the Fog server is configured with its own DHCP and DNS turned off and dnsmasq enabled. Do I just uninstall dnsmasq now, or are there more steps needed to gracefully revert to a standard Fog installation?

[Wayne Workman]

@jeffzimmm said:

@Wayne-Workman

All right! I have successfully installed DD-WRT on the N66u and configured it to point to undionly.kkpxe. When all the teachers go home today, I’ll swap it in.

Just a couple questions:

1. As mentioned, I’ve got legacy BIOS Dell Inspiron Ones, and UEFI Dell XPS 13s. Should undionly.kkpxe theoretically work for both of them?

2. Dumb question. Right now, the Fog server is configured with its own DHCP and DNS turned off and dnsmasq enabled. Do I just uninstall dnsmasq now, or are there more steps needed to gracefully revert to a standard Fog installation?

1. No. Booting UEFI over the network requires a co-existing DHCP environment OR the manual switching of the specified bootfile every time you want to boot one or the other. I’ve not played with DD-WRT yet, so I can’t speak to what it can and can’t do in the area of co-existing BIOS and UEFI network booting. Basically - determined by the vendor information supplied by the device during the DHCP process - DHCP decides what options to give the device. I have accomplished configuring co-existence in Windows Server 2012 DHCP and I THINK that I’ve got it figured out for Linux DHCP. I have no earthly idea for DD-WRT. This article might reveal more insight to you - it links thread resources in the forums at the bottom if you wanted to read through those. Keep in mind this article is un-finished. Perhaps you can write the section for DD-WRT??? https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence Basically, in a nut shell you need one of the many .efi files in the /tftpboot directory to network boot via UEFI. To figure out which one you need, perhaps you might just “know” or perhaps you just try each one till you find one that works (there aren’t that many).

2. You should disable dnsmasq. It’s not necessary to uninstall it -but uninstalling is one way to disable it… I’d recommend just disabling it so that it’s there for you in the future should you need it. There are no changes specific to FOG when you disable dnsmasq - you simply disable it at the system level and then you’re done.

[Wayne Workman]

@cml said:

No idea if this helps, but this undionly.kpxe will point to 192.168.1.20. If this works it would seem that your default gateway is being set as next-server.
undionly.kpxe

Can you please explain how you built undionly.kpxe to point to a specific IP address?

[cml]

@Wayne-Workman

Sure,

I follow the steps in the wiki for the most part, except for the ipxescript I use:

#!ipxe
ifclose
ifopen && goto bootme || goto netstart
:netstart
dhcp || shell
ifopen || reboot
:netboot
chain tftp://192.168.1.20/default.ipxe || goto shell

Where of course 192.168.1.20 is replaced with your FOG IP.

But, reading back over the wiki the section labeled Custom ipxe script has a way that bypasses default.ipxe entirely.