Hello again,
I've managed to repair my Slackware 14 installation. For future references I'll descript whole process here.
So, once again, let's describe the
problem: when I installed Slackware 14 x86_64 (with LVM and LUKS) I had only one disk in my machine (sda). Then I added one disk more, and used Slack HDD as an externally connected hard drive. Because of that Slack drive received different label (sdb) than during installation. Bootloader tried to unlock partition /dev/sda2, but this was a partition on a different HDD. The correct one at this time was /dev/sdb2. I needed to make new
initrd.gz, this time unlocking /dev/sdb2.
Solution: during boot process, because the root filesystem failed to mount, I have been dropped to command line. I was able to unlock encrypted /dev/sdb2 and mount LVM volumes available on it. Then I've tried to generate new initrd.gz with:
Code:
mkinitrd -c -k 3.2.29 -m ext3 -f ext3 -r /dev/cryptvg/root -C /dev/sdb2 -L
but this command only made it worse - because I didn't have all necessary partitions mounted during execution of above command I generated a ram disk which wasn't able to boot at all. I received "Kernel panic" message at boot and I was stuck without even access to console. So, I booted up the box with Slackware 14 x86_64 DVD disc and executed:
Code:
cryptsetup luksOpen /dev/sdb2 slackluks
Next, I've enabled LVM volumes with:
Code:
vgscan --mknodes
vgchange -ay
Then I've mounted all the drives:
Code:
mount /dev/crytpvg/root /mnt
mount /dev/sdb1 /boot
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt
In the end I've generated new ram disk as previously:
Code:
mkinitrd -c -k 3.2.29 -m ext3 -f ext3 -r /dev/cryptvg/root -C /dev/sdb2 -L
As the last step I've executed command:
Please note that this command will return some warrnings. That's normal. The most important is that you shouldn't receive any "Fatal" errors. If you get one, the boot process will most probably fail.
Hope this will help someone.
There's still one question in this topic: how to use drive UUID's instead of device names during ram disk generation? This would solve the issue for future.
Best regards,
Chris.