# genkernel initramfs file has 0 byte binaries [SOLVED]

## John Klug

I am having a problem where when I create an initramfs file I get the following error:

request_module:runaway

loop modprobe binfm-0000

loop modprobe binfm-0000

loop modprobe binfm-0000

etc.

This is due to the binary files being mostly of zero length in the gzipped cpio archive created by genkernel.  Another directory callec lib/keymaps has a bunch of zero length files.  I don't understand where the date is coming from on the binaries.  modprobe is about the only good binary file in the archive.  The text is OK.

What would cause this to happen?

I have the latest genkernel 3.4.10.904.

(chroot) livecd bin # ls -l busybox

-rwxr-xr-x 1 root root 972912 Nov 10 11:23 busybox

(chroot) livecd bin # cd /boot

(chroot) livecd boot # zcat initramfs-genkernel-x86_64-2.6.30-gentoo-r5 | cpio -ivt | grep busybox

-rwxr-xr-x   9 root     root            0 Nov  5 08:38 bin/busybox

Maybe there is a clue in the dates.  Busybox is Nov 5, and ls -l says Nov 10.  So where is it going for busybox?

cpio seems to be working correctly:

(chroot) livecd / # echo /bin/busybox | cpio -o >/tmp/busybox.cpio

1901 blocks

(chroot) livecd / # cpio -ivt </tmp/busybox.cpio

-rwxr-xr-x   1 root     root       972912 Nov 10 11:23 /bin/busybox

1901 blocks

From the log file:

```

* Linux Kernel 2.6.30-gentoo-r5 for x86_64

* busybox: >> Using cache

* initramfs: >> Initializing...

*         >> Appending base_layout cpio data...

*         >> Appending auxilary cpio data...

*         >> Appending busybox cpio data...

*         >> Appending modules cpio data...

* initramfs: >> Searching for modules...

```

It would be nice if genkernel said where the cache was located that has this bad busybox.  I set --loglevel=5Last edited by John Klug on Thu Dec 17, 2009 7:48 am; edited 1 time in total

----------

## John Klug

This appears to be a cpio bug that breaks genkernel.

genkernel uses cpio option -Hnewc, and it appears that cpio with this option cannot handle hard links.

https://bugs.gentoo.org/show_bug.cgi?id=297252

You would think something that breaks genkernel and the install wouldn't get released?

----------

## John Klug

I am not exactly sure what caused the bad sizes in the busybox links.

I reemerged genkernel, and that didn't help.

I deleted /usr/share/genkernel, and reemerged genkernel and then had a good size on /bin/busybox in my initramfs file.

I did not do anything with cpio.

Anyway, it is solved.

----------

## John Klug

I finally figured out what broke genkernel so silently.

I had screwed around with /var/tmp, and it was a symbolic link to nowhere.

I ran genkernel, and it got errors with the bad /var/tmp.

Then when I fixed the /var/tmp problem, and re-ran genkernel, the cache was bad, but genkernel did not know it, and genkernel built the initramfs with empty stuff.

Running genkernel again does not help. 

I believe I removed /var/tmp/genkernel, removed /usr/share/genkernel, did an emerge -C genkernel, then another install of genkernel.  Then when I re-ran genkernel, I got a good initramfs.

----------

## John Klug

I had this problem again on the next kernel upgrade.

The real story is that some levels of cpio do not support 64 bit inodes.

This level of CPIO worked for me on AMD64:

app-arch/cpio-2.10-r1

Here is a bug report on the issue:

https://bugs.gentoo.org/246370

So there is a chance that genkernel will fail if you use xfs (or some other file system with 64 bit inodes) and some file inodes are the same in the 32 bits that cpio uses.  In which case, if you are on AMD64. you need an unstable version of cpio.

----------

## richard.scott

 *John Klug wrote:*   

> ...In which case, if you are on AMD64. you need an unstable version of cpio.

 

Just for peoples info, app-arch/cpio-2.10-r1 works fine for me with XFS and AMD64.

Rich

----------

