mount encrypted partition at boot using crypttab

farmerdave · 12-20-2017, 08:17 PM

I have an encrypted partition (non-root) which I wish to mount at boot time. I used dm-crypt/LUKS to do the encryption. I created a passphrase and a keyfile for the decryption.

My crypttab entry for mounting with the keyfile works fine and is

Code:

cryptFiles   /dev/sdb6   /etc/dm-crypt/secretfile

with an /etc/fstab entry

Code:

/dev/mapper/crytpFiles   /Data    ext4   defaults  0 2

If I change this to prompt me for the passphrase in my crypttab file with

Code:

cryptFiles   /dev/sdb6   none

then my boot fails. I never see a prompt for entering the password.

I believe the problem is with Plymouth (according to the Arch wiki). My system is actually dual boot (Fedora 27 and CentOS 7.0), and the exact same crypttab file that prompts me for a passphrase works fine in CentOS. I enter the password and the boot process continues.

The solution on the Arch wiki points to adding a "plymouth" hook in the mkinicpio.conf file and regenerating the initramfs, however I can't find any information about how to solve this for Fedora 27.

How can I boot Fedora and have a prompt for a passphrase for this encrypted partition?

MensaWater · 12-21-2017, 01:42 PM

I'll start by saying I've not worked with the encrypted filesystems.

What stands out to me in your post however, is your use of "/dev/sdb6". Is it possible that what your CentOS is identifying as sdb6 is NOT what your Fedora is identifying as sdb6 (i.e. maybe Fedora sees it as sda6 or sdc6)?

The sd devices aren't guaranteed to be the same on every boot which is why even for unencrypted devices it is recommended you label the device and use that label rather than the name in fstab.

rknichols · 12-21-2017, 06:33 PM

As an experiment, try adding "nofail" to the options in the /etc/fstab entry. That should allow the boot to succeed without that mount, and then you can then see whether your encrypted device is really /dev/sdb6 or elsewhere.

Your LUKS partition may not have an accessible LABEL until it has been successfully unlocked (unless you are using GPT, the only LABEL is in the ext4 filesystem super block), but it does have a LUKS UUID that I believe you could use in /etc/crypttab if the device identity does turn out to be the problem.

farmerdave · 12-22-2017, 02:19 AM

Thanks for the answers, I'll investigate. I did try the UUID instead and it still didn't work, but I'll double check my attempts. As I mentioned though, if I specify the full path to the keyfile it works fine, UUID or /dev doesn't matter.

farmerdave · 12-22-2017, 02:20 AM

Trouble is that this is my work computer that is causing problems, and I've just knocked off for Christmas!

farmerdave · 01-18-2018, 10:22 PM

I'm still having trouble with this.

I once again tried using UUIDs instead of /dev/sdb6 but it made no difference. I also tried nofail to the options in /etc/crypttab, but still don't get a password prompt.

I am at the point where I can start the pc, get past grub, get a black screen but type the luks password and decrypt the volume and magically get to my display manager login screen. I achieved this by removing 'rhgb' from the kernel boot parameters.

One other interesting thing (possibly related?) is that I can switch to another TTY using 'Ctrl + Alt + F2' and can see the boot messages, but I have no login on F2-F6, its all the same messages. 'Ctrl + Alt + F1' takes me back to my graphical environment. I'm using sddm , and if I edit the /etc/sddm.conf line to provide extra Virtual consoles

Code:

MinimumVT=7

then I need to use 'Ctrl Alt + F7' to get back to graphical, but I still have no login on the other consoles, just the same boot text.

I've tried a range of different grub parameters in /etc/default/grub such as GRUB_TERMINAL_OUTPUT="console", GRUB_GFXPAYLOAD_LINUX="text" and GRUB_ENABLE_CRYPTODISK="y" but I don't see any difference.

At this point I'd welcome any other suggestions!

bgstack15 · 01-22-2018, 10:56 AM

Maybe your /dev/mapper/ entry needs "luks-" prepended to the name, e.g., /dev/mapper/luks-b8f055d6?

I wrote about this on my blog at https://bgstack15.wordpress.com/2017...ted-with-luks/ a while ago.

My notes also indicate my /etc/crypttab has a single character dash - as the last column. Maybe Fedora needs the dash to realize to prompt you?

farmerdave · 01-22-2018, 06:33 PM

I think I am getting closer to cracking this. I have an nvidia GPU which is potentially the difficulty.
If I use the nouveau video driver I can get a graphical boot screen, with a graphical prompt for a passphrase. I can also get a console prompt for a passphrase if I change some kernel parameters at boot time.

