Kernel for Ubuntu 64 bit

[Sebastian Roth]

@Tom Looks like this: https://static.spiceworks.com/shared/post/0012/0090/image1.JPG

Either you are pointing it to the wrong TFTP server (check next-server/option 66) or your TFTP service on the FOG server is down (restart and test the service: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP)

[Tom Elliott]

I’m confused what’s going on. You have three dhcp servers? All handing out Option 66/67?

Can all three DHCP servers actually reach the FOG Server? If so, maybe this is the issue? I think the old saying: “Too many chiefs, not enough indians” is potentially one of the truest statements in this scenario?

(PS, I’m not intending my statement to offend, just simply using an old idiom I’ve heard as far as when I was a kid.)

[Tom]

@Tom-Elliott Let me explain, I have 2 domain controllers in one subnet providing DHCP to workstations (70/30 rule). The 3rd is DHCP server on different subnet, which does not play any role in this scenario.
I build new VM from scratch, Ubuntu 14.04.3 and fog 6257.
From DCs I was able to ping fog successfully.
Options 66 set with ip address correctly
Option 67 set to undionly.kpxe. I tried kkpxe and pxe - I got “selected boot device failed”. When it was incorrectly set to prelinux.0 I got the kernel panic-not syncing error.
Installed tftp on my windows station, tried to do tfpt -I x.x.x.x get undioly.kpxe and received the following error:
Timeout occurred, connect request failed.
On the fog machine: Ran tftp -v x.x.x.x -c get undionly.kpxe and got:
Connected to x.x.x.x (x.x.x.x), port 69
getting from x.x.x.x:undionly.kpxe to undionly.kpxe [netascii]
Received 92617 bytes in 0.3 seconds [2762316 bit/s]
Then, ran service tftp-hpa status and received tftp-gpa:unrecognized service
Ran cat /etc/xinetd.d/tftp results looks correct.
Ran cat /etc/default/tftpd-hpa and got "cat: /etc/default/tftp-hpa: No such file or directory

I hope it will give you a better insight,

Thanks for all the help

Tom

[Wayne Workman]

@Tom said:

I have 2 domain controllers in one subnet providing DHCP to workstations (70/30 rule)

that rule will cause clients to sometimes not get an IP.

70/30 means 70% of your available range is given out by one server, 30% by the other.

However, the load is 50/50. Both DHCP servers hear all DHCP Discoveries, both attempt to hand out an address. Whichever one is first wins normally unless you have one set as authoritative (which nobody does it seems).

When the one that has 30% of the range assigned to it runs out of available addresses, it’ll respond to clients that no addresses are available and the client will then auto-configure with APIPA.

Anything other than 50/50 is almost always not a good idea - and is easy to mess up and break.

[MRCUR]

@Tom If you’re going to run multiple DHCP servers (I assume you’re trying to get some HA out of it), then you really should be using the built in DHCP Failover setup that Windows provides. It’s far easier to manage than what you’ve got now.

I’ll also note that you should really consider moving DHCP services off of a DC.

[Tom]

@Wayne-Workman as much as I agree with you, that decision was made above me. Also, I have never encountered any issue with this setup.
In terms od fog, I never had any issue while running 0.31.

[Wayne Workman]

@Tom Well I mean, if the lease time is short enough or if you have a large enough pool of addresses on the 30% range DHCP Server - or a mixture of those two things - then you might never have problems.

But I say what I say because the potential is there. It’s happened here where I work.

We have a DHCP server that serves 100% of a range, and we had an old mac server - we used it for OpenDirectory for our Macs and for Deploy studio. It was configured to run DHCP for a very small subset of our range, and at the very end of our range - and we always kept that turned off unless we were using Deploy Studio. Well one day it was turned on somehow accidentally (not by me) and because the range was so small (256), it ran out of IPs quickly, and then our entire building suddenly started not getting addresses and auto-configuring with APIPA. Keep in mind that thousands and thousands of addresses were still available from our actual DHCP server - and it was even responding to requests, it’s just that the old mac server was beating it and serving addresses faster… or in this case, serving “no more addresses available” messages faster.

[Wayne Workman]

@Tom said:

