Modifying initrd image - Revision history

14.140.2.178: /* Analyzing init script */

2015-09-28T10:48:29Z

‎Analyzing init script

Vzuser: added cpio option "-H newc"

2006-07-27T20:10:43Z

added cpio option "-H newc"

Vzuser: changed mtpspi.ko to mptspi.ko

2006-07-27T20:05:27Z

changed mtpspi.ko to mptspi.ko

Vass: /* Creating initrd */

2006-06-30T06:51:16Z

‎Creating initrd

Kir: typo fixed in /* Creating initrd */

2006-06-28T20:38:01Z

typo fixed in ‎Creating initrd

Kir: fixed HN link in /* Analyzing init script */

2006-06-28T20:35:58Z

fixed HN link in ‎Analyzing init script

Kir: small fixes here and there

2006-06-28T20:35:09Z

small fixes here and there

Vass: Initial edition of article

2006-06-27T14:34:31Z

Initial edition of article

New page

The very often reason why your kernel can't boot is not properly created initrd image.
Here is a small description what you can do if encounter similar problem.

==What is initrd image==
Your boot loader ussually supports <tt>initrd</tt> instruction.
For example in GRUB:
<pre>
OpenVZ (2.6.8-022stab077)
root (hd0,0)
kernel /vmlinuz-2.6.8-022stab077 ro root=LABEL=/ console=tty0
initrd /initrd-2.6.8-022stab077.img
</pre>
GRUB loads initrd-2.6.8-022stab077.img file at a certain address in memory.
When kernel boots it checks for initrd image and if it exists starts <tt>init</tt>
script, that resides on this image.
<tt>init</tt> script usually is written on nash (something like bash, but poorer).
When <tt>init</tt> scipt on initrd image is finished kernel as usually calls system V <tt>init</tt>
process (/sbin/init, etc.)

==Why initrd image is necessary==
Suppose your root partion resides on some SCSI device and driver for this SCSI devices is compiled in some
kernel module. Of course this module is required at boot time to have access to the root partion. Somebody has to load this
module, and it does initrd image!
Additionally after appearing udev subsystem, somebody have to start udev to create device nodes. This is initrd's duty too.

==Typical problem==
Consider a real problem. After booting the kernel we get the following:
<pre>
...
Creating root device
mkrootdev: label / not found
Mounting root filesystem
mount: error 2 mounting ext3
mount: error 2 mounting none
Switching to new root
switchroot: mount failed: 22
umount /initrd/dev failed: 2
Kernel panic - not sysncing: Attempted to kill init!
</pre>
This can appear if there is no module loaded for device, where root partion resides.
To solve the problem extract the initrd image.

==Extracting initrd image==
Initrd image is just cpio-gzip archive. So to extract it:
<pre>
$ mkdir cpio
$ cp initrd-2.6.16-026test014.4-smp.img cpio/initrd-2.6.16-026test014.4-smp.cpio.gz
$ cd cpio
$ gunzip initrd-2.6.16-026test014.4-smp.cpio.gz
$ cpio -i < initrd-2.6.16-026test014.4-smp.cpio
$ ls -1
bin
dev
etc
init
initrd-2.6.16-026test014.4-smp.cpio
lib
loopfs
proc
sbin
sys
sysroot
</pre>

==Analyzing init script==
<pre>
$ cat init
#!/bin/nash

mount -t proc /proc /proc
setquiet
echo Mounted /proc filesystem
echo Mounting sysfs
mount -t sysfs none /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs none /dev
mknod /dev/console c 5 1
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mkdir /dev/pts
mkdir /dev/shm
echo Starting udev
/sbin/udevstart
echo -n "/sbin/hotplug" > /proc/sys/kernel/hotplug
echo "Loading mptbase.ko module"
insmod /lib/mptbase.ko
echo "Loading mptscsih.ko module"
insmod /lib/mptscsih.ko
/sbin/udevstart
echo Creating root device
mkrootdev /dev/root
umount /sys
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
mount -t tmpfs --bind /dev /sysroot/dev
echo Switching to new root
switchroot /sysroot
umount /initrd/dev
</pre>

We can see, that init tryies to load modules mptbase.ko and mptscsih.ko.
Check for presense of these modules on initrd image:
<pre>
$ ls -1 ./lib/
mptbase.ko
mptscsih.ko
</pre>

So they are... But on the node in question there is device, that is supported by driver in another module:
<tt>mtpspi.ko</tt>! After adding it to image an in init script everything must work.

==Creating initrd==
We just have to cpio and gzip directory cpio:
<pre>
$ ls
bin etc initrd-2.6.16-026test014.4-smp.cpio loopfs sbin sysroot
dev init lib proc sys
$ rm initrd-2.6.16-026test014.4-smp.cpio
$ find ./ | cpio -o > ../new-initrd.img
1354 blocks
</pre>

==Who create mkinitrd by default?==
In each modern distribution there is <tt>mkdinitrd</tt> packet, that allows to create
initrd image. You can use this program, it has a lot of options. OpenVZ kernel RPM-package (and "make install" too) uses this
program to create initrd image.

[[Category: HOWTO]]
[[Category: Troubleshooting]]

@@ Line 98: / Line 98: @@
 We can see that init tries to load modules <code>mptbase.ko</code> and <code>mptscsih.ko</code>.
