View previous topic :: View next topic |
Author |
Message |
chrylis n00b
Joined: 29 Dec 2017 Posts: 3
|
Posted: Fri Dec 29, 2017 9:43 pm Post subject: dmcrypt volumes don't get automatically mounted |
|
|
I'm trying to get an encrypted /home partition working on a new Gentoo installation. I've used LUKS before on a systemd installation, but I'm back to Gentoo specifically because I want OpenRC!
My LUKS volume is on an LV, and it all maps correctly: LVM comes up, OpenRC starts dmcrypt, I get prompted for a passphrase, and the LUKS volume gets mapped correctly. However, the volume doesn't get mounted, presumably because localmount already ran. My fstab entry is correct, using a UUID as recommended by the wiki, and 'mount /home' always works immediately after boot. The wiki suggests that using the UUID will cause the volume to be mounted as soon as it becomes available, but that doesn't work for me; I get identical behavior using /dev/mapper/home.
Is there a way to ensure my LUKS volume gets mounted automatically on boot as soon as I open it, besides adding a custom RC entry or otherwise doing it "manually"?
/etc/conf.d/dmcrypt
Code: | target=home
source='/dev/vg/home-luks' |
/etc/fstab
Code: | UUID="da53d409-442f-4c0d-8fed-5bea2777ddea" /home ext4 noatime,discard 0 0 |
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Dec 30, 2017 5:31 am Post subject: Re: dmcrypt volumes don't get automatically mounted |
|
|
chrylis wrote: | IHowever, the volume doesn't get mounted, presumably because localmount already ran. |
This shouldn't be the case: dmcrypt has a "before fsck", and localmount has a "need fsck".
Are you sure that you added dmcrypt to the boot runlevel (in contrast to the default runlevel?)
Try to force dependency regeneration with
Code: | /lib64/rc/bin/rc-depend --update |
(use /lib instead of /lib64 if you are on an x86 system.)
Quote: | The wiki suggests that using the UUID will cause the volume to be mounted as soon as it becomes available |
This is not true. There are of course ways (automount, udev rules, or when you are using systemd) to do this, but AFAIK nothing like this is set up by default. |
|
Back to top |
|
|
chrylis n00b
Joined: 29 Dec 2017 Posts: 3
|
Posted: Sat Dec 30, 2017 6:23 pm Post subject: |
|
|
I read through the dependencies myself and came to the same conclusion, but the mount is still running first; I reran the dependency resolution, so maybe that will change things, but I haven't rebooted (running things).
In the meantime, I added /home to localmount:critical_mounts. Now localmount still comes up first, but it complains about not being able to mount /home, then dmcrypt runs, and by the time I get logins localmount is started and /home is mounted. Perhaps not elegant, but it's working reliably. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Sat Dec 30, 2017 10:53 pm Post subject: |
|
|
What is the output of rc-update show? |
|
Back to top |
|
|
chrylis n00b
Joined: 29 Dec 2017 Posts: 3
|
Posted: Mon Jan 01, 2018 2:29 am Post subject: |
|
|
Code: | binfmt | boot
bootmisc | boot
consolefont | sysinit
cronie | default
dbus | default
devfs | sysinit
device-mapper | boot
dmcrypt | boot
dmesg | sysinit
fsck | boot
hdparm | default
home-mount-workaround | boot
hostname | boot
hwclock | boot
keymaps | boot
killprocs | shutdown
kmod-static-nodes | sysinit
lm_sensors | default
local | default nonetwork
localmount | boot
loopback | boot
lvm | boot
metalog | default
modules | boot
mount-ro | shutdown
mtab | boot
net.lan0 | default
netmount | default
nfsclient | default
procfs | boot
root | boot
savecache | shutdown
sshd | default
swap | boot
sysctl | boot
sysfs | sysinit
termencoding | boot
udev | sysinit
udev-trigger | sysinit
urandom | boot
xdm | default
|
|
|
Back to top |
|
|
PureTryOut n00b
Joined: 05 Nov 2016 Posts: 12
|
Posted: Sun Jan 07, 2018 1:01 pm Post subject: |
|
|
I'm sadly having the exact same problem, on a freshly installed system.
A SSD and a HDD, both encrypted. The SSD gets decrypted on boot by means of a password, the HDD gets decrypted by using a keyfile on the just decrypted SDD. Both encrypted partitions contain LVM volumes.
Decrypting is going fine, everything on the SSD gets mounted properly. However, the system tries to mount everything on the HDD before it's actually decrypted, and thus fails. Running once the system has booted remounts it all properly.
/var/log/rc.log:
Code: |
* /run/lvm: creating directory
* Starting lvmetad ...
[ ok ]
* Setting up the Logical Volume Manager ...
[ ok ]
* Checking local filesystems ...
/dev/mapper/ssd-rootfs: clean, 514754/3276800 files, 2671384/13107200 blocks
fsck.ext4: Unable to resolve 'UUID=d0c63dd0-7eb3-4ff1-9f55-160e23d8a924'
/dev/mapper/ssd-data: clean, 11/12288000 files, 1048886/49143808 blocks
fsck.ext4: Unable to resolve 'UUID=c12a983c-d3f6-41b5-b41e-33d7306049d0'
fsck.fat 4.0 (2016-05-06)
/dev/nvme0n1p1: 355 files, 10621/261628 clusters
* Operational error
[ !! ]
* Mounting local filesystems ...
mount: /home: can't find UUID=d0c63dd0-7eb3-4ff1-9f55-160e23d8a924.
mount: /games-hdd: can't find UUID=c12a983c-d3f6-41b5-b41e-33d7306049d0.
* Some local filesystem failed to mount
[ !! ]
* Starting dbus ...
[ ok ]
* Starting NetworkManager ...
[ ok ]
Connecting.......... 1sConnecting........... 1sConnecting............ 1sConnecting............. 1sConnecting.............. 1sConnecting............... 1sConnecting............... 0s [offline]
* Marking NetworkManager as inactive. It will automatically be marked
* as started after a network connection has been established.
* WARNING: NetworkManager has started, but is inactive
rc sysinit logging stopped at Sun Jan 7 13:28:45 2018
rc boot logging started at Sun Jan 7 13:28:45 2018
* Setting system clock using the hardware clock [UTC] ...
[ ok ]
* Setting up dm-crypt mappings ...
* hdd using: open /dev/sda1 hdd ...
[ ok ]
[ ok ]
* Remounting root filesystem read/write ...
[ ok ]
|
/etc/fstab:
Code: |
UUID=385E-FD1C /boot vfat defaults,noatime 1 2
UUID=5ec3a414-d96b-4c3a-bba8-f351a333b3a9 / ext4 defaults,noatime,errors=remount-ro 0 1
UUID=d0c63dd0-7eb3-4ff1-9f55-160e23d8a924 /home ext4 defaults,noatime 0 1
UUID=2cddf51f-e929-45d4-b520-fb1de6882af1 /games-ssd ext4 defaults,noatime 0 1
UUID=c12a983c-d3f6-41b5-b41e-33d7306049d0 /games-hdd ext4 defaults,noatime 0 1
|
rc-status boot:
Code: |
Runlevel: boot
hwclock [ started ]
modules [ started ]
dmcrypt [ started ]
fsck [ started ]
root [ started ]
mtab [ started ]
swap [ started ]
localmount [ started ]
procfs [ started ]
sysctl [ started ]
bootmisc [ started ]
termencoding [ started ]
keymaps [ started ]
binfmt [ started ]
urandom [ started ]
loopback [ started ]
hostname [ started ]
|
|
|
Back to top |
|
|
khayyam Watchman
Joined: 07 Jun 2012 Posts: 6227 Location: Room 101
|
Posted: Sun Jan 07, 2018 6:07 pm Post subject: |
|
|
PureTryOut wrote: | A SSD and a HDD, both encrypted. The SSD gets decrypted on boot by means of a password, the HDD gets decrypted by using a keyfile on the just decrypted SDD. Both encrypted partitions contain LVM volumes. Decrypting is going fine, everything on the SSD gets mounted properly. However, the system tries to mount everything on the HDD before it's actually decrypted, and thus fails. Running 'mount -a' once the system has booted remounts it all properly. |
PureTryOut ... you need your initramfs to decrypt both SSD/HD, and run 'lvm vgchange -a y', prior to switching root. I'm not sure what you're doing ITR but you need these available prior to 'localmount' and 'fsck' (and both of these are in the 'boot' runlevel).
HTH & best ... khay |
|
Back to top |
|
|
PureTryOut n00b
Joined: 05 Nov 2016 Posts: 12
|
Posted: Sun Jan 07, 2018 10:54 pm Post subject: |
|
|
But that would require me to enter a password for HDD as well right? That's exactly what I'm trying to prevent by using a keyfile on the first encrypted drive... I had this working a few years ago on Arch, so with systemd, and I'm not sure why it wouldn't work here. The 'dmcrypt' service is already supposed to run before 'fsck' according to it's 'depend()' function. |
|
Back to top |
|
|
khayyam Watchman
Joined: 07 Jun 2012 Posts: 6227 Location: Room 101
|
Posted: Mon Jan 08, 2018 3:23 pm Post subject: |
|
|
PureTryOut wrote: | But that would require me to enter a password for HDD as well right? That's exactly what I'm trying to prevent by using a keyfile on the first encrypted drive... |
PureTryOut ... no, it wouldn't, you would do the same, unlock SSD, lvchange, point cryptsetup to the keyfile, lvchange, switch_root. I expect your initramfs is not something you've created for that purpose, and so only does a single luksOpen. I did state "I'm not sure what you're doing ITR".
PureTryOut wrote: | The 'dmcrypt' service is already supposed to run before 'fsck' according to it's 'depend()' function. |
Yes, I didn't see that dmcrypt was being started, my bad. If you did this your initramfs you wouldn't need to have dmcrypt, or lvm, in the runlevel, but anyhow, looking closer I don't see lvm in the boot runlevel, is that output from 'rc-status boot'?
best ... khay |
|
Back to top |
|
|
PureTryOut n00b
Joined: 05 Nov 2016 Posts: 12
|
Posted: Mon Jan 08, 2018 4:48 pm Post subject: |
|
|
Ah, I don't know much about the initramfs so I sadly have no clue how to do that.
khayyam wrote: | is that output from 'rc-status boot'? |
Yes it is. I noticed LVM missing as well, but adding it didn't change anything. LVM scans anyway it seems. |
|
Back to top |
|
|
khayyam Watchman
Joined: 07 Jun 2012 Posts: 6227 Location: Room 101
|
Posted: Mon Jan 08, 2018 10:11 pm Post subject: |
|
|
PureTryOut wrote: | Ah, I don't know much about the initramfs so I sadly have no clue how to do that. |
PureTryOut ... well, it's worth spending a little time getting familiar with it. All an initramfs is is a small root filesystem with an 'init' script. Normally 'init' parses /proc/cmdline and passes these parameters to <command> (eg, cryptsetup, lvm, etc), and once this process is completed, it's switches to the real root, and runs /sbin/init (or whatever happens to correspond with init=), if anything fails it (should) drop you to a rescue shell. As 'init' is basically a shell script, its fairly simple to modify, and so add the required additional crypsetup, lgchange -y a, etc. So, while various tools exist to create an initramfs (genkernel, dracut, etc) the internals (ie, 'init') are wrapped up in the resulting *.cpio.gz, and so take a little more work to access, modify, and re-generate. However, you can roll your own, or use something like better-intitramfs and so have more control of what goes into the *.cpio.gz at various stages of the 'build' (better-initramfs has other benefits but for brevities sake ...). But anyhow, you may not want to take that route, but essentially that's what a initramfs is for.
PureTryOut wrote: | khayyam wrote: | is that output from 'rc-status boot'? |
Yes it is. I noticed LVM missing as well, but adding it didn't change anything. LVM scans anyway it seems. |
I would try changing from UUID to /dev/mapper in fstab, it's possible {e,}udev is taking its time. You could also try post_mount="vgchange -a y" in /etc/conf.d/dmcrypt, but I doubt this will remedy the problem. Other than that I'm not sure what to suggest, I do all this in initramfs.
best ... khay |
|
Back to top |
|
|
majoron Apprentice
Joined: 12 Oct 2005 Posts: 239 Location: Frankfurt
|
Posted: Tue Nov 27, 2018 1:29 pm Post subject: |
|
|
In my case I only encrypt /home, but still an initramfs seems to be needed: all local filesystems are mounted by localmount before dmcrypt can be run, which is good because / must be there. It is bad because at the same time /home is tried to be mounted...
For now I have fixed it with a hack: adding a script to /etc/local.d that just mounts /home _________________ Computers are like air conditioners, they stop working properly if you open Windows |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|