How Do I Make an initrd image?

Posted by ajt on Sun 13 Nov 2005 at 21:32


I have a Debian "sid" box installed onto a root partition on LVM2, boot is on hda. When I set it up originally everything went in well and it boots perfectly. The inital initrd created during install has all the right bits in and it boots and finds the root partition on the LVM2 without a problem. This works fine for both 2.4 and 2.6 family kernels.

Since installing it I've upgraded to the latest stock 2.6 "sid" kernel. When I try and boot from that kernel it dies with a kernel panic very quickly. I've tried creating an initrd with the standard mkinitrd tool and with that tool it boots a lot further, but still dies complaining about being unable to mount devfs.

What is the correct procedure to make a functioning initrd? It was able to make one during installation, why can't I make one now?

(I've done a Google search, but most of the hits are about LVM2+RAID, which I'm not doing.)

As ever, thanks in advance.



Posted by markybob (67.163.xx.xx) on Sun 13 Nov 2005 at 22:12

[ Parent | Reply to this comment ]

Posted by ajt (204.193.xx.xx) on Mon 14 Nov 2005 at 09:28
[ View Weblogs ]
Sorry, yes the 2.6.14 kernel.

Okay, excluding the bug, how do I make an initrd then? Or will aptitude automatically build a proper one when it installs the kernel?

(For some reason my title line got mangled too, sorry for that as well - it looked okay in preview)

"It's Not Magic, It's Work"

[ Parent | Reply to this comment ]

Posted by undefined (192.91.xx.xx) on Tue 29 Nov 2005 at 22:45
the problem you are experiencing sounds exactly like the problem i solved this last weekend (but with 2.4.27 kernel source from debian etch, built with make-kpkg, where i refused to enable devfs in the kernel because of past problems).

cat <<eof>/etc/mkinitrd/scripts/
echo copying device files corresponding to lvm partitions
# actually copying all files associated with hard drive
cp -av /dev/hda* ${INITRDDIR}/dev/
echo done

chmod 755 /etc/mkinitrd/scripts/

my exact problem was that mkinitrd expects devfs to be used (and tries to mount devfs which fails), so no dev files are included in the initrd. but vgscan and vgchange need the dev files to "discover" your lvm physical volumes.

also, by default mkinitrd uses cramfs for the initrd, but historically the stock kernel (maybe just 2.4) didn't include cramfs. you can build an initrd of a specific filesystem type by setting MKIMAGE to the proper command within /etc/mkinitrd/mkinitrd.conf.

if that doesn't solve your problem, then you can do the following to enable further investigation:

apt-get install busybox

editor /etc/mkinitrd/mkinitrd.conf

