1

I'm new here, hope I'm posting in the right section...

Well, I got the initrd.img of debian 3.16.0-4-686-pae (downloaded and burned whole iso). If I boot from disk or lan initrd is ok, everything boots just fine.

The problem begins when I want to add a driver to the initrd. I take the file initrd.img and I extract it. I only get 1 directory named kernel. After searching around I found a thread with the same issue here and tried his solutions (Thread link: Why is it that my initrd only has one directory, namely, 'kernel'?).

I tried with cpio which only extracted 1410 blocks, after dd from 1410 to end of archive I get an archive (if it matters, it's only readable if I name it name.tar.gz ) that contains all folders and everything but it is somewhat damaged, some files there are sized 0 (sh and bash for example which makes any initrd I'll try to create from this useless and unbootable with eror: Sh found but cant be executed. Same with shell).

If I use the binwalk solution on the same thread I managed to extract an archive from the initrd but that archive only contains 3 folders (bin, etc, lib) with out all of the files. (No sh or bash for example).

Note - According to binwalk the initrd contains:

1 - ascii archive

1 - xz compressed data

30 - gzip compressed data archive which according to binwalk are

from NTFS file system (NT) NULL date: Thu jan 1 00:00:00 1970

All of them are less than 1MB.

So pretty much I'm unable to add a driver to this initrd.img file because of it's format... Any help would be appreciated, if more information is needed let me know I'll do my best to provide it.

Tl;dr I got weird initrd.img file I can't seem to be able to add a driver to.

Binwalk output:

Note that I edited the file, the beginning of it are files from the ASCII archive, all other things I've removed are the date of the gzip compressed archives, all of which are, as stated: Thu 1 Jan 00:00:00 1970 (I believe that since this is epoch date, maybe it is unable to read their real date for some odd reason...)

Any help would be appreciated, let me know if more information is needed I'll do my best to provide it, thanks :)

Forgot to mention - all the commands I'm running and using are on Ubuntu 3.16.0-30-generic (I think it's trusty)

Improve this question

1 Answer 1

Reset to default
1

First, if it boots fine I would look at how you extract the img file. The image is in tact.

For Redhat/Fedora initrd images I use the following method:

# This should confirm it is a gziped image    
file initrd0.img 

# This should leave you with unzipped initrd0 (no .img)
# The -d is decompress, the -S is to expect the .img suffix not the usual .gz
gzip -dS .img 

# This should show confirm it is now a cpio archive
file initrd0

# Create a directory to unpack to
# and unpack inside the new directory
mkdir new-init 
cd new-init
cpio -id < ../initrd0

I added comments to some of the "less than obvious" lines above. The idea is to confirm we have the proper file type before we try to unpack. If the output of each file command is different than expected (gzip file first and cpio after) then you must use the appropriate tool to unpack.

Improve this answer
6
  • Thanks for your input, I'll check it tomorrow as this happens at work and not at home PC. If this helps, I already tried the file command on my initrd at first and it told me it's ASCII file. After I extract everything other than the first ASCII archive (dd if=initrd.img of=arc.tar.gz bs=512 skip=1410) to a different archive and run file on that I get XZ compressed archive. Pretty much the same as binwalk tells me.
    – Dan Baruch
    Mar 26, 2015 at 22:30
  • Ok so, this is what I get, can't seem to newline, sorry: file initrd.img -> ASCII cpio archive. Thats the first archive which I don't need so I dd'ed to get the XZ archive (dd if=initrd.img of=initrd2.img bs=512 skip=1410. I verified I'm not talking the file from middle of archive or something like that). I then run file on initrd2.img -> XZ compressed data. If I run the gzip command you provided I get "not in gzip format". If I try unxz or something like that I get "unknown file suffix".
    – Dan Baruch
    Mar 29, 2015 at 8:06
  • If I rename the file to initrd2.xz and re-run unxz I get a readable archive how ever it's not good. The bash there is 0 bytes, same as sh, there are files called "[" and "[[", which I believe not really exist in normal initrd... Either way, having sh and bash at 0 bytes means I can't remake a bootable initrd from this (I tried and got "sh exists but can't execute", same with bash) Sorry I splitted it to 2 comments, it didn't allow me to post it as one...
    – Dan Baruch
    Mar 29, 2015 at 8:07
  • Maybe I am misunderstanding but it seems like when you first run the file command it says that you have a cpio archive. If that is the case, then start with the cpio steps (mkdir, cd, cpio -id, etc...). There should be no need to use the 'dd' command in this entire process. The point of using the 'file' command is to tell you what you are working with. If it is gzip, use 'gzip' command, if cpio archive, use the 'cpio' command, etc... dd just makes a raw image, not a gzip/cpio/xz archive.
    – David Dreggors
    Mar 30, 2015 at 13:31
  • What I would do is delete what you have, re-copy the initrd.img file from Debian disk (or where ever you get it from), and start fresh. Then with a fresh image, use the file command to see what you have. Use the appropriate tool to unpack it. Once unpacked, if you have a single file, use the file command again. Follow this pattern until you have a file system unpacked. At the end of the day, the contents of the initrd.img is a small but complete root filesystem.
    – David Dreggors
    Mar 30, 2015 at 13:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .