On Thursday, May 20, 2010 03:32:36 pm you wrote:
Ugh.
I can think of two things that might be useful.
Add a print statement into mkelfImage that prints the value of kernel_alignment Most of the fields are already printed so this just requires tweaking linux-i386/convert_params.c
Where you still have a reboot in the kexec case I am a little curious if everything applied ok.
I'm more curious, myself, at what happened in the past couple of hours to the hard drive... I've literally done __NOTHING__ to the binary generated, and nothing to the script I used (the script removes the old .ebi, uses mkelfImage to generate a new one, then kexecs it).
Three hours ago, it behaved exactly as I said. I moved on to an entirely different task, and decided to revisit it after your reply.
Now it is working, and its behavior is consistent between kexec and etherboot. I'm a bit WTF'd out about that... but I'll take the victory where I can get it.
That being said, the program that calls mkelfImage (which you knew as cwx), runs the following command: mkelfImage --command-line="some stuff here" --kernel=kernelBinary --ramdisk- base=20971520 --ramdisk=ramDiskPath --output=file
The .ebi files generated are the ones that are returning:
Loading x-slam://10.0.10.1:10006/239.192.0.131:10006 .....(ELF)... done Firmware type: LinuxBIOS
(and then does nothing)
And that appears to be due to the --ramdisk-base= argument. Simply increasing the size allows the kernel to start - but then fails as it can't load the ramdisk.
I'm a bit unclear on what --ramdisk-base actually does; so I'm willing to venture that it may be the source of our problem. I'll see what else I can figure out tomorrow. If you can enlighten me for the purpose of ramdisk-base, I'd appreciate it. (What an initrd load address is/means isn't something I know offhand). I'm going to look that up as well, but for now, I have to call it a night.