cat <<eof>/etc/mkinitrd/scripts/
#!/bin/bash -xv
rm -f ${INITRDDIR}/sbin/{vgscan,vgchange}
cp {,${INITRDDIR}}/sbin/lvmiopversion
for FILE in /lib/lvm-10/*; do
ln -s lvmiopversion ${INITRDDIR}/sbin/$(basename ${FILE})

chmod 755 /etc/mkinitrd/scripts/

mkinitrd -k -o /boot/initrd.img-<version> <version>

-k is useful because if you want to inspect the contents of the initrd it is much easier to peruse the build directory than loop-mounting the initrd image.

for me version = 2.4.27-11+1-686 as that was the version of the corresponding kernel-image package i built with make-kpkg. (i really recommend make-kpkg though i've only ever used it to compile kernel-source packages, not stock kernels.)

when booting the initrd it should print a message similar to "pausing to allow user to interrupt the boot process by pressing enter". press enter. now start probing around the system. if your initrd is cramfs, which is read-only, and you want/need to create files, then you'll need to "mount tmpfs tmpfs /blah" to give you a writable directory (and lvm needs a writable /etc).

that worked for me, maybe it'll help you.

[ Parent | Reply to this comment ]

Posted by markybob (67.163.xx.xx) on Sun 13 Nov 2005 at 22:16
i dont think the comments are working. i'm submitting one more to know for sure.

[ Parent | Reply to this comment ]

Posted by Anonymous (82.41.xx.xx) on Sun 13 Nov 2005 at 22:35
It seems to be ok.

[ Parent | Reply to this comment ]

Posted by markybob (67.163.xx.xx) on Sun 13 Nov 2005 at 22:38
yes, now :-) i emailed steve about it and received this:
"Strange. I've fixed it for the moment, but I'm not 100% sure what went wrong. I'll experiment, thanks for letting me know.


[ Parent | Reply to this comment ]

Posted by Anonymous (65.84.xx.xx) on Mon 14 Nov 2005 at 19:24
i'd build a vanilla kernel. copy your debian config from /boot, then when your ready to build:

root# make-kpkg clean && make-kpkg --initrd --revision=custom.1.0 kernel_image

after its finished with no errors, dpkg -i <kernel>.deb

[ Parent | Reply to this comment ]

Posted by Anonymous (24.8.xx.xx) on Mon 14 Nov 2005 at 20:45
Dont forget to "make oldconfig" after copying the config file from /boot to update the new .config file with any new options.

[ Parent | Reply to this comment ]

Posted by hardik (61.95.xx.xx) on Tue 15 Nov 2005 at 03:56
If you have the devfs problem while boot you can skip that part by putting
below line at end of kernel argument in grub like...

----------------------------------------------------------------- -----------------
kernel /boot/vmlinuz-2.6.13 root=/dev/hda1 ro vga=791 splash=verbose
----------------------------------------------------------------- -----------------

Hardik Dalwadi.

[ Parent | Reply to this comment ]

Posted by Anonymous (213.197.xx.xx) on Sun 27 Nov 2005 at 14:59
did you do a installation of udev
you need that with kernel 2.6.12 and higer.

apt-get install udev

not long ago i did a dist-upgrade from sarge to sid
but because i did'nt had 2.6.12 or higer kernel
and no udev installed my system went crazy
i at last did a reinstall

and did you configure the files /etc/mkinird/

[ Parent | Reply to this comment ]

Posted by undefined (192.91.xx.xx) on Tue 29 Nov 2005 at 23:29
i don't believe udev is required to boot 2.6.12 (but possibly just a populated /dev, whether static or populated by udev).

case in point: i have a sarge AMD64 server that i've tested with linux-source-2.6.12 from ubuntu's breezy. udev is not installed, but initrd-tools boots my raid1+lvm2 setup just fine with 2.6.12. devfs is enabled in the kernel (default ubuntu kernel config), but i have a static /dev as i don't use devfs (and i'm regretting using udev on my etch desktop as it's a pain to learn udev's configuration file format and it never seems to work "just right").

side note: why use ubuntu's 2.6.12 kernel? debian sarge's 2.6.8 kernel-image doesn't contain ata pass-through for sata drives to enable smart, but ubuntu's 2.6.12 does and ubuntu provides security support for it (and will continue for a minimum of 18 months).

[ Parent | Reply to this comment ]

Posted by undefined (192.91.xx.xx) on Tue 29 Nov 2005 at 23:11
i don't believe that helps in the case of an initrd that does not include any (or a very limited subset of) files under /dev as it expects devfs to provide the files.

if you do not use devfs, then the kernel has every right to expect dev to be already populate. but mkinitrd is expecting devfs, so /dev is minimally populated (with some symlinks to /devfs where i assume devfs would be mounted).

[ Parent | Reply to this comment ]

Posted by Anonymous (66.190.xx.xx) on Fri 3 Mar 2006 at 16:30
Hopefully nobody will mind me commenting on a stale article (think of the children, uh, googlebots!! )...

I am describing my Sarge setup; it has been running stably for long enough that some of the details are a bit fuzzy in my mind, but I'll try not to forget anything:

if you're using the make-kpkg, --initrd will do the right thing if you have configured a couple of non-obvious things first.

the contents of my /etc/kernel-img.conf:

mkimage=/usr/sbin/mkcramfs %s %s # very important

you are going to need the cramfsprogs, kernel-package, initrd-tools.

module-init-tools is required for 2.6 kernels (The first problem I had involved this; the error messages were not at all informative at that time, since maybe fixed)
udev is a REALLY good idea in my experience.

Remember, the initrd is created at kernel-image-xxx.deb install time.
In my experience, any errors at that stage tend to mean that the mkimage command didn't work or one of the initrd builder pieces is missing. For this step, dependencies don't help you, as the needed packages vary based on your /etc/kernel-img.conf.

So, get kernel ready for compile,
make-kpkg --initrd --append-to-version .example.001 buildpackage
wait a while
dpkg -i ../kernel-*{yourversion}.example.001*deb

Ignore a couple of scary prompts, if you haven't overridden them in the kernel-img.conf (modern kernels can handle cramfs, and depending on what kernel you're running right now you might possibly get a whole stack of missing symbol errors when depmod tries to match up the new modules with the currently-running kernel)
if it all looked like it worked, boot your computer and test it...

[ Parent | Reply to this comment ]

Posted by Anonymous (194.215.xx.xx) on Fri 28 Jul 2006 at 14:43
The problem is that you are using mkinitrd when you probably should be using mkinitramfs. mkinitrd is for devfs while mkinitramfs is for udev.

I was fighting with the same problem...

[ Parent | Reply to this comment ]

Posted by Anonymous (84.232.xx.xx) on Fri 14 Dec 2007 at 09:29
Yes, the previous poster was correct. Had to upgrade a Sarge (3.1) from 2.4.26 to 2.6.22 (with vserver support). Kernel compilation was OK ("make all" finished successfully) BUT rebooting with the kernel and the initrd that I was creating with "mkinitrd" failed.

I finally installed "mkinitramfs" from the backports repository ( However, I had to force the installation after manually downloading the package as this version has some dependencies that can not be resolved even by using the repository. After this forced install I regenerated the initrd with "mkinitramfs" and everything went smoothly.

What I would do now and I think would completely solve the problem would be to first upgrade Sarge (3.1) to Etch (4.0) and then use the provided tools to upgrade the kernel ("mkinitramfs" comes with Etch). Depending on your setup this may or may not be applicable, however.

As always, YMMV.

[ Parent | Reply to this comment ]

Posted by Anonymous (84.232.xx.xx) on Fri 14 Dec 2007 at 09:39
Forgot to add one last thing to the previous message: you will need to install "udev" and "module-init-tools", these are needed by the 2.6 kernel. "udev" is needed in order to populate "/dev" while "module-init-tools" is needed to take care of the changes that occured from 2.4 and 2.6 regarding modules and module-loading. It takes care automatically of the version of the kernel and calls the appropriate tools for your version, depending on which one you have so that you can have a system that can be dual-booted with 2.4 and 2.6.

[ Parent | Reply to this comment ]

Posted by Anonymous (195.78.xx.xx) on Sat 23 May 2009 at 01:30
use initramfs command. It is real solution. Run under /boot dir
initramfs -o name_of_initrd kernel_version. That's all. Good Luck.

[ Parent | Reply to this comment ]

Sign In







Current Poll

Will you stick to systemd as the default in Debian?

( 919 votes ~ 35 comments )