Eric W. Biederman wrote: > Ollie Lho <[EMAIL PROTECTED]> writes: > > >>ollie mkelfImage 70:objdump -p elfImage >> >>elfImage: file format elf32-i386 >> >>Program Header: >> LOAD off 0x00001000 vaddr 0x00010000 paddr 0x00010000 align 2**12 >> filesz 0x00001478 memsz 0x00005720 flags rwx >> LOAD off 0x00003000 vaddr 0x00091000 paddr 0x00091000 align 2**12 >> filesz 0x00000028 memsz 0x00000028 flags rwx >> LOAD off 0x00004000 vaddr 0x00100000 paddr 0x00100000 align 2**12 >> filesz 0x00154660 memsz 0x00154660 flags rw- >> >>Still no section as >> >>Loading Section: addr: 0x0000000000000000 memsz: 0x0000000040000000 filesz: >>0x0000000000000018 >> > > O.k. All of the segments load o.k. and then there is an extra segment > it attempts to load. > > So what is the extra segment. > > For a known good kernel I have. > Program Header: > LOAD off 0x00001000 vaddr 0x00010000 paddr 0x00010000 align 2**12 > filesz 0x00001538 memsz 0x000057e0 flags rwx > LOAD off 0x00003000 vaddr 0x00091000 paddr 0x00091000 align 2**12 > filesz 0x00000028 memsz 0x00000028 flags rwx > LOAD off 0x00004000 vaddr 0x00100000 paddr 0x00100000 align 2**12 > filesz 0x000db97a memsz 0x000db97a flags rw- > LOAD off 0x000e0000 vaddr 0x00800000 paddr 0x00800000 align 2**12 > filesz 0x00000000 memsz 0x00000000 flags rw- > > Which has an extra unused segment for a ramdisk if it ever appears. > > Ollie my hunch is that last segment is getting corrupted for you. > At this point I don't know where or why. > > Could you try to get it to work without stripping the output of > mkelfImage. I will try to reproduce the problem by stripping an > image. That is my only guess so far. >
Why mkelfImage always generate a .ramdisk section even though I don't use/want a ramdisk ?? Ollie
