wtogami (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} wtogami) wrote,@ 2007-12-01 00:32:00 |
|
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.
http://fedorapeople.org/~wtogami/mkinitr
mkinitrd bash-branch git repository
git://git.fedoraproject.org/hosted/mkini
Upstream mkinitrd git repository
A few new features supported by this mkinitrd:
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
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.
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.
http://fedorapeople.org/~wtogami/mkinitr
mkinitrd bash-branch git repository
git://git.fedoraproject.org/hosted/mkini
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.
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
- 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. - http://fedorapeople.org/~wtogami/temp/mk
initrd-rpm/
RPMS for Fedora 8. Upgrade your mkinitrd, nash and possibly others if you have them installed. - mkinitrd syntax:
mkinitrd IMAGENAME KERNELVERSION
If you have kernel-2.6.23.9-67.fc8 then you might type:
mkinitrd /boot/initrd-2.6.23.9-67.fc8-test.img 2.6.23.9-67.fc8
In this case I added "-test" within the image name because I want it to be different from the original initrd-2.6.23.9-67.fc8.img. This way I can have separate grub menu options to try the original mkinitrd vs. bash-branch mkinitrd with exactly the same kernel version. - Configure grub.conf. Copy your existing menu entry, creating a second identical except for the initrd image name and description. Example:
title Fedora (2.6.23.9-67.fc8)
root (hd0,0)
kernel /vmlinuz-2.6.23.9-67.fc8 ro root=/dev/vg0/system
initrd /initrd-2.6.23.9-67.fc8.img
title Bash-Branch Test (2.6.23.9-67.fc8.test)
root (hd0,0)
kernel /vmlinuz-2.6.23.9-67.fc8 ro root=/dev/vg0/system
initrd /initrd-2.6.23.9-67.fc8-test.img
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.
