Re: How to debug: Initramfs unpacking failed: junk in compressed archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



El 24/10/13 12:17, Richard W.M. Jones escribió:
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 to discard overlapping memory issues:

1) I create the uImage files that look like this:

[alex@avillacis linux-git]$ mkimage -l /run/media/alex/BOOT/uImage
Image Name:   mcuzone-3.5.6-1.fc17
Created:      Mon Apr  1 14:04:10 2013
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    3448056 Bytes = 3367.24 kB = 3.29 MB
Load Address: c0008000
Entry Point:  c0008000
[alex@avillacis linux-git]$ mkimage -l /run/media/alex/BOOT/initramfs-mcuzone.img
Image Name:   mcuzone-initramfs-3.5.6-1.fc17
Created:      Wed Oct 23 11:46:59 2013
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:    7861736 Bytes = 7677.48 kB = 7.50 MB
Load Address: c8000000
Entry Point:  c8000000

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.

The board memory goes from 0xc0000000 to 0xcfffffff. The target address for the initramfs is now at the 128 MiB boundary. The initramfs itself checks ok with gzip -t even with the padding. The file itself is 7.50Mb and decompresses to 17 MB.

Now, to the bootloader:

U-Boot > setenv bootargs root=/dev/mmcblk0p2 rw rootwait ip=off initrd=0xc8000000,7861736 keepinitrd; mmc rescan 0; fatload mmc 0 0xc0700000 uImage; fatload mmc 0 0xc4000000 initramfs-mcuzone.img; bootm c0700000 c4000000;
reading uImage

3448120 bytes read
reading initramfs-mcuzone.img

7861800 bytes read
## Booting kernel from Legacy Image at c0700000 ...
   Image Name:   mcuzone-3.5.6-1.fc17
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3448056 Bytes = 3.3 MiB
   Load Address: c0008000
   Entry Point:  c0008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at c4000000 ...
   Image Name:   mcuzone-initramfs-3.5.6-1.fc17
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    7861736 Bytes = 7.5 MiB
   Load Address: c8000000
   Entry Point:  c8000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

The initrd= parameter is at the target address of 0xc8000000 ... check.
Loading the kernel uImage at 0xc0700000 , 3MiB ... no overlap so far, check.
Loading the initramfs uImage at 0xc4000000 (64 MB boundary), 7.5 Mib ... no overlap so far with anything else, check.
The bootm command receives the addresses and checksums them... check.

... but I still get the same kernel error message "junk in compressed archive".

So I get a system that mounted the SD as root, without the initramfs. I want to peek into physical address 0xc8000000 to check if the initramfs data is there at all, so I attempt this:

[root@elx ~]# LANG=C dd if=/dev/mem of=dump bs=1 skip=3355443200 count=7861736
dd: reading `/dev/mem': Operation not permitted
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.0184769 s, 0.0 kB/s

The value of 3355443200 is 0xc8000000.

So, I cannot even access the memory to check on it. What else can I try, while waiting for the debug kernel to compile?
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux