[SOLVED] Can't get encrypted root partition to boot using grub2
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Can't get encrypted root partition to boot using grub2
I just tried a reinstall of Slackware 14.1 x64, encrypting my root partition along the way. I'm using grub2 as my bootloader as I'm dual-booting with Windows and I know it works. I tried following the Arch Linux guide to using grub2, doing the grub-install to the EFI partition and adding in thte extra lines for an encrypted root. However, when I boot, it complains that it can't find mapper/cryptroot and fails to boot.
Any pointers in the right direction would be appreciated. And if someone could let me know what kernel parameters to enter for my USB boot disk to boot into the encrypted system, that'd be great... I think I need to know that to fix it.
The huge kernel will provide you with device drivers but you need extra software for the decryption of your disk, and that software is loaded from initrd.
Sorry it took so long to reply, I got really busy right after.
So I used AlienBob's mkinitrd_generator script and got an initrd.gz good to go. I've run into a different problem now. When I boot, it would appear that the password for the encrypted hard drive is requested before the keyboard is detected (I see the request for the password and then immediately after I see all the messsages popping up for my USB hardware being detected). After this, no matter what I type on the keyboard and press enter, I get the following messages:
[CODE]udevd[282]: failed to execute '/sbin/dmsetup' '/sbin/dmsetup udevflags 5148928': No such file or directory
udevd[283]: failed to execute '/sbin/dmsetup' '/sbin/dmsetup udevcomplete 5148928': No such file or directory[\CODE]
and everything just stops. I did a quick Google search and came up with this thread from last year with similar problems that resulted in not using the root= line in lilo.conf. I'm not sure as to where I would implement that fix within grub2 with EFI, though, so I need some help.
You said your root partition is encrypted. Then how were you able to run mkinitrd_generator.sh without successfully booting into your system? It should be run from within the installed system to work properly (perhaps you mounted the partition from the installation DVD and then chroot'ed into it?). Anyway, it still seems to me that initrd isn't working as expected. /sbin/dmsetup should already have been copied into initrd.gz. Make sure you use the -L and -C options when you run mknitrd.
Note: Normally if you don't use LVM then -L should not be needed, but I vaguely remember reading about a change of behaviour/bug? in this version of mkinitrd which requires -L even when there's encryption without LVM.
Another note: If you want initrd to wait for devices, use the option -w [seconds]. This is especially useful when you install into an external HD, for example. Udev may spit out some keyboard-related messages after the LUKS password prompt, but so far this didn't give me any trouble.
Yet another note: You may change your lilo options on-the-fly by pressing "Tab" at the boot menu (you should then write the menu item name plus the new options). IN case the root= options is the problem, you may experiment with various values without needing to re-run lilo.
Sorry it took so long to reply, I got really busy right after.
So I used AlienBob's mkinitrd_generator script and got an initrd.gz good to go. I've run into a different problem now. When I boot, it would appear that the password for the encrypted hard drive is requested before the keyboard is detected (I see the request for the password and then immediately after I see all the messsages popping up for my USB hardware being detected). After this, no matter what I type on the keyboard and press enter, I get the following messages:
[CODE]udevd[282]: failed to execute '/sbin/dmsetup' '/sbin/dmsetup udevflags 5148928': No such file or directory
udevd[283]: failed to execute '/sbin/dmsetup' '/sbin/dmsetup udevcomplete 5148928': No such file or directory[\CODE]
and everything just stops. I did a quick Google search and came up with this thread from last year with similar problems that resulted in not using the root= line in lilo.conf. I'm not sure as to where I would implement that fix within grub2 with EFI, though, so I need some help.
The quickest way to test would be to edit the grub stanza as the system is coming up. Press "e" during boot and scroll down until you see a block that looks like...
Code:
echo Loading Linux 3.10.17 ...
linux /vmlinuz-generic-3.10.17 root=UUID=f15cdaf7-c299-4cc0-8a16-533808d59454 ro
echo Loading initial ramdisk ...
initrd /initrd.gz
Use grub's interactive editing feature to delete the bolded part (your values will be different; you just delete everything starting from "root=" and ending at the next whitespace. Hit ctrl-x and grub will boot with your temporary change.
If it works, you can hand-edit /boot/grub/grub.cfg when the system comes up to match what you did interactively. Or just edit /etc/default/grub to set GRUB_DISABLE_LINUX_UUID=true (There's a comment in the file that describes what this does.) and regenerate your config file with
I did a lot of reinstalls yesterday. I tried chroot-ing but things wouldn't work properly (which wasn't bad because it only takes like 10 min for me to setup Slackware and I was doing Christmas stuff during the waits). And now that you mention it, I do vaguely remember having to use the -w option on another computer to get things running properly, I'll try adding that in. I'll also try adding in the -L option, although I'm not using an LVM in this case.
@Richard Cranium:
What you've suggested seems reasonable, I'll give it a shot.
Your root partition isn't on top of software RAID is it?
Nope, no software RAID. I'm gonna be away for Christmas so I don't think I'm even going to get a chance to try to get this working again until next week.
I'm glad that it worked. I think this (new) behaviour of mkinitrd deserves a mention in the relevant README files if it persists in the upcoming releases.
I'd send it to Pat ("Patrick Volkerding" <volkerdi@slackware.com> in case the e-mail link doesn't work). Speaking as a software weasel, please give him enough detail so that he could re-create your problem on a machine of his own. It's difficult to fix a problem that you can't re-create.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.