[SOLVED] initrd/vmlinuz issues: Losing my mind...

[MultimediaMan]

Sometime between March and now, I've discovered a problem with my home network boot solution.

ALL Linux distros I use (CentOS/ Scientific Linux/ VMware ESX 4.1) which use the standard initrd/vmlinuz load combinations panic at pretty much the exact same point during the net boot.

The messages are, without fail, are some variation of "Failed to find Ramdisk at 0..."

Googling reveals this message to be usually the result of a corrupted image. CRC checks on the actual files are good (The installation ISOs are mounted as iso9660 Read-Only File systems)

The problems seem to be occurring after I rearranged the directory structure.

This leads me to wonder: Is there is a directory depth limitation with either iPXE or the Linux kernel itself?

http://andromeda.olympus.bv.ar.us.local/...initrd.img

and

http://andromeda.olympus.bv.ar.us.local/...ot/vmlinuz

These addresses will not resolve outside my network, and are for information only.

Both load fine in iPXE, but I wonder if the directory path length might be too deep for Anaconda? Maybe around 127-128 characters?

Thoughts?

[robinsmidsrod]

Why would that matter, once the kernel and initrd is loaded, they are in memory, and the initrd behaves like a mounted filesystem. I can't imagine that anything in your kernel would actually care what your kernel or initrd is actually named, it only cares about the kernel cmdline you've specified.

You are absolutely sure that you don't have bad hardware?

Have you actually tried with a shorter path, and does that make any difference?

[MultimediaMan]

(2013-06-08 20:29)robinsmidsrod Wrote:  Why would that matter, once the kernel and initrd is loaded, they are in memory, and the initrd behaves like a mounted filesystem. I can't imagine that anything in your kernel would actually care what your kernel or initrd is actually named, it only cares about the kernel cmdline you've specified.

You are absolutely sure that you don't have bad hardware?

Have you actually tried with a shorter path, and does that make any difference?

Haven't tried the shorter path yet; the behaviour is the same with a virtual server or a physical. I'm pretty sure it is the path length/ depth. I've pretty much ruled out iPXE... my thought is when the kernel goes looking for the path in the image arguments, it seems to lose it's way. I've put the ask out to find out of there are any limitations. I'll shorten the path and see how things go. But I wanted to couch this with the forum beforehand.

[MultimediaMan]

Tried shortening the path: no change (new directory upload)
Tried going with undionly: no change

Tried physical and virtual clients on both of the above scenarios: no change.

The Server is not reporting any errors on the port.

I have a mothballed server with a previous version all of this I'm going to spin back up... will report back later.

[MultimediaMan]

It is NOT the iPXE build nor is it an issue with a script. I was able to build the latest iPXE with a previous script for an older environment without issues. But running on a different platform: Not CentOS 6.4 x86_64. Investigating further as time permits...

[MultimediaMan]

Found the issue... and it's what I suspected all along...this was in my personal Dev environment, so thankfully it did not impact anyone.

The issue relates to how kernel arguments are passed to vmlinuz in RedHat-based distros...

Be careful that your kickstart path is not more than than 8 directories deep and/or no more than about 100 bytes in length total. I haven't really had the chance lately to investigate these limits extensively, and online documentation is thin/non-existent on this particular subject.

[MultimediaMan]

Interesting development: when testing the Directory Depth/ Directory length hypothesis... I found all worked with "generic" names...

Code:

${17}/verrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrylongfilepath/ks.cfg

or

Code:

${17}/1/2/3/4/5/6/7/8/9/10/ks.cfg

But they really had issues with a path which had BOTH a length exceeding 96 Bytes and a period "." in the path. Strange.

[robinsmidsrod]

I'm glad you figured it out. This is really something odd. I would suggest you add it to the relevant RHEL wiki. Does this only affect iPXE-based deployments or also pxelinux/syslinux?