"Invalid or corrupt kernel image" -- except it isn

[thekorn]

This should be a fun one...

I have two boxes, one real one with a core2duo and a foxconn motherboard, and another virtual machine running inside VMWare. (Which would make it, I guess, a "vmware motherboard".) Both of them are exhibiting an identical problem when booting minimyth.

I've set up my tftp server, and it's serving pxelinux.0 just fine. But the problem comes with the handoff to loading the kernel. Every time you cold boot either the real (physical -- foxconn) or virtual (not physical -- vmware) machine, you get a "invalid or corrupt kernel image". (I apologize for using screenshots, but as the OS isn't actually loaded that's the only way to get the information, outside of lots of retyping.)



Now here's the weird part... As far as I can tell, the kernel image on the tftp server is just fine. Why do I say that? Because I can get either machine to boot by hitting enter!



In other words, not changing any files on the server, not throwing any flags, just basically saying "try again" causes both the VMware and real hardware systems to continue booting every time.

Anyone seen this before? And/or have any ideas on how to work around it?

Thanks!

(Happy to do any commands to help diagnose the problem, though the VMware machine has additional issues apparently stemming from the virtual video card that I haven't even started to dig into yet. I do have a fully working ubuntu frontend in an identically configured VM that I could use to do hardware probes, so not all is lost.)

[thekorn]

And here is the contents of pxelinux.cfg/default:

Code: Select all

DEFAULT minimyth-ram

LABEL minimyth-ram
        KERNEL minimyth-0-21.0-61/kernel
        APPEND ro root=/dev/ram0 ramdisk_size=96000 initrd=minimyth-0-21.0-61/rootfs


[Pablo]

MiniMyth bundles the PXELINUX loader (pxelinux.0). Are you using that one? If not, could you try using it rather than the one that comes with you distribution and let me know whether or not it works?

[thekorn]

MiniMyth bundles the PXELINUX loader (pxelinux.0). Are you using that one? If not, could you try using it rather than the one that comes with you distribution and let me know whether or not it works?

Hey Pablo, thanks for the reply. I'm using the pxelinux.0 file that was included with minimyth. (The ubuntu installation is a traditional hard disk based instalation, not a network booter.)

[thekorn]

Well, this certainly was a weird one.

For giggles, I backed down pxelinux.0 to version 3.63. That shed some illumination -- now pxelinux.0 wouldn't load at all! (pxe complained about the tftp server not supporting tsize.... pound google and the syslinux wiki if you want the gory details.)

Turns out the problem was that I had my tftpd on a ubuntu (hardy) machine, and the default tftpd package is essentially broken. Or at least, broken from a pxelinux standpoint.

The solution is to remove the stock tftpd, and replace it with tftpd-hpa. (Apparently the hpa version supports the tsize command which pxelinux requires.)

Code: Select all

sudo apt-get remove tftpd
sudo apt-get install tftpd-hpa

Changing the tftp daemon to tftp-hpa allowed pxelinux.0 ver 3.63 to boot, and also fixed the problem of needing to hit enter when loading pxelinux.0 ver 3.72 .

As a nice side bonus, tftpd-hpa is a shade under six bigzillion times faster at serving the images than the stock tftpd daemon. So there's a good reason to do it regardless of the annoying "hit enter to continue" problem.

Now, on to slay other problems. (sigh)

[Pablo]

That is some good detective work.

I have updated the pxelinux version bundled with MiniMyth to 2.72. In theory, the 2.72 should not require tsize support. Hopefully, this update will prevent others from have the same problem in the future.

Based on your detective work, I wondering whether or not the difference I see between the TFTP and HTTP speeds is due to using a sub-standard TFTP server. Well, given that I prefer gPXE+HTTP to pxelinux+TFTP, I am unlikely to ever take the time to find out.