Differences between revisions 13 and 14
Revision 13 as of 2009-01-08 05:54:47
Size: 3772
Editor: ?timrichardson
Comment:
Revision 14 as of 2009-01-08 05:56:24
Size: 3771
Editor: ?timrichardson
Comment:
Deletions are marked like this. Additions are marked like this.
Line 58: Line 58:
You can either use the kernel break parameter and edit the script in {{{/scripts}}} for a one-time change, or edit the script in {{{under /usr/share/initramfs-tools/}}} and do {{{{update-initramfs -u}}} for a permanent change. You can either use the kernel break parameter and edit the script in {{{/scripts}}} for a one-time change, or edit the script in {{{under /usr/share/initramfs-tools/}}} and do {{{update-initramfs -u}}} for a permanent change.

?wiki:initramfs-tools is used in Debian to build the initramfs that contains the early userspace and the needed kernel modules to be able to mount any possible root.

Boot

Boot with rootdelay=9 to shorten the time of waiting for the root device to come up. Also it adds time to scsi device to settle before calling mdadm or lvm thus excluding potential races.

Rescue shell (also known as initramfs shell)

Read man initramfs-tools to learn about the break= kernel parameter, which starts a debug shell. You can try, for example, break=premount. You can edit /boot/grub/menu.lst to add this to the end of the kernel line, or you can do it interactively from the grub boot menu: "e" to edit, and "b" to boot once you've edited the kernel line.

Ok, now you landed in the initramfs debug shell. This is a surprisingly complete environment provided by "busybox". You can use vi, for example, but not everything is fully the same as bash. For example, sleep only accepts integer arguments. You may find more complete commands in /bin (for example, /bin/sleep does accept decimal arguments, but you will need to use /bin/sleep in your scripts).

The following steps should help to narrow down the problem.

  • Check root device existence
     ls -l /dev/[hs]da*
    If above does not exist checkout for eventual driver conflict or other information
     dmesg
  • Check root boot argument
    • It needs to be the same than above root device
     cat /proc/cmdline
  • Check correct fs recognition
     /lib/udev/vol_id -t /dev/sda1
     fstype /dev/sda1
    • If the output of aboves command differ, your partition was not cleanly formated. For example mkfs.ext2 does not clear all sectors when formating a partition.
  • Check if the ata/ide/scsi driver is loaded
     cat /proc/modules
  • saving output from an initramfs script into a logfile you can review later

If you have a lot of interesting debug going to stderr, you may want to save it and review later. You can't save it to /tmp because the initramfs filesystem is not visible after the full boot. There is a solution, though: You can redirect output to /dev/.initramfs/mylogfile.txt. and this will be available after the full boot, in the same location. It will be erased at the next boot, so rename it if you want to keep it.

This works even if you keep the initramfs as read-only (no need to change the default ro kernel parameter).

Of course, you still need to add 2>/dev/.initramfs/mylogfile.txt to script you are interested in. You can either use the kernel break parameter and edit the script in /scripts for a one-time change, or edit the script in under /usr/share/initramfs-tools/ and do update-initramfs -u for a permanent change.

initramfs content

It can happen that due to a bug in the initramfs creation a newer initramfs lacks important libraries or utilities. Easiest way is to compare the file list of working contra non-working initramfs.

  •  cd $TMPDIR
     mkdir initramfs{,-old}
     cd initramfs
     gunzip -c -9 /boot/initrd.img-2.6.22-rc6-686 \
      | cpio -i -d -H newc --no-absolute-filenames
     find > ../initramfs.content
     cd ../initramfs-old
     gunzip -c -9 /boot/initrd.img-2.6.22-rc6-686.bak \
      | cpio -i -d -H newc --no-absolute-filenames
     find > ../initramfs-old.content
     cd ..
     diff -u initramfs-old.content initramfs.content
    If the intiramfs creation of both those images went well there should be no diff. If you are comparing initramfs for different kernels you should see a difference in the modules aka other dir and newer drivers in /lib/modules/$(uname -r)