Slackware Excursions - Rescuing a failed LUKS / LVM install

The Slackware logo.

Image via Wikipedia

Roughly 3.5 yrs ago I purchased an Acer Aspire 5100. Initially, it was running Vista Home. I promptly wiped the hard disk and installed Debian/Stable. For whatever reason, I ran into some very weird kernel regression problems related to clocksource (TSC unstable due to cpufreq).  Finally got fed up and installed slamd64 (64bit slackware port). At that point official slackware did not exist on 64bit AMD or Intel. I believe the official Slackware64 port was released 5/19/09. Eric Hamleers and crew did an outstanding job.

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 alienbob   alienBOB on ##slackware.
Please be advised that these instructions are geared towards my setup.
For my LVM setup, I only had two volume groups.
I had chose not to leave one partition /boot (/dev/sda1) unencrypted and the entire root file system /dev/sda2 utilizes LUKS.  You must also remember to keep your LUKS passphrase in a safe place. Perhaps store it on an encrypted USB keychain or simply in your brain.
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
vgscan --mknodes
vgchange -ay
Run 'ls -la /dev/cryptvg'
lrwxrwxrwx  1 root root    24 2010-09-25 08:27 home -> /dev/mapper/cryptvg-home
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
Now we'll mount the LVM partitions and setup our chroot environment
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 ::
vgscan --mknodes
vgchange -ay

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 -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 ;-)

  • klogctl: Operation not permitted
  • Boot Loader Polka
  • Woes of Odeo
  • 2011 Ohio Linux Fest
  • Monthly Archives


    OpenID accepted here Learn more about OpenID
    Powered by Movable Type 4.25

    About this Entry

    This page contains a single entry by AG published on October 3, 2010 8:44 AM.

    Ode to the ARM was the previous entry in this blog.

    Death of a Brand is the next entry in this blog.

    Find recent content on the main index or look in the archives to find all content.