Upgrade to Trunk, Kernel Panic
-
@george1421 said in Upgrade to Trunk, Kernel Panic:
@SaxxAppeal Would you post the complete line from your dnsmasq for this prefix: pxe-service=X86PC
@Quazz I may have been reading more into what the OP didn’t say than reality.
The line you requested is as follows:
pxe-service=X86PC, "Boot from network", pxelinux
-
@george1421 THIS WORKED!!!
I renamed the pxelinux.0 file to something else, and created the sym link… Booted right in!
I’ll continue to test with some other machines, if anyone else has any other tidbits to contribute please let me know!
-
Good to know. So my list of suggestions was spot on!
@SaxxAppeal Can you please try booting the Dell Optiplex 745 as well. We have another user having trouble with just that machine model!
-
@Sebastian-Roth Tried the 745 and the Lenovo notebook, both are perfect.
Only other thing that has been happening is when I PXE boot, I get the following prompt:
“Please enter TFTP server:”
When I enter it, everything goes through fine and it brings up the FOG menu. I’m sure it’s just an argument that needs to be passed, but not sure where I need to specify this. Any ideas?
-
@SaxxAppeal The TFTP server (next-server option) should be send by the DHCP server (dnsmasq in your case). Maybe try adding your FOG server IP address to the pxe-service line:
pxe-service=X86PC, "Boot from network", pxelinux, x.x.x.x
As well let us know what you have for
dhcp-boot=
in your config. -
While this isn’t an official document I did write a kb a while ago that gave guidance setting up dnsmasq under centos: https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7 So Sebastian’s recommendation for the next server in the config file is spot on.
-
@Sebastian-Roth I need to add, remove the pxelinux side (unless you are requiring use of the pxelinux.0 file.)
-
@Sebastian-Roth Got it, that’s what I figured. I’ve been trying to figure out where I need to pass the FOG server address, so far no luck.
Requested info:
dhcp-boot=/tftpboot/ipxe.krn
I’ve played with this line over the last week, but it seems to work great this way.
-
Sure, even better symlink
undionly.kpxe
asundionly.0
and use:pxe-service=X86PC, "Boot from network", undionly, x.x.x.x dhcp-boot=undionly.kpxe, x.x.x.x, x.x.x.x
[edit] That’s another thing I hate about dnsmasq - there are options that seem to do the same kind of thing and I had to study the code to find out which is doing what - and sure I forgot again already [/edit]
-
@Sebastian-Roth The symlink works as well… But still asks me to enter the TFTP server. I think its just a matter of knowing exactly where and how to pass the FOG IP to dnsmasq…
-
@SaxxAppeal Just figured it out!!
the boot line should read:
dhcp-boot=undionly.kpxe,, XXX.XXX.XXX.XXX
The double comma is required because it expects the server name first, then the IP.
Hope that helps someone…
Thanks EVERYONE for your help on this!!
-
@Sebastian-Roth said in Upgrade to Trunk, Kernel Panic:
@SaxxAppeal said:
bzImage: x86 boot sector
A while back already I noticed that the
file
command does not output all the valuable information on all distros. What it does is kind of simple. It reads the first couple of bytes of a file and compares it to known signatures (https://en.wikipedia.org/wiki/List_of_file_signatures). Seems like the ubuntufile
command does detect the kernel as simple x86 boot sector and therefore does not print out the kernel version. Very sad because I really love that little tool. So maybe I have to get around this by pointing people to check the kernel version via the web gui - although this only works when the kernel image is in place but nor for checking the version of any bzImage you have lying around.@george1421 said:
Strange on my prod server and dev box they both say x86, not sure if that is a type-o or what. I can see from an ls command that bzImage IS larger so that is probably the x64 image.
Although the
file
command is powerful (e.g. even prints the partition table if you runfile d1.mbr
) is does not distinguish between 32 or 64 bit kernel. I don’t know the kernel binary structure enough but I guess detecting a 64 bit bzImage from a 32 bit one is beyond the capability of a simple tool likefile
which just compares a few byte ranges…Ok, back to the initial question. George is right that the kernel panic essentially means that the kernel was not able to find it’s root device (which we have packed completely into the init(_32).xz file!). This can be caused by different reasons:
- init(_32).xz missing / wrong filename - in the output you posted I see init_32.xz.1, sure you have the file named like that? Shouldn’t hurt I suppose but maybe try re-naming/-configuring it to init_32_1.xz to see if it makes a difference
- using the old pxelinux.0 for PXE booting (although I still haven’t had the time to find out why that is!) - use ipxe binaries for PXE booting, e.g.
undionly.kpxe
- init(_32).xz corrupt - broken download (shouldn’t happen with FOG trunk anymore)
- 32/64 bit mixed, e.g. bzImage32 / init.xz or vice versa
- Missing
initrd=init..
kernel command line parameter - bzImage32 / init_32.xz booted on a 64 bit architecture (although this usually yields in a different error from what I know)
Possibly something else I missed!? Please add other things you know so I can add this to the wiki soon!
Bumping this post - this one is all yours, @Sebastian-Roth
-
Thanks @Wayne-Workman for reminding me. Added to the wiki now (see my signature). The article is still missing a lot of details about the boot process and all the issues one might run into.