Kernel for Ubuntu 64 bit

[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.

[Tom]

@Sebastian-Roth I don’t have deep understanding of FOG internal works, but I can say that when option 67 was set to prelinux.0 the kernel panicked.