FS#55043 - [cryptsetup] luks-encrypted home directory fails to open
Attached to Project:
Arch Linux
Opened by Scott Burman (osteichthyes) - Saturday, 05 August 2017, 20:22 GMT
Last edited by Toolybird (Toolybird) - Sunday, 11 June 2023, 00:41 GMT
Opened by Scott Burman (osteichthyes) - Saturday, 05 August 2017, 20:22 GMT
Last edited by Toolybird (Toolybird) - Sunday, 11 June 2023, 00:41 GMT
|
Details
Description:
I have an encrypted home (my root is not encrypted). Which uses pam_exec to decrypt following the instructions in the wiki: https://wiki.archlinux.org/index.php/Dm-crypt/Mounting_at_login In the past week, when logging in, the home partition fails to mount, logs report that cryptsetup fails with exit-code 1. (Looking at cryptsetup docs: exit code 1 means wrong parameters) If I use gdm to login, the login stays on the login screen and the little gear spins forever. If I use tty to login, then after entering my password, the cursor just sits and flashes forever. However, all that is called is: /usr/bin/cryptsetup open /dev/disk/by-partlabel/home home This has worked reliably for about two years. It seems related to this bug, which applied to root encryption: https://bugs.archlinux.org/task/54825 I don't recall the exact date that this break occurred, but it may well have been the day that bug was fixed (31 July). The only work-around I've found is to enter the password, wait a few seconds -- long enough for it to decrypt, then suspend the computer. On waking the computer, the directory will be unlocked and mounted. Additional info: * package version: 234.11-4 * config and/or log files etc. /usr/bin/cryptsetup failed: exit code 1 Steps to reproduce: Boot and login. |
This task depends upon
Closed by Toolybird (Toolybird)
Sunday, 11 June 2023, 00:41 GMT
Reason for closing: Fixed
Additional comments about closing: Old and stale. Seems to be no longer an issue and was resolved according to the comments.
Sunday, 11 June 2023, 00:41 GMT
Reason for closing: Fixed
Additional comments about closing: Old and stale. Seems to be no longer an issue and was resolved according to the comments.
https://bbs.archlinux.org/viewtopic.php?id=228801
This was all that was written:
[code]
*** Mon Aug 14 15:30:56 2017
[/code]
After suspend/resume:
[code]
*** Mon Aug 14 15:30:48 2017
*** Mon Aug 14 15:31:18 2017
Device home-scott already exists.
*** Mon Aug 14 15:31:19 2017
Device home-scott already exists.
[/code]
I've done some other testing, outlined in the forum -- mostly relating to other software, including full configs/systemd units.
https://bbs.archlinux.org/viewtopic.php?pid=1730992
Should I file this upstream?
Doing so causes it to simply never mount, unless you trigger the fs being called (by sleep/wake cycle, etc).
I do not know why an update in util-linux caused this. x-systemd.automount has never worked for me as described, and it would seem presently it is causing this issue.
I'll add comments to the wiki. This bug can be closed, but perhaps there should be a bug against systemd.automount.
I have a similar problem as you after following the wiki (https://wiki.archlinux.org/index.php/Dm-crypt/Mounting_at_login). I believe that x-systemd.automount is the right choice in here, but the problem seems to be connected to filesystem check. If I replace the /etc/fstab line:
/dev/mapper/home-YOURNAME /home/YOURNAME ext4 rw,noatime,noauto,x-systemd.automount 0 2
by this line:
/dev/mapper/home-YOURNAME /home/YOURNAME ext4 rw,noatime,noauto,x-systemd.automount 0 0
Than everything works as expected (it should be noted that in my case the filesystem is btrfs, though).
It seems that with "0 2", the filesystem is being checked somewhere during the boot, without actually being decrypted by proper user password and the check gets stuck. After boot, when you actually log in, cryptsetup fails because /dev/mapper/home-YOURNAME is still busy. So overall you may be right, it may be a bug in systemd.automount, let us know when/whether you fill in the bug report.