LinuxQuestions.org - mount encrypted partition at boot using crypttab

Page 1 of 2

Show 50 post(s) from this thread on one page

- Fedora (https://www.linuxquestions.org/questions/fedora-35/)

- - mount encrypted partition at boot using crypttab (https://www.linuxquestions.org/questions/fedora-35/mount-encrypted-partition-at-boot-using-crypttab-4175620019/)

farmerdave

12-20-2017 08:17 PM

mount encrypted partition at boot using crypttab

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 (Post 5809833)

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 (Post 5815935)

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.

All times are GMT -5. The time now is 03:49 PM.

Page 1 of 2

Show 50 post(s) from this thread on one page