There is small simple howto with Slackware package mkinitrd, man page says a little bit more, more is kind of mystery 🙂
I switched from full kernel (in fact, my own compiled kernel) to initrd few years ago and since then I had learned a lot about it (sometimes in hard way) 🙂
So, this is my way (a little different than in man and readme) of doing initrd.
During Slackware installation you need to install:
- kernel-generic (not kernel-huge!)
and of course other packages you would like to have 🙂
Remember NOT to install kernel-huge package.
Install everything, setup lilo, timezones etc as usual. At the end DON’T reboot at the end of setup – system isn’t finished yet!
Now, it’s time to prepare new initrd.
- Chroot to /mnt (where new system should be already mounted)
- Make copy of default mkinitrd config:
cp /etc/mkinitrd.conf.sample /etc/mkinitrd.conf
- Edit new /etc/mkinitrd.conf with your favourite editor and set few options:
- uncomment and set MODULE_LIST and ROOTFS to type of your root filesystem, for example
You don’t need to worry about all related modules, they will be added automatically.
- if you use software raid, uncomment and set
- if you use lvm or encryption, uncomment and set
- I strongly recommend to set SOURCE_TREE and OUTPUT_IMAGE to some more unique names, for example
You don’t have to do this if you don’t want to play with custom kernels etc.
- make new initrd with mkinitrd -F
- add initrd image to lilo.conf adding it just after ‘image’ line, so it will look like this:
image = /boot/vmlinuz-generic-3.10.12
initrd = /boot/initrd-3.10.12.gz
- get out of chroot and rebuild lilo with:
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
lilo -r /mnt
Right now you could reboot system and enjoy new Slackware with initrd:-)
What’s an advantage of this way instead of running mkinitrd with many bizarre options? See next part.
Sometimes you need to change kernel, upgrade or something like that.
There are 2 ways of maintaining Slackware with initrd:
- Use one initrd for all kernels
- Use separate initrd for every kernel or even every entry in lilo
One initrd for all
At start, make sure that you have commented out CLEAR_TREE or set it to 0 in mkinitrd.conf!
After installation of new kernel and running still from old one, you need to to set KERNEL_VERSION to version of your new kernel, for example
Then just run mkinitrd -F
That’s all about initrd – now image has required modules for both/all your kernels.
Of course you need new entry in lilo.conf for new kernel with exactly the same initrd as old one.
If you are making kernel upgrade (replace old kernel package) you don’t even need to touch lilo.conf. But in both cases, you must run lilo at the end.
From time to time, you could clean initrd tree from old modules from kernel you don’t use anymore. In this case just remove all directory with that modules from /boot/initrd-tree/lib/modules/old-kernel-version and regenerate initrd using as usual mkinitrd -F. And rerun lilo of course 🙂
Now, you probably see advantage of using mkinitrd.conf instead of remembering all those weird switches you used last time to generate this image.
Separate initrd for every kernel
This way have a little sense if you only use one root filesystem and only stock kernel which you sometimes only upgrade.
Separate initrd is even easier than ‘one for all’ attitude.
One drawback is that mkinitrd with -F flag only reads one default /etc/mkinitrd.conf file, so each time you have to copy saved configuration back to this file.
So, for first kernel you should customize at least SOURCE_TREE, OUTPUT_IMAGE and KERNEL_VERSION. Generate new initrd with mkinitrd -F, then make backup of mkinitrd.conf to for example mkinitrd.conf.3.10.17.
For next kernel with different options customize mkinitrd.conf again, create new initrd, make backup and so on.
That way you could have different initrds and saved all options to regenerate each of them. It’s safe attitude as playing with new kernel and initrd configuration you always have working old one.
Ok, that was easy part:-)
Next time I’ll cover how to combine initrd with encrypted root and even root on encrypted lvm 🙂
I found quite good article on the same topic at Slackware Documentation Project. So, it looks like i didn’t do so much research before writing this post 🙂