I'm using debian live-build to work on a bootable system. By the end of the process i get the typical files used to boot a live system: a squashfs file, some GRUB modules and config files, and an initrd.img file.

I can boot just fine using those files, passing the initrd to the kernel via


on the bootloader command line. But when I try to examine the contents of my initrd image, like so:

$file initrd.img
initrd.img: ASCII cpio archive (SVR4 with no CRC)
$mkdir initTree && cd initTree
$cpio -idv < ../initrd.img

the file tree i get looks like this:

$tree --charset=ASCII
`-- kernel
    `-- x86
        `-- microcode
            `-- GenuineIntel.bin

Where is the actual filesystem tree, with the typical /bin , /etc, /sbin ... containing the actual files used during boot?

  • The 'lsinitramfs' command was designed for this. – earlgrey Aug 5 '18 at 15:50

The cpio block skip method given doesn't work reliably. That's because the initrd images I was getting myself didn't have both archives concatenated on a 512 byte boundary.

Instead, do this:

apt-get install binwalk
legolas [mc]# binwalk initrd.img 
0             0x0             ASCII cpio archive (SVR4 with no CRC), file name: "kernel", file name length: "0x00000007", file size: "0x00000000"
120           0x78            ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86", file name length: "0x0000000B", file size: "0x00000000"
244           0xF4            ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode", file name length: "0x00000015", file size: "0x00000000"
376           0x178           ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode/GenuineIntel.bin", file name length: "0x00000026", file size: "0x00005000"
21004         0x520C          ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"
21136         0x5290          gzip compressed data, from Unix, last modified: Sat Feb 28 09:46:24 2015

Use the last number (21136) which is not on a 512 byte boundary for me:

legolas [mc]# dd if=initrd.img bs=21136 skip=1 | gunzip | cpio -tdv | head
drwxr-xr-x   1 root     root            0 Feb 28 09:46 .
drwxr-xr-x   1 root     root            0 Feb 28 09:46 bin
-rwxr-xr-x   1 root     root       554424 Dec 17  2011 bin/busybox
lrwxrwxrwx   1 root     root            7 Feb 28 09:46 bin/sh -> busybox
-rwxr-xr-x   1 root     root       111288 Sep 23  2011 bin/loadkeys
-rwxr-xr-x   1 root     root         2800 Aug 19  2013 bin/cat
-rwxr-xr-x   1 root     root          856 Aug 19  2013 bin/chroot
-rwxr-xr-x   1 root     root         5224 Aug 19  2013 bin/cpio
-rwxr-xr-x   1 root     root         3936 Aug 19  2013 bin/dd
-rwxr-xr-x   1 root     root          984 Aug 19  2013 bin/dmesg
  • Indeed, your answer beats mine. I haven't ever thought that alignment would be a problem. I wonder, though, if cpio would give some more interesting output if the first image contained within the multi-image file was not 512B-lined. – user986730 Mar 25 '15 at 16:52
  • How to revert it back (repack to original state) after modifying, with the same folder hierarchy ? – EdiD May 25 '16 at 9:39
  • 2
    Just cd into the directory where you extracted your cpio archive, run find | cpio -H newc -o > /tmp/my_archive.cpio, then gzip it with gzip /tmp/my_archive.cpio and finally, concatenate it with the with the microcode image, if you had one: cat my_microcode_image.cpio /tmp/my_archive.cpio.gz > mynewinitrd.img. If you didn't have a microcode image, then you can just use you gzipped file as is in your bootloader – user986730 Jun 2 '16 at 12:50

It turns out the initrd generated by Debian's live-build (and to my surprise, accepted by the kernel) is actually the concatenation of two images:

  • a CPIO archive containing microcode updates to be applied on the processor;
  • a gzip-ed cpio archive, which actually contains the initrd file tree (with the /etc /bin /sbin /dev ... directories that were expected).

Upon extracting the original initrd.img, straight out of the live-build output, I got this output:

$cpio -idv ../initrd.img
896 blocks

Which means that the cpio extraction ended after parsing 896 blocks of 512 Bytes each. But the original initrd.img was way bigger than 896*512 = 458752B = 448 KB :

$ls -liah initrd.img
3933924 -r--r--r-- 1 root root 21M Oct 21 10:05 initrd.img

So the actual initrd image I was looking for was appended right after the first cpio archive (the one containing the microcode updates) and could be accessed using dd:

$dd if=initrd.img of=myActualInitrdImage.img.gz bs=512 skip=896

If you know your initrd.img consists of an uncompressed cpio archive followed by a gz-compressed cpio archive, you can use the following to extract all files (from both archives) into your current working directory (tested in bash):

(cpio -id; zcat | cpio -id) < /path/to/initrd.img

The above command-line passes the contents of initrd.img as standard input into a subshell which executes the two commands cpio -id and zcat | cpio -id sequentially. The first command (cpio -id) terminates once it has read all the data belonging to the first cpio archive. The remaining content is then passed to zcat | cpio -id, which decompresses and unpacks the second archive.

  • 1
    This looks like the cleanest solution by far – velis Jan 30 '17 at 8:38
  • 1
    It works beautifully – TurboHz Jun 7 '18 at 17:28
  • Mysteriously, @woolpool's fine answer is the sole answer that user has ever posted. That's style. If you were going to post only one answer during your entire StackExchange career, then you could hardly do better than to post one such as this. OP might consider changing the accepted answer to this one. – thb Dec 1 '18 at 13:07

If you need to perform this task often, you may want to create a small bash function like the following (and maybe add it to your .bashrc):

initramfs-extract() {
    local target=$1
    local offset=$(binwalk -y gzip $1 | awk '$3 ~ /gzip/ { print $1; exit }')
    dd if=$target bs=$offset skip=1 | zcat | cpio -id --no-absolute-filenames $@

The code is based on Marc's answer, but it's significantly faster since binwalk will only look for gzip files. You can invoke it, like this:

$ initramfs-extract /boot/initrd.img -v

You will need binwalk installed to make it work.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.