Image via Wikipedia
So, earlier this year I began scouring the interwebs looking for clues on how to upgrade directly from slamd64 to slackware64. Typically, the "upgradepkg pkgtool" and glibc along with a host of base slackware packages "a - through - l" will do the trick. However, since I had already backed up the notebook there was no reason to play around with a live update. I wiped the disk clean and installed slackware64-13.0. When I was running Debian on that notebook, I ran LUKS (Linux Unified Key Setup) encryption on the /home and root files systems. *Quick Aside* encrypted file systems are useful on your notebook computers.. It keeps people from getting at your confidential data..
Somehow, the Debian installer presents LUKS as an option during the install process. Though, some may see this as an advantage, I really never understood what was happening behind the scenes. I didn't realize that the /boot partition was not actually being encrypted (and for good reason). LVM is fairly trivial to setup, in fact my notebook sports a modest 80GB disk so it is questionable whether I really need LVM. Nonetheless, I figured that I could then be able to grow and shrink partition sizes with LVM installed. That could never be a bad thing :-)
After making the choice of running Slackware on the notebook, I used some very helpful README files. LVM and its LUKS companion. Unfortunately, I munged the install by incorrectly setting up initrd so that the bootloader LILO can boot the root filesystem.
For those unfamiliar with initrd, it is a temporary filesystem which loads specific instructions into ramdisk (ie kernel modules for hard disk, and file system, etc) to aid in booting the Linux kernel.
Actually, in my earlier days of running slackware (before the era of exotic hardware and large hard disks) I never needed initrd. Somewhere around kernel 2.4.x I began using as Volkerding suggested it in the install README files. Anyway, if you do not setup initrd correctly, you'll be greeted with a nice kernel panic :-)
How does one rescue their installation when this occurs? Here are some steps that should help. Once again, I was grateful for the help I received from
Please be advised that these instructions are geared towards my setup.
For my LVM setup, I only had two volume groups.
If you forget the LUKS passphrase, you will have to wipe the hard disk and re-install your operating system.
Do the following -
Boot your system with the Slackware install CD/DVD (actually any linux distro live CD should work)
Run 'fdisk -l' to view your partition table
cryptsetup luksOpen /dev/myrootfs cryptslack
Respond with your LUKS passphrase
Run 'ls -la /dev/cryptvg'
lrwxrwxrwx 1 root root 24 2010-09-25 08:27 home -> /dev/mapper/cryptvg-homeNow we'll mount the LVM partitions and setup our chroot environment
lrwxrwxrwx 1 root root 24 2010-09-25 08:27 root -> /dev/mapper/cryptvg-root
lrwxrwxrwx 1 root root 24 2010-09-25 08:27 swap -> /dev/mapper/cryptvg-swap
The chroot environment is necessary for us to correct the initrd setup on our native root file system. Remember that the installer has its own rootfs, /etc/fstab , etc.. If you're unclear about chroot. I'd recommend reading up or using the ubiquitous GOOG search.
After running 'ls -la /dev/cryptvg'
mount /dev/cryptvg/root /mnt
mount /dev/cryptvg/home /mnt/home
mount /dev/mybootpart /mnt/boot
All of your LVM volume groups and boot partitions should now be mounted. Next we must setup our chroot environment..
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt --> gets us into chroot
While inside chroot ::
At this point you should be able to see your installed slackware root filesystem. Be sure to check out the /etc/lilo.conf and the filesize of initrd.gz. My clue was that initrd.gz was a mere 20kb. This told me that initrd was not built correctly.
So to fix initrd do the following:
mkinitrd -c -k 18.104.22.168 -f ext3 -r /dev/cryptvg/root -C /dev/sda2 -L -o /boot/initrd.gz
Of course replace with your actual Linux kernel version number and using the explicit path to mkinitrd would be wise too. Take a look at man mkinitrd to decipher the parameters.
After rebuilding mkinitrd check the timestamp and filesize of /boot/initrd.gz.
They should be different from your originial initrd.gz
After you again check of /etc/lilo.conf for errors (pointers to correct boot image and initrd.gz) Run '/sbin/lilo -v'
type exit to leave chroot
All should be well again.. If all went well, after your reboot, you should be prompted for your LUKS passphrase. If not rinse and repeat ;-)