But if I try and use the nvidia driver I can't get a passphrase, it fails firstly because the nvidia driver is not loading early enough. So I've tried using dracut to add it earlier in the boot process (I think I'm doing it right!) and still have problems because it fails when creating a virtual console (systemd-vconsole-setup.service).

I'm working through some suggestions for this at the moment.

farmerdave · 01-22-2018, 07:40 PM

Quote:

Originally Posted by bgstack15

Maybe your /dev/mapper/ entry needs "luks-" prepended to the name, e.g., /dev/mapper/luks-b8f055d6?

I wrote about this on my blog at https://bgstack15.wordpress.com/2017...ted-with-luks/ a while ago.

My notes also indicate my /etc/crypttab has a single character dash - as the last column. Maybe Fedora needs the dash to realize to prompt you?

My understanding is that the entry for /dev/mapper/ is really just a label, and the fourth field is optional. See https://www.freedesktop.org/software.../crypttab.html

voleg · 01-31-2018, 11:22 AM

There is fourth field in /etc/crypttab that set an option.
I've used option forcing boot to wait for passphrase forever.
Check mine Encrypted /home on Fedora

farmerdave · 02-04-2018, 10:33 PM

Thanks, I've followed what you've done to manually test and I get an unusual result!

In particular, I added the fourth field in /etc/crypttab, namely "luks,x-systemd.device-timeout=0". I then got the same result as you for the next two commands:

Code:

# systemctl daemon-reload
# find /var/run/systemd/generator | grep cryptsetup
/var/run/systemd/generator/dev-mapper-cryptFiles.device.requires/systemd-cryptsetup@cryptFiles.service
/var/run/systemd/generator/cryptsetup.target.requires
/var/run/systemd/generator/cryptsetup.target.requires/systemd-cryptsetup@cryptFiles.service
/var/run/systemd/generator/dev-disk-by\x2duuid-7070dcf2\x2d756f\x2d438e\x2dabf7\x2dce2059902332.device.wants/systemd-cryptsetup@cryptFiles.service
/var/run/systemd/generator/systemd-cryptsetup@cryptFiles.service

And the same result here:

Code:

# umount /dev/mapper/cryptFiles
# cryptsetup luksClose cryptFiles
# ls -l /dev/mapper/cryptFiles
ls: cannot access '/dev/mapper/cryptFiles': No such file or directory

But then, using the next command:

Code:

# systemctl start systemd-cryptsetup@cryptFiles.service

I don't get a password prompt, I just get a new bash prompt! And there is no new mapping in /dev/mapper either.

farmerdave · 02-04-2018, 10:53 PM

I've almost got this!

If I modify the kernel parameters to disable kernel mode setting I get a password prompt at boot! My grub entry is

Code:

menuentry 'Fedora (4.14.14-300.fc27.x86_64) 27 (Twenty Seven)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.14.14-300.fc27.x86_64-advanced-c9b22aa7-c3ae-4938-8117-9eb3f9e56d54' {
        savedefault
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos12'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos12 --hint-efi=hd0,msdos12 --hint-baremetal=ahci0,msdos12 --hint='hd0,msdos12'  c3ad994b-b74c-492c-8292-e42ae83bfee2
        else
          search --no-floppy --fs-uuid --set=root c3ad994b-b74c-492c-8292-e42ae83bfee2
        fi
        linux16 /vmlinuz-4.14.14-300.fc27.x86_64 root=UUID=c9b22aa7-c3ae-4938-8117-9eb3f9e56d54 ro rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nomodeset 
        initrd16 /initramfs-4.14.14-300.fc27.x86_64.img
}

There is now only one problem left. For each keypress of my password, I get a new "please enter your password" request. The password does work, but since its 19 characters long I get 19 requests. I'm so close, surely I can resolve this last step!

voleg · 02-05-2018, 02:38 AM

New line for each character usually because of wrong or missing TERM definitions at time script run.

farmerdave · 02-05-2018, 09:49 PM

Quote:

Originally Posted by voleg

New line for each character usually because of wrong or missing TERM definitions at time script run.

Thanks, can you elaborate on which script? Are you referring to a config file I may have modified, or instead do you mean a grub script?

voleg · 02-06-2018, 12:08 AM

No, I have no recepie in this case, it is just what pay attention to.
"nomodeset" may be a reason, may be not. Try to play with it.
Non modified fresh Fedora have no such staircase effect,
so you should check modified parts related to boot.