Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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 Christian Hesse (eworm) - Thursday, 17 August 2017, 06:02 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

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

Comment by Doug Newgard (Scimmia) - Monday, 14 August 2017, 15:39 GMT
If cryptsetup is failing, it's not a systemd issue.
Comment by Christian Hesse (eworm) - Monday, 14 August 2017, 20:08 GMT
Any chance to get some more error messages from cryptsetup?
Comment by Scott Burman (osteichthyes) - Monday, 14 August 2017, 20:51 GMT
Yes. I have been troubleshooting on the forums

https://bbs.archlinux.org/viewtopic.php?id=228801
Comment by Scott Burman (osteichthyes) - Monday, 14 August 2017, 20:52 GMT
I will try downgrading systemd this afternoon
Comment by Christian Hesse (eworm) - Monday, 14 August 2017, 21:16 GMT
Take a look at man pam_exec(8) and try to get some more info there. Possibly 'debug' and 'log=' can help.
Comment by Scott Burman (osteichthyes) - Monday, 14 August 2017, 22:40 GMT
log was empty before suspend/resume.
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.
Comment by Scott Burman (osteichthyes) - Wednesday, 16 August 2017, 22:39 GMT
Per some suggestions on the forum, I downgraded arch. First to 30 July. The problem persisted. I then downgraded to 28 July, the problem was resolved. Between 28 and 30 July, only a few things updated, most relevant were util-linux and libutil-linux, both of which are dependencies of cryptsetup. I'm not sure if I should move this to util-linux or if it is related to the cryptsetup dependence on util-linux.
Comment by Scott Burman (osteichthyes) - Wednesday, 16 August 2017, 22:39 GMT
Full records of the downgrades are listed in the forum post (omitted for brevity):
https://bbs.archlinux.org/viewtopic.php?pid=1730992
Comment by Scott Burman (osteichthyes) - Wednesday, 16 August 2017, 22:49 GMT
The break seems to have been introduced by the util-linux/libutil-linux upgrade from 2.30 to 2.30.1
Comment by Christian Hesse (eworm) - Thursday, 17 August 2017, 06:03 GMT
Adding Dave to the assignees for the util-linux part.
Comment by Scott Burman (osteichthyes) - Sunday, 24 September 2017, 23:50 GMT
Hey all, not to be a bother, but has there been any progress on this? It's becoming a bit of a problem.
Comment by Christian Hesse (eworm) - Monday, 25 September 2017, 09:35 GMT
I pushed util-linux 2.30.2-1 to [testing]. Can you check if that fixes your issue?
Comment by Scott Burman (osteichthyes) - Saturday, 30 September 2017, 22:36 GMT
I just upgraded when it was moved to core, unfortunately it did not fix the issue.
Comment by Christian Hesse (eworm) - Friday, 20 October 2017, 09:34 GMT
Dave pushed util-linux 2.31-1 to [testing]. Any change?
Comment by Scott Burman (osteichthyes) - Tuesday, 31 October 2017, 02:30 GMT
Nope.

Should I file this upstream?
Comment by Scott Burman (osteichthyes) - Monday, 13 November 2017, 00:53 GMT
I finally got this figured out. The configs on the wiki for the pamexec instructions specify the use of x-systemd.automount in fstab

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.
Comment by Filip Matzner (floop) - Monday, 13 November 2017, 11:04 GMT
Hi Scott,

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.

Loading...