Here is how I generate the ramdisk
mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -e 0x00000000
-n "ramdisk" -d /boot/initramfs-X.YY.Z-foo.fcNN.armv5.img /tmp/uImage
Note the address and entry point are zeros.
On your board's u-boot environment just run the 'bdi' command (board
info) to findout the start addr and size.
You can workout load addr's that make your boot happy.
I would advise loading the ramdisk first, in the begining space of the
memory... then load the kernel.
That way if there is any overlap it will be the ramdisk that is
corrupted, not the kernel memory.
Regards,
-Jon Disnard
On Tue, Oct 22, 2013 at 4:06 PM, Alex Villací­s Lasso
<a_villacis(a)palosanto.com&gt; wrote:

Here is how I generate the ramdisk
mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -e 0x00000000
-n "ramdisk" -d /boot/initramfs-X.YY.Z-foo.fcNN.armv5.img /tmp/uImage
Note the address and entry point are zeros.
On your board's u-boot environment just run the 'bdi' command (board
info) to findout the start addr and size.
You can workout load addr's that make your boot happy.
I would advise loading the ramdisk first, in the begining space of the
memory... then load the kernel.
That way if there is any overlap it will be the ramdisk that is
corrupted, not the kernel memory.

How do I peek into the initramfs memory from within the Linux system, in order to check
the actual contents to see where the corruption is? Is there any block device to check?

Hello Alex Lasso,
Sorry about that.
To be clear... the normal way to generate the uInitrd is to specify
the address and entry point with all zero's.
(as demonstrated in the example)
However, when you go about actually loading the uInitrd... you do
specify a valid load address, one sufficiently separate from the
kernel load addr so the two memories do not overlap.
My best guess is your ramdisk is large, and being corrupted by it's
memory address being going out of bounds, or overlapping with kernel.
One of the most common challenges people seem to face.
Good luck.
-Jon
On Wed, Oct 23, 2013 at 11:26 AM, Alex Villací­s Lasso
<a_villacis(a)palosanto.com&gt; wrote:

How do I peek into the initramfs memory from within the Linux
system, in order to check the actual contents to see where the
corruption is? Is there any block device to check?

It doesn't work like this. When the kernel boots, it locates the
initrd and then parses it, creating files and directories as it
parses, in a tmpfs-like in-memory filesystem from the (optionally
gzipped-) cpio data. There is no block device backing it.
Because it is using gzip and cpio, the kernel is able to verify the
data looks sane as it goes along, hence the error message.
Note that recent kernels support xz compression. Not sure about your
kernel, but it might help you squeeze a little bit more into the
initramfs.
You could also try to add some debugging to init/initramfs.c (eg. in
the 'do_name', 'do_copy' and 'do_symlink' functions).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

On Wed, Oct 23, 2013 at 12:11:57PM -0500, Alex Villací­s Lasso
wrote:
> How do I peek into the initramfs memory from within the Linux
> system, in order to check the actual contents to see where the
> corruption is? Is there any block device to check?
It doesn't work like this. When the kernel boots, it locates the
initrd and then parses it, creating files and directories as it
parses, in a tmpfs-like in-memory filesystem from the (optionally
gzipped-) cpio data. There is no block device backing it.
Because it is using gzip and cpio, the kernel is able to verify the
data looks sane as it goes along, hence the error message.
Note that recent kernels support xz compression. Not sure about your
kernel, but it might help you squeeze a little bit more into the
initramfs.
You could also try to add some debugging to init/initramfs.c (eg. in
the 'do_name', 'do_copy' and 'do_symlink' functions).
Rich.

Just for the record, the actual size of the on-disk initramfs is
7861729 bytes. I padded it with 7 extra zero bytes to make the size
a multiple of 8, in case the bootloader requires an 8-byte
restriction. Why 8-byte? The kernel image got that size restriction
by chance.

Is this valid? I can not recall anyone saying they had to pad the
size of the initramfs file.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v