Installed tftp on my windows station, tried to do tfpt -I x.x.x.x get undioly.kpxe and received the following error:

try tftp –i x.x.x.x get undionly.kpxe

you have typos in your above command. tftpt and the -i should be lower case.

If it still doesn’t work, sounds like a network thing or firewall thing. Can you ping the fog server from this windows box? ssh into it?

[Tom]

@Wayne-Workman So, disabled the firewall on my win 10 machine. Ran tftp -i x.x.x.x get undionly.kpxe successfully.
I’m not sure why target machine cannot boot to pxe.

Thanks,

Tom

[Wayne Workman]

@Tom On all the DHCP servers, please set options 066 and 067. 66 should be the FOG server IP, 67 should (generally) be undionly.kkpxe

If you need help doing that - or have questions, please PM me so we can work much faster.

[george1421]

I think we are at the point where we are going to need to see a packet capture of what is really going down the wire with these dhcp servers. Your current setup is not standard, for sure. What we will need for you to do is setup wireshark (or other tool to collect a pcap file) on a mirrored port. Select the source of the mirror the port where the target computer you are trying to boot is connected. Set the filters on wireshark to “bootp || tftp”. Once you have wireshark collecting data boot the target computer until it fails then stop wireshark. Make the time between starting wireshark capture and booting the target computer as short as possible.

Post the pcap file here. There are several people in the forums that can decode it, even without a magic decoder ring. Also please note the ip address of the dhcp server(s)

[Wayne Workman]

A mirrored port is not necessary. You can do a capture directly on your FOG server like this: https://wiki.fogproject.org/wiki/index.php?title=TCPDump

Also, just to collect DHCP data, you don’t need to do anything but just run a capture in Wireshark on a computer that’s on the same network as the computer’s you’re trying to fog. DHCP Discoveries and replies are broadcast messages - they go throughout the entire broadcast domain.

[george1421]

@Wayne-Workman The mirrored port suggestion was to also capture the unicast tftp requests from the point of view what the target is specifically seeing.

[Tom]

@Wayne-Workman WOW, I don’t know what change, but it’s working now. I was able to register the OptiPlex 990 and the Latitude E7240.
Now I have to figure out the new interface, since it’s very different from 0.31.

THANK YOU ALL FOR YOUR HELP, I WOULD NOT BE ABLE TO DO IT WITHOUT YOU.

Tom

[Wayne Workman]

@Tom But does it work 5 times in a row…

[george1421]

@Tom I want to be wrong here, but my intuition is telling me you are in the 30% category right now, where its working.

I hope for your sake you have fixed it so you can move on to greater things. If not, capture a pcap file when it fails and post back here. For now I’ll mark the thread as solved. We can change it back if we find out otherwise.

[Tom]

@Wayne-Workman Tested it 3 times, I hope it will working properly.

Thanks for all your help.

Tom

[Tom Elliott]

@Tom So what, exactly, did you have to do? After the problems that were shown by changing out all the dhcp servers to use undionly, nothing was working.

[Tom]

@Tom-Elliott I’m not sure what exactly happened.
I turned off the firewall on my workstation and made sure tftp answers. Then I changed option 67 from kpxe to kkpxe as Wayne suggested and it worked.
I did not work before.
I’ll if it’s continue to work properly over time.
Maybe when tftp answered, it kicked something in Ubuntu
Sorry I cannot be more helpful.
I hope I did not create to much headache.

Thanks for all your help.
Tom

Tom

[Sebastian Roth]

I am wondering if we’ll ever find out what caused the kernel panic?? This is my major concern as we have seen those kernel panics caused by very different issues lately. From what I am getting between the lines the change from pxelinux.0 or undionly.kpxe to undionly.kkpxe made hugh difference. I don’t count the TFTP hickups as kernel bootup is way past that.

Do we have a wiki article on kernel panics and debugging yet? I feel like we have made some progress on that in the last weeks. Checksum in the installer is a major step but as well earlyprintk in the kernel and efi_wrap in iPXE if it gets really ugly. Not sure if this is way to complex to document in the wiki?! Not to forget trying different iPXE binaries (kkpxe)… although I am still wondering why this has helped here as George has booted the same model without an issue.