-Check for presense of these modules on initrd image:
+Check for presence of these modules on initrd image:
 <pre>
 $ ls -1 ./lib/

@@ Line 111: / Line 111: @@
 We just have to cpio and gzip directory cpio:
 <pre>
-$ find ./ | cpio -o > /boot/new-initrd.cpio
+$ find ./ | cpio -H newc -o > /boot/new-initrd.cpio
 blocks
 $ cd /boot

@@ Line 106: / Line 106: @@
 So they are here... But on the [[Hardware Node|node]] in question there is a device supported by driver in another module:
-<code>mtpspi.ko</code>! After adding it to the image and into init script everything should work.
+<code>mptspi.ko</code>! After adding it to the image and into init script everything should work.
 ==Creating initrd==

@@ Line 111: / Line 111: @@
 We just have to cpio and gzip directory cpio:
 <pre>
-$ find ./ | cpio -o > /boot/new-initrd.img
+$ find ./ | cpio -o > /boot/new-initrd.cpio
 blocks
 </pre>

@@ Line 115: / Line 115: @@
 </pre>
-Next, try to boot your kernel with newly created initrd image,
+Next, try to boot your kernel with newly created initrd image.
 ==Who create initrd by default?==

@@ Line 1: / Line 1: @@
-The very often reason why your kernel can't boot is not properly created initrd image.
+The frequent reason why your kernel can't boot is not properly created initrd image.
-Here is a small description what you can do if encounter similar problem.
+Here is a small description of what you can do if you encounter a similar problem.
 ==What is initrd image==
-Your boot loader ussually supports <tt>initrd</tt> instruction.
+Your boot loader usually supports <code>initrd</code> instruction.
-For example in GRUB:
+For example, in GRUB:
 <pre>
 OpenVZ (2.6.8-022stab077)
@@ Line 12: / Line 12: @@
 </pre>
 GRUB loads initrd-2.6.8-022stab077.img file at a certain address in memory.
-When kernel boots it checks for initrd image and if it exists starts <tt>init</tt>
+When kernel boots, it checks for initrd image, and if it exists starts <tt>init</tt>
-script, that resides on this image.
+script that resides on this image.
-<tt>init</tt> script usually is written on nash (something like bash, but poorer).
+<tt>init</tt> script is usually written in nash (a sort of bash-like shell, just smaller).
-When <tt>init</tt> scipt on initrd image is finished kernel as usually calls system V <tt>init</tt>
+When <tt>init</tt> script on initrd image is finished, kernel usually calls standard System V <tt>init</tt>
 process (/sbin/init, etc.)
 ==Why initrd image is necessary==
-Suppose your root partion resides on some SCSI device and driver for this SCSI devices is compiled in some
+Suppose your root partion resides on some SCSI device and driver for this SCSI devices is compiled as a
-kernel module. Of course this module is required at boot time to have access to the root partion. Somebody has to load this
+kernel module. Of course this module is required at boot time to have access to the root partion — but it is not in the kernel. Thus the need for an initrd image.
-module, and it does initrd image!
-Additionally after appearing udev subsystem, somebody have to start udev to create device nodes. This is initrd's duty too.
+Additionally after udev subsystem become common, somebody has to start udev to create device nodes. This is initrd's duty too.
 ==Typical problem==
@@ Line 39: / Line 39: @@
 </pre>
 This can appear if there is no module loaded for device, where root partion resides.
-To solve the problem extract the initrd image.
+To solve the problem, extract the initrd image.
 ==Extracting initrd image==
 Initrd image is just cpio-gzip archive. So to extract it:
 <pre>
-$ mkdir cpio
+$ mkdir initrd
-$ cp initrd-2.6.16-026test014.4-smp.img cpio/initrd-2.6.16-026test014.4-smp.cpio.gz
+$ cd initrd
-$ cd cpio
+$ gzip -dc /boot/initrd-2.6.16-026test014.4-smp.cpio | cpio -id
 $ ls -1
 bin
@@ Line 99: / Line 97: @@
 </pre>
-We can see, that init tryies to load modules mptbase.ko and mptscsih.ko.
+We can see that init tries to load modules <code>mptbase.ko</code> and <code>mptscsih.ko</code>.
 Check for presense of these modules on initrd image:
 <pre>
@@ Line 107: / Line 105: @@
 </pre>
-So they are... But on the node in question there is device, that is supported by driver in another module:
+So they are here... But on the [[Hardware Node|node] in question there is a device supported by driver in another module:
-<tt>mtpspi.ko</tt>! After adding it to image an in init script everything must work.
+<code>mtpspi.ko</code>! After adding it to the image and into init script everything should work.
 ==Creating initrd==
 We just have to cpio and gzip directory cpio:
 <pre>
-$ ls
+$ find ./ | cpio -o > /boot/new-initrd.img
 blocks
 </pre>
-==Who create mkinitrd by default?==
+Next, try to boot your kernel with newly created initrd image,
-In each modern distribution there is <tt>mkdinitrd</tt> packet, that allows to create
-initrd image. You can use this program, it has a lot of options. OpenVZ kernel RPM-package (and "make install" too) uses this
+==Who create initrd by default?==
-program to create initrd image.
+Usually there is an <code>mkdinitrd</code> package installed, that allows to create
 [[Category: HOWTO]]
 [[Category: Troubleshooting]]