Open ticpu opened 4 weeks ago
After further investigation, the issue isn't completely isolated to a specific commit in the tools. It is possible to reproduce the same issue after running kernel 6.11-rc1 for a while and unmounting/re-mounting with v1.9.4 of the tools. I get ENOKEY and no way to mount until reboot, even after keyctl clear @u
.
After more digging, using a systemd service can't unlock the disk on Arch. Using but when "/bin/login" is used to authenticate first, the PAM modules that are loaded from there allows unlocking the FS.
Another failure mode to be aware of is with screen/tmux: the key could be scoped to a keyring attached to the first ssh connection; after reconnecting it becomes inaccessible, but still present enough to gum up the works. Workaround is:
keyctl new_session
keyctl link @u @s # optional?
Either from a freshly formatted FS or old, bcachefs fails to mount or use fsck -k in some conditions.
ENOKEY issue will most often appear when working from a sudo or Xorg session. When using a root TTY, it seems to be less likely, but not impossible, to reproduce. Rebooting and using a TTY to mount from just after startup has been a reliable way to mount my FS so far.
Userspace tools are not affected.
Here are some examples:
Return code was 0 there and normal mount didn't work anymore, as expected.
I also tried with all disks one by one, then:
So things don't want to mount at all for now, however;
Changing the passphrase works, using empty passphrase works as well but doesn't mount and still ask for passphrase if I change it again unlike the first time. I can change password as much as I want and it also recognize wrong passwords while using set-passphrase.
Oddly, it also asks for the old passphrase twice.
bcachefs fsck also fails after entering the right passphrase.