wtogami (wtogami) wrote,

Testing Needed: mkinitrd bash-branch

mkinitrd is a totally unsexy piece of the distribution, but its importance is critical.  mkinitrd creates the initramfs image, which is a RAM disk that contains a minimal set of tools necessary to mount your filesystems and boot your system.

One of the things I've been working on is an experimental branch of mkinitrd that uses bash to run the /init script instead of just nash.  Having a real shell allows more flexibility in what can be done in the initramfs in shell scripting.  I am not entirely pleased that we are using bash (800K binary) instead of a smaller shell like dash (100K binary), but the reason Jeremy wants bash is so we don't have to maintain yet another shell.  There is the *possibility* that we might use this bash-branch of mkinitrd for Fedora 9, so I have been periodically pulling updates from pjones' upstream mkinitrd git repo so the two branches stay in sync.

mkinitrd bash-branch git repository

Upstream mkinitrd git repository

A few new features supported by this mkinitrd:
  • If an error occurs during initramfs initialization, it drops to a shell so you can try to debug what happened during the /init script.
  • dleham's LUKS-based encrypted root filesystem support.  I just synced it from pjones' upstream tree today.  I have no idea how it works, and the bash-branch port could be broken.
  • Boot read-only squashfs NBD (Network Block Device).  I later intend on implementing squashfs containing an ext3 image, with dm-snap on top to allow for block-level read-write just like the LiveCD.  Either read-only root or read-write root it has potential to enable things like thin clients or network booted centrally managed workstations.
  • Detect and load the proper network driver during initramfs so you can boot off the network with either NFS or NBD.
Testing Needed
I think I have mkinitrd bash-branch to a mostly usable state.  I need testing to see if it works in all cases just like the original mkinitrd.  Testers would need to be CAREFUL to keep a non-bash-branch initrd as an alternative in their grub.conf so they can go back to the known good boot option in case this experimental mkinitrd broke.  Only help in testing if you really know what you are doing.

How to Test
  1. cp /sbin/mkinitrd /sbin/mkinitrd-orig
    Make a backup copy of the mkinitrd script.  This might be useful later if you want to compare the behavior of the new and old mkinitrd.  Important Note: nash of the original mkinitrd works only with original mkinitrd.  bash-branch nash works with both original mkinitrd and bash-branch mkinitrd.
  2. http://fedorapeople.org/~wtogami/temp/mkinitrd-rpm/
    RPMS for Fedora 8.  Upgrade your mkinitrd, nash and possibly others if you have them installed.
  3. mkinitrd syntax:
    If you have kernel- then you might type:
    mkinitrd /boot/initrd-
    In this case I added "-test" within the image name because I want it to be different from the original initrd-  This way I can have separate grub menu options to try the original mkinitrd vs. bash-branch mkinitrd with exactly the same kernel version.
  4. Configure grub.conf.  Copy your existing menu entry, creating a second identical except for the initrd image name and description.  Example:
    title Fedora (
            root (hd0,0)
            kernel /vmlinuz- ro root=/dev/vg0/system
            initrd /initrd-
    title Bash-Branch Test (
            root (hd0,0)
            kernel /vmlinuz- ro root=/dev/vg0/system
            initrd /initrd-

Be careful about future kernel installs/upgrades, because all subsequent kernels will use the new experimental mkinitrd to create their initrd images.  You may want to downgrade back to the original mkinitrd if you are not actively testing it just to be safe.

Reporting Bugs and Debugging
I want to know if this experimental mkinitrd fails in any cases where the original succeeded.  I know that it is a bit noisier than the original mkinitrd, ignore this for now.  Please file in Bugzilla against mkinitrd and assign directly to me if you run into any problems.

If you encounter an error during initramfs it will drop you to a shell.  It is likely that you cannot easily figure out what caused the error.  Try rebooting, remove "quiet" add the "verbose" option to your kernel parameters.  That will run the /init script with "set -x" so you see each command as it goes by.  You might be able to see the last command that happened before it dropped you to the shell.
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded