[Testing Update] 2019-02-15 - Kernels, Grub, Systemd, Haskell, Python

update
testing

#21

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.


#22

Full encrypted installation with systemd241.71-1 Kernel: x86_64 Linux 4.20.9-1-MANJARO
update went just fine.


#23

The systemd log issue with plenty of messages like

Feb 15 07:16:38 manjaro systemd-udevd[217]: /usr/lib/udev/rules.d/50-udev-default.rules:20: Invalid GROUP operation

is fixed in systemd:master:

Closed #11720 via #11726.


#24

A note/remark:
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.

UPDATE:
Issue solved by

:hugs::smiling_face_with_three_hearts:


#25

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 <torvalds@linux-foundation.org>
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 <samuel@dionne-riel.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

#26

Phil has already done this now.


#27

@sueridgepipe, @kdemeoz, @Frog Seems upstream needs more information on the setup to find a proper fix for the systemd issue we have in v241. This is what Lennart posted:

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?


#28

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 systemd-cryptsetup@xxx.service?

…& 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 systemd-cryptsetup@xxx.service means. :blush:


#29

I also don’t have that file on my VMs that have an encrypted /home.


closed #30

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.