| View previous topic :: View next topic |
| Author |
Message |
hrnick
Guru
Joined: 31 Aug 2002
Posts: 429
Location: Sweden
|
 Posted: Mon Dec 27, 2021 6:23 pm Post subject: [SOLVED] Problems mounting encrypted drive on boot |
 |
|
Hi!
I rarely reboot my Gentoo system but when I did so recently my encrypted /home drive did not mount automatically. I have no idea what's wrong but what I did in order to get it to mount again was the following (with some ls -la /dev/mapper for debugging):
| Code: | $ ls -la /dev/mapper/
total 0
drwxr-xr-x 2 root root 180 dec 27 19:07 .
drwxr-xr-x 19 root root 4500 dec 27 19:07 ..
lrwxrwxrwx 1 root root 7 dec 27 19:06 cache -> ../dm-6
crw------- 1 root root 10, 236 dec 27 19:06 control
lrwxrwxrwx 1 root root 7 dec 27 19:06 repos -> ../dm-7
lrwxrwxrwx 1 root root 7 dec 27 19:06 root -> ../dm-0
brw------- 1 root root 254, 1 dec 27 19:06 vg0-root
brw------- 1 root root 254, 3 dec 27 19:06 vg0-usr
brw------- 1 root root 254, 2 dec 27 19:06 vg0-var
$ dmsetup remove_all
$ cryptsetup luksOpen /dev/sdb1 home
$ vgchange -ay
$ ls -la /dev/mapper/
total 0
drwxr-xr-x 2 root root 220 dec 27 19:08 .
drwxr-xr-x 20 root root 4560 dec 27 19:08 ..
lrwxrwxrwx 1 root root 7 dec 27 19:06 cache -> ../dm-6
crw------- 1 root root 10, 236 dec 27 19:06 control
lrwxrwxrwx 1 root root 7 dec 27 19:07 home -> ../dm-4
lrwxrwxrwx 1 root root 7 dec 27 19:06 repos -> ../dm-7
lrwxrwxrwx 1 root root 7 dec 27 19:06 root -> ../dm-0
brw------- 1 root root 254, 1 dec 27 19:06 vg0-root
brw------- 1 root root 254, 3 dec 27 19:06 vg0-usr
brw------- 1 root root 254, 2 dec 27 19:06 vg0-var
lrwxrwxrwx 1 root root 7 dec 27 19:08 vg2-home -> ../dm-5
$ mount /dev/mapper/vg2-home /home/ |
Rebooting there seems to be some error when unmounting the drives which I believe is the source of all this:
| Code: | Removing dm-crypt mappings
home ...
Stopping the Logical Volume Manager ...
0 logical volume(s) in volume group "vg2" now active
Logical volume vg0/root contains a filesystem in use
Can't deactivate volume group "vg0" with 2 open logical volume(s)
Failed to stop Logical Volume Manager (possibly some LVs still needed for /usr or root) |
So it seems as if /home can't be unmounted which causes other volumes to not be unmounted but it's only for the /home partition I need to run the commands above to get it mounted again.
I don't really get what's going on here. vg2-home is created after running cryptsetup luksOpen and then I can mount it but it fails to do it automatically. I realize that the information here might not be the most useful but if someone could please point me in the right direction I'll provide more information on what's happening.
Thanks!
Last edited by hrnick on Tue Dec 28, 2021 3:34 pm; edited 1 time in total |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2005
|
| Posted: Mon Dec 27, 2021 6:57 pm Post subject: |
|
|
Can you turn on boot logging via /etc/rc.conf and post the log here for a startup?
I suspect part of this is because lvm is starting before dmcrypt when it should be the opposite to unlock home first since it looks like home is also an LVM volume under the encryption. But this is all a hypothetical guess without more info. |
|
| Back to top |
|
|
hrnick
Guru
Joined: 31 Aug 2002
Posts: 429
Location: Sweden
|
| Posted: Mon Dec 27, 2021 9:54 pm Post subject: |
|
|
| grknight wrote: | Can you turn on boot logging via /etc/rc.conf and post the log here for a startup?
I suspect part of this is because lvm is starting before dmcrypt when it should be the opposite to unlock home first since it looks like home is also an LVM volume under the encryption. But this is all a hypothetical guess without more info. |
Thank you for your reply grknight. I was worried that was where we were headed Last time I tried enabling that my system didn't boot and I had to boot from a USB stick and chroot into the root partition and change the configuration back again. I might give it a try again though. I'll keep you posted. :) |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2005
|
| Posted: Tue Dec 28, 2021 12:23 am Post subject: |
|
|
| hrnick wrote: | | grknight wrote: | Can you turn on boot logging via /etc/rc.conf and post the log here for a startup?
I suspect part of this is because lvm is starting before dmcrypt when it should be the opposite to unlock home first since it looks like home is also an LVM volume under the encryption. But this is all a hypothetical guess without more info. |
Thank you for your reply grknight. I was worried that was where we were headed Last time I tried enabling that my system didn't boot and I had to boot from a USB stick and chroot into the root partition and change the configuration back again. I might give it a try again though. I'll keep you posted.  |
Setting rc_logger="YES" in rc.conf should never stop booting. Likely there is some other issue if editing that file does anything. |
|
| Back to top |
|
|
hrnick
Guru
Joined: 31 Aug 2002
Posts: 429
Location: Sweden
|
| Posted: Tue Dec 28, 2021 8:26 am Post subject: |
|
|
| grknight wrote: | | hrnick wrote: | | grknight wrote: | Can you turn on boot logging via /etc/rc.conf and post the log here for a startup?
I suspect part of this is because lvm is starting before dmcrypt when it should be the opposite to unlock home first since it looks like home is also an LVM volume under the encryption. But this is all a hypothetical guess without more info. |
Thank you for your reply grknight. I was worried that was where we were headed Last time I tried enabling that my system didn't boot and I had to boot from a USB stick and chroot into the root partition and change the configuration back again. I might give it a try again though. I'll keep you posted. |
Setting rc_logger="YES" in rc.conf should never stop booting. Likely there is some other issue if editing that file does anything. |
Yeah, I found it weird but just restored my system at that time. Whatever caused it seems to be gone because I could enable logging without any problems and the output can be found here. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2005
|
| Posted: Tue Dec 28, 2021 1:34 pm Post subject: |
|
|
| hrnick wrote: | | Yeah, I found it weird but just restored my system at that time. Whatever caused it seems to be gone because I could enable logging without any problems and the output can be found here. |
| Code: | * Starting the Logical Volume Manager ...
Found volume group "vg0" using metadata type lvm2
3 logical volume(s) in volume group "vg0" now active
[ ok ]
* Setting up dm-crypt mappings ...
* home using: open /dev/sdb1 home ...
[ ok ]
* cache using: open /dev/sda1 cache ...
[ ok ]
* repos using: open /dev/sda2 repos ...
[ ok ]
[ ok ]
* Checking local filesystems ...
fsck.fat 4.2 (2021-01-31)
/dev/sdc2: 772 files, 253860/258078 clusters
[ ok ]
* Remounting root filesystem read/write ...
[ ok ]
* Remounting filesystems ...
[ ok ]
* Updating /etc/mtab ...
* Creating mtab symbolic link
[ ok ]
* Activating swap devices ...
[ ok ]
* Mounting local filesystems ...
mount: /home: /dev/sdb1 already mounted or mount point busy.
mount: /root: special device /home/root does not exist.
* Some local filesystem failed to mount
[ !! ] |
First off, it seems you have /home defined in /etc/fstab as an unencrypted partition and not a LUKS volume location as it is using sdb1. Suggest using a UUID= value in fstab.
Second, since /home looks to be an LVM volume underneath LUKS, add dmcrypt to the rc_after value in /etc/conf.d/lvm for ordering purposes. e.g. rc_after="mdadm dmcrypt".
This should unconfuse your boot up process. |
|
| Back to top |
|
|
hrnick
Guru
Joined: 31 Aug 2002
Posts: 429
Location: Sweden
|
| Posted: Tue Dec 28, 2021 2:29 pm Post subject: |
|
|
Thank you for your reply grknight!
Actually the /home partition is specified using UUID in /etc/fstab and has been so since I set up the system. I confirmed that it's the correct UUID with a ls -l /dev/disk/by-uuid|grep sdb1. I added dmcrypt to rc_after but that did not change anything unfortunately. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2005
|
| Posted: Tue Dec 28, 2021 3:01 pm Post subject: |
|
|
| hrnick wrote: | Thank you for your reply grknight!
Actually the /home partition is specified using UUID in /etc/fstab and has been so since I set up the system. I confirmed that it's the correct UUID with a ls -l /dev/disk/by-uuid|grep sdb1. I added dmcrypt to rc_after but that did not change anything unfortunately. |
Your command "ls -l /dev/disk/by-uuid|grep sdb1" is producing the wrong result for the fstab entry. Instead, do the manual method and get the result of
| Code: | | lsblk -o MOUNTPOINTS,UUID|grep /home |
for the correct UUID |
|
| Back to top |
|
|
hrnick
Guru
Joined: 31 Aug 2002
Posts: 429
Location: Sweden
|
| Posted: Tue Dec 28, 2021 3:33 pm Post subject: |
|
|
| grknight wrote: | | hrnick wrote: | Thank you for your reply grknight!
Actually the /home partition is specified using UUID in /etc/fstab and has been so since I set up the system. I confirmed that it's the correct UUID with a ls -l /dev/disk/by-uuid|grep sdb1. I added dmcrypt to rc_after but that did not change anything unfortunately. |
Your command "ls -l /dev/disk/by-uuid|grep sdb1" is producing the wrong result for the fstab entry. Instead, do the manual method and get the result of
| Code: | | lsblk -o MOUNTPOINTS,UUID|grep /home |
for the correct UUID |
So it was the UUID all along, when I changed to the one that I got from lsblk it all worked, possibly with the addition to /etc/conf.d/lvm as well. Thank you for your help grknight!
Out of curiosity; why does /dev/disk/by-uuid list the wrong UUIDs and is there a reason to keep it there regardless? |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2005
|
| Posted: Tue Dec 28, 2021 3:39 pm Post subject: |
|
|
| hrnick wrote: | | grknight wrote: | | hrnick wrote: | Thank you for your reply grknight!
Actually the /home partition is specified using UUID in /etc/fstab and has been so since I set up the system. I confirmed that it's the correct UUID with a ls -l /dev/disk/by-uuid|grep sdb1. I added dmcrypt to rc_after but that did not change anything unfortunately. |
Your command "ls -l /dev/disk/by-uuid|grep sdb1" is producing the wrong result for the fstab entry. Instead, do the manual method and get the result of
| Code: | | lsblk -o MOUNTPOINTS,UUID|grep /home |
for the correct UUID |
So it was the UUID all along, when I changed to the one that I got from lsblk it all worked, possibly with the addition to /etc/conf.d/lvm as well. Thank you for your help grknight!
Out of curiosity; why does /dev/disk/by-uuid list the wrong UUIDs and is there a reason to keep it there regardless? |
fstab's purpose is to mount file systems, but this must be the raw,unencrypted versions. sdb1 has a UUID of the encrypted LUKS container, but the mount command cannot do anything with it because it is 1) opened by cryptsetup first, 2) has data that no known file system can mount.
When you have LUKS, and even other DM volumes (like LVM), there are additional UUIDs for each intermediate device. What goes in fstab is the end result to mount. This is easily demonstrated with either 'blkid' or 'lsblk -o NAME,MOUNTPOINTS,UUID' commands. |
|
| Back to top |
|
|
hrnick
Guru
Joined: 31 Aug 2002
Posts: 429
Location: Sweden
|
| Posted: Wed Dec 29, 2021 9:06 am Post subject: |
|
|
| grknight wrote: | fstab's purpose is to mount file systems, but this must be the raw,unencrypted versions. sdb1 has a UUID of the encrypted LUKS container, but the mount command cannot do anything with it because it is 1) opened by cryptsetup first, 2) has data that no known file system can mount.
When you have LUKS, and even other DM volumes (like LVM), there are additional UUIDs for each intermediate device. What goes in fstab is the end result to mount. This is easily demonstrated with either 'blkid' or 'lsblk -o NAME,MOUNTPOINTS,UUID' commands. |
Thank you for the explanation and for the help, it all makes more sense now! :) |
|
| Back to top |
|
|
|
Kernel & Hardware
