Indeed, this is the one I referenced too … that explains the issues, however if they Arch build works just stick with it in the short term.
Full encrypted installation with systemd241.71-1 Kernel: x86_64 Linux 4.20.9-1-MANJARO
update went just fine.
The systemd log issue with plenty of messages like
Feb 15 07:16:38 manjaro systemd-udevd: /usr/lib/udev/rules.d/50-udev-default.rules:20: Invalid GROUP operation
is fixed in systemd:master:
Whatever was introduced/modified in the linux420 and linux419 kernels, makes the wacom tablet not only to connect/disconnect (as before), but once is again manually disconnected and connected, the mapping goes off with an internal error, rendering the tablet unusable. I didn’t had much time to play around, it works in linux414 with no issue.
Later i will post more findings about it.
Issue solved by
All kernels in Manjaro testing need an update:
linux414 4.14.100-1 linux419 4.19.22-1 linux420 4.20.9-1
They all have the same issue and should be replaced with the next version. All next versions have the same commit reverted:
Author: Linus Torvalds <email@example.com> Date: Thu Feb 14 15:02:18 2019 -0800 Revert "exec: load_script: don't blindly truncate shebang string" commit cb5b020a8d38f77209d0472a0fea755299a8ec78 upstream. This reverts commit 8099b047ecc431518b9bb6bdbba3549bbecdc343. It turns out that people do actually depend on the shebang string being truncated, and on the fact that an interpreter (like perl) will often just re-interpret it entirely to get the full argument list. Reported-by: Samuel Dionne-Riel <firstname.lastname@example.org> Acked-by: Kees Cook <email@example.com> Cc: Oleg Nesterov <firstname.lastname@example.org> Signed-off-by: Linus Torvalds <email@example.com> Signed-off-by: Greg Kroah-Hartman <firstname.lastname@example.org>
Phil has already done this now.
So, that file /crypto_keyfile.bin does it actually contain a valid key?
Previously, if we get EINVAL from an attempt to activate some disk while passing a key file, we’d try again with a password prompt to the user. Now we only do that if we get EPERM (which is the usual error the kernel returns if the key is not correct).
Hence, does /crypto_keyfile.bin actually work? is that file valid? or did you just specify it but enter the password manually anyway?
Hi Phil. I don’t know that i can help much here, as i’m way beyond my comfort/knowledge level in this area. I can tell you though that my KDE VM [with ext4
/ & LUKS
/home] which broke with that recent 241, does NOT have any such file as
/crypto_keyfile.bin. I don’t even know what it’s for. My Tower’s & Lappy’s real KDEs [same partition structure wrt
/home] also do not have this file. All i know is that my VM & real systems normally boot fine, halting at one early point for me to enter my decryption password, after which the rest of the startup process eventually takes me to the SDDM login & thence my Plasma desktop. When my Testing VM broke with that 241 version, it basically went into rescue mode very early in the boot process… certainly well before i should have been asked for my password. Sorry i cannot really help you better.
Edit: I don’t know if this is relevant or helpful, but fyi, this is for that VM:
[kdemeoz@ManjaroTestingKDEVM ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 40G 0 disk ├─sda1 8:1 0 30G 0 part / ├─sda2 8:2 0 2G 0 part └─sda3 8:3 0 8G 0 part └─luks-b6163f1a-778f-4c0d-aa9a-28ae8f712ef1 253:0 0 8G 0 crypt /home sr0 11:0 1 1024M 0 rom zram0 252:0 0 1.2G 0 disk [SWAP] zram1 252:1 0 1.2G 0 disk [SWAP]
Edit: This seems a bit odd. I just noticed https://github.com/systemd/systemd/issues/11723#issuecomment-464551629…
Could you show /etc/crypttab and generated email@example.com?
…& so i ran
sudo nano crypttab, in which i see:
luks-b6163f1a-778f-4c0d-aa9a-28ae8f712ef1 UUID=b6163f1a-778f-4c0d-aa9a-28ae8f712ef1 /crypto_keyfile.bin luks
…but as i said already,
/crypto_keyfile.bin does not exist [or if it does, i cannot see it].
I do not know what
generated firstname.lastname@example.org means.
I also don’t have that file on my VMs that have an encrypted /home.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.