Troy Telford ttelford.groups@gmail.com writes:
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.
ramdisk-base is just where in ram to load the ramdisk. mkelfImage defaults to 8M. You are setting it to 20M. With the change to kernels to default them to running at 16M that only leaves 4M for the kernel which I expect is to little. Because mkelfImage is old and the hack is crude I don't mkelfImage is to stupid to realize that we have a problem.
Eric