[Unstable Update] 2019-02-22 - Systemd, Cryptsetup, Go, Python - might break encrypted systems with luks

unstable
update

#1

Hi community,

Welcome to another unstable update for 2019. These are additional package needed to our last update. So what do we have with this one?

  • we updated systemd to v241 - we added 257 additional patches so far to v241 series.
  • cryptsetup got downgraded to v2.0.6 as we expect some issues with v2.1 series. We also kept commit 6f177c7 to see if it acutally hurt or not. More about the systemd issue here
  • some golang packages got added
  • the usual python updates

We hope with all these changes Manjaro to be more efficient for you all.


CLT19

DzhOtsFWsAAz3SI

Manjaro will take part on the Chemnitz Linux Days in March this year. You may want to visit our booth with the latest Manjaro hardware and Core Developers present to answer your questions. Feel free to bring your devices if you want to have Manjaro installed on them or problems fixed from our experts.

Partnership with FCS Linux Aarhus

We are happy to announce a new partnership with FCS Linux Aarhus owned by @fhdk. This enables us to offer you Laptops with Manjaro pre-installed and Manjaro Stickers you can use on your own hardware or gift them to a friend. For each sale FCS will donate a percentage to the Manjaro project.

Manjaro v18.0.3 released!

We updated our flagship ISOs of Manjaro Illyria with the latest packages. It comes with refreshed packages and updated tools. You may want to download our XFCE Edition with the latest 4.13 packages, aswell as our most recent styling efforts. Our KDE fans may try our KDE Edition with the latest KDE v5.15 instead. And our GNOME fans may try our Gnome Edition with the latest GNOME v3.30.


Current supported Kernels

  • linux316 3.16.62
  • linux318 3.18.135 [EOL]
  • linux44 4.4.167 [FZN]
  • linux49 4.9.159
  • linux414 4.14.102
  • linux419 4.19.24
  • linux420 4.20.11
  • linux414-rt 4.14.93_rt53
  • linux418-rt 4.18.16_rt9

Package Updates (Fri Feb 22 21:01:05 CET 2019)

Fri Feb 22 21:01:05 CET 2019

:: Different overlay package(s) in repository community x86_64

-------------------------------------------------------------------------------
                             PACKAGE              testing             unstable
-------------------------------------------------------------------------------
                          deepin-api                    -             3.16.0-1
              deepin-desktop-schemas                    -             3.11.0-1
                       deepin-go-lib                    -              1.8.0-1
              deepin-qt-dbus-factory                    -              1.0.8-2
                   deepin-session-ui                    -              4.8.9-1


:: Different sync package(s) in repository community x86_64

-------------------------------------------------------------------------------
                             PACKAGE              testing             unstable
-------------------------------------------------------------------------------
                          deepin-api             3.16.0-1             3.17.0-1
                       deepin-daemon             3.22.0-1             3.23.0-2
                       deepin-go-lib              1.8.0-1              1.9.0-1
              deepin-qt-dbus-factory              1.0.8-2              1.0.9-1
                   deepin-session-ui              4.8.9-1             4.8.10-1
                              ledger             3.1.1-10              3.1.2-1
                                lmms           1.2.0rc7-3           1.2.0rc8-1
                        perl-json-xs               3.03-6                4.0-1
                     python-billiard            3.5.0.5-1            3.6.0.0-1
                       python-celery              4.2.1-2              4.2.1-3
                         python-cmd2              0.9.8-1              0.9.9-1
                     python-httplib2             0.12.0-1             0.12.1-1
                 python-linux-procfs                0.6-2              0.6.1-1
                    python2-billiard            3.5.0.5-1            3.6.0.0-1
                      python2-celery              4.2.1-2              4.2.1-3
                    python2-httplib2             0.12.0-1             0.12.1-1
                                 snd               18.9-2               19.1-1
                            startdde             3.11.0-2             3.12.0-1
                               tmuxp              1.5.0-1              1.5.1-1
                              albert                    -             0.16.1-1
       golang-github-davecgh-go-spew                    -              1.1.1-1
             golang-github-kr-pretty                    -              0.1.0-1
                golang-github-kr-pty                    -              1.1.3-1
               golang-github-kr-text                    -              0.1.0-1
    golang-github-pmezard-go-difflib                    -              1.0.0-1
         golang-github-stretchr-objx                    -     0.1.1.20190212-1
      golang-github-stretchr-testify                    -              1.3.0-1
                 golang-golang-x-sys                    -       0.0.20190222-1
                golang-golang-x-text                    -              0.3.0-1
               golang-golang-x-tools                    -       0.0.20190222-1
               golang-gopkg-check.v1                    -       0.0.20180629-1


:: Different overlay package(s) in repository core x86_64

-------------------------------------------------------------------------------
                             PACKAGE              testing             unstable
-------------------------------------------------------------------------------
                             systemd            241.244-1            241.257-2
                        systemd-libs            241.244-1            241.257-2
                  systemd-resolvconf            241.244-1            241.257-2
                  systemd-sysvcompat            241.244-1            241.257-2
                          cryptsetup                    - 2.1.0+really+2.0.6-1


:: Different overlay package(s) in repository extra x86_64

-------------------------------------------------------------------------------
                             PACKAGE              testing             unstable
-------------------------------------------------------------------------------
                  linux419-rtl8723bu    4.3.9.3.13200.0-4    4.3.9.3.13200.0-5
                  linux420-rtl8723bu    4.3.9.3.13200.0-3    4.3.9.3.13200.0-4


:: Different sync package(s) in repository extra x86_64

-------------------------------------------------------------------------------
                             PACKAGE              testing             unstable
-------------------------------------------------------------------------------
                         python-cffi             1.11.5-2             1.12.1-1
                        python2-cffi             1.11.5-2             1.12.1-1
                python2-configparser              3.7.1-1              3.7.2-1


:: Different overlay package(s) in repository multilib x86_64

-------------------------------------------------------------------------------
                             PACKAGE              testing             unstable
-------------------------------------------------------------------------------
                       lib32-systemd            241.244-1            241.257-2
  • No issue, everything went smoothly
  • Yes there was an issue. I was able to resolve it myself.(Please post your solution)
  • Yes i am currently experiencing an issue due to the update. (Please post about it)

0 voters

Check if your mirror has already synced:


[Unstable Update] 2019-02-28 - Kernels, Plasma5, Systemd, Mesa, Xorg-Server, Deepin
#2

Post image is still weird/broken/whatever :wink:


#3

Can you give me an example? We actually use the picture stored at twitter. Is that blocked on your end? I uploaded it now to the forum …


#4

Whereas I can load the image url directly fine.

(yes, checked private session, turning off extensions, etc.)

It’s really just me? :woman_shrugging:


#5

If this is only in unstable do we really need a +really+ or can we expect people to handle a downgrade to an overlaid 2.0.6?


#6

We need a +really+ here as this is a downgrade. Currently the setup routine in Calamares is broken when we use cryptsetup v2.1.0. See here.


#7

Ah I spoke too soon. Everything seemed fine.

But I lost my clean logs :sob: And touchscreen apparently.

$ journalctl -b -p3

kernel: AMD-Vi: Unable to write to IOMMU perf counter.
kernel: kfd kfd: Failed to resume IOMMU for device 1002:15dd
kernel: kfd kfd: device 1002:15dd NOT added due to errors
kernel: i2c_designware AMDI0010:00: controller timed out
inxi
Kernel:    4.20.11-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.2.1 Desktop: KDE Plasma 5.15.1 
           tk: Qt 5.12.1 wm: kwin_x11 dm: SDDM Distro: Manjaro Linux 
Machine:   Type: Laptop System: HUAWEI product: KPL-W0X v: M1F serial: <filter> 
           Mobo: HUAWEI model: KPL-W0X v: M1F serial: <filter> UEFI: HUAWEI v: 1.19 date: 01/11/2019 
Battery:   ID-1: BAT1 charge: 52.9 Wh condition: 54.8/56.3 Wh (97%) volts: 8.5/7.6 model: DYNAPACK HB4593R1ECW type: Li-ion 
           serial: <filter> status: Discharging cycles: 86 
CPU:       Topology: Quad Core model: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx bits: 64 type: MT MCP arch: Zen 
           L2 cache: 2048 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 31948 
           Speed: 1386 MHz min/max: 1600/2000 MHz Core speeds (MHz): 1: 1373 2: 1369 3: 1447 4: 1596 5: 1369 6: 1368 7: 1369 
           8: 1369 
Graphics:  Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] vendor: Huawei driver: amdgpu v: kernel 
           bus ID: 02:00.0 chip ID: 1002:15dd 
           Display: x11 server: X.Org 1.20.3 driver: amdgpu compositor: kwin_x11 resolution: 1920x1080~60Hz 
           OpenGL: renderer: AMD RAVEN (DRM 3.27.0 4.20.11-1-MANJARO LLVM 7.0.1) v: 4.5 Mesa 18.3.3 direct render: Yes 
Audio:     Device-1: Advanced Micro Devices [AMD/ATI] Raven/Raven2/Fenghuang HDMI/DP Audio vendor: Huawei 
           driver: snd_hda_intel v: kernel bus ID: 02:00.1 chip ID: 1002:15de 
           Device-2: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor vendor: Huawei driver: N/A 
           bus ID: 02:00.5 chip ID: 1022:15e2 
           Device-3: Advanced Micro Devices [AMD] Family 17h HD Audio vendor: Huawei driver: snd_hda_intel v: kernel 
           bus ID: 02:00.6 chip ID: 1022:15e3 
           Sound Server: ALSA v: k4.20.11-1-MANJARO 
Network:   Device-1: Intel Wireless 8265 / 8275 driver: iwlwifi v: kernel bus ID: 01:00.0 chip ID: 8086:24fd 
           IF: wlp1s0 state: up mac: <filter> 
Drives:    Local Storage: total: 238.47 GiB used: 58.60 GiB (24.6%) 
           ID-1: /dev/sda vendor: SanDisk model: SD9SN8W256G1027 size: 238.47 GiB speed: 6.0 Gb/s serial: <filter> rev: 2027 
           scheme: GPT 
Partition: ID-1: / size: 115.44 GiB used: 58.54 GiB (50.7%) fs: ext4 dev: /dev/sda5 
Sensors:   System Temperatures: cpu: 38.2 C mobo: N/A gpu: amdgpu temp: 38 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 217 Uptime: 1m Memory: 6.77 GiB used: 1.06 GiB (15.7%) Init: systemd v: 241 Compilers: gcc: 8.2.1 
           clang: 7.0.1 Shell: bash v: 5.0.0 running in: konsole inxi: 3.0.30

#8

Due to the systemd update?


#9

No, you are right, it mkinitcpiod … but the kernel stuff was this morning, which is where I suppose it is from.

[2019-02-22 04:02] [ALPM] upgraded linux419 (4.19.23-1 -> 4.19.24-1)
[2019-02-22 04:02] [ALPM] upgraded linux419-headers (4.19.23-1 -> 4.19.24-1)
[2019-02-22 04:02] [ALPM] upgraded linux420 (4.20.10-1 -> 4.20.11-1)
[2019-02-22 04:02] [ALPM] upgraded linux420-headers (4.20.10-1 -> 4.20.11-1)

anyways for half the errors … the kfd looks to be the same as:
https://bugs.freedesktop.org/show_bug.cgi?id=107898
Workaround:
iommu=pt


#10

Yes, but if it’s only in unstable does it need to be repackaged, or can it just be reverted?

I don’t really care either way, I’m just wondering if it saves work in the longer term.

Oh, I see - cryptsetup-2.1.0 is already in stable. Makes sense now.


#11

After thinking a little more the workaround for the encrypted home issue is actually pretty easy.

I did another VM installation with manjaro-kde-18.0.3-pre2, manual partition with encrypted home partition, reboot, same crash. Status quo.

Boot live ISO, mount unencrypted root partition, edit /etc/crypttab and remove the keyfile reference (ie /crypto_keyfile.bin), save and reboot.

Successful boot, asking for encypted home password, system includes both cryptsetup 2.1 and the “problematic” systemd cryptsetup commit.

The problem is Calamares I think. The /etc/crypttab file references the keyfile which does not exist. Also cryptsetup luksDump on the luks2 home partition indicates only one configured keyslot, which is presumably the password slot. There is no keyslot for the keyfile, which does not exist anyway.

Should this setup crash is the $64k question and something Poettering et al can probably answer. If there is no keyfile should systemd cryptsetup be robust enough to skip it and password prompt instead? IDK enough to give an informed opinion.

So, Calamares encryption setup needs closer inspection.

For full system encryption the keyfile is generated, referenced in /etc/crypttab for all entries, and a luks2 keyslot is created for both password and keyfile for each luks2 partition.

For single partition encryption in manual partitioning the keyfile is not generated, it is referenced in /etc/crypttab, and only a single luks2 keyslot is created for the password.

I have not used manual partition to setup multiple luks2 partitions, so don’t know if it works … maybe a task for this weekend.

Cryptsetup is not the issue here, it doesn’t need to be downgraded, the solution is to remove the keyfile reference in /etc/crypttab and fix Calamares manual partition encryption logic IMO.

EDIT :

Did another test install with multiple encrypted partitions (home and data) and same crash. Remove keyfile reference in crypttab for both entries and boots successfully, prompting for password correctly.

So Calamares manual partitioning logic does not differ no matter how many luks partitions are created. I thought maybe mulitple partitions would prompt the creation of a keyfile, but alas not.


#12

Good work and troubleshooting, @sueridgepipe!!!

:+1:


#13

Heh. Pottering: it’s not a bug. Your userland is broken! :laughing:


#14

Hey guys, can you push Latte-dock?? it’s already on 8.6.

Thanks for your work.


#15

Awesome work man!


#16

This latest took out the DKMS with broadcom-wl. I had to go back to stable.


#17

I confirm that it works. It even works on my Namib virtual machine (having this VM ended up being useful at the end I guess) that ends up having the exact same issue that we faced (using systemd 241.7 package from Arch Linux). This VM has a unencrypted, regular / partition and an encrypted /home partition, and the distro has been installed with Calamares.

Screenshot

Removing the keyfile reference in /etc/crypttab fixes the issue completely on Namib with systemd from Arch.

Both Namib and Manjaro uses Calamares.

The thing is, I think Calamares decided to include that additional line in case the user use that keyfile after installation, so he/she don’t have to modify his /etc/crypttab file to use it.

And it worked perfectly fine before, even if the crypttab had that reference pointing to a file that didn’t exist. So for me, systemd definitely introduced a regression, most likely accidentally because maybe they didn’t know that there are installers that configure /etc/crypttab that way.

Also, even if Calamares devs remove that behavior on their side, the harm is already done on all current installations that use encrypted partitions configured with Calamares. To prevent a more or less massive amount of regression on Manjaro users without having to keep the revert in systemd code forever, systemd devs has to fix the bug in their code and support a the non-existence of the file. If the file specified in crypttab, it should use the manual password prompt as a fallback.


I reported to upstream the new discoveries on our side about this issue (and quoted @sueridgepipe work on this issue too).


[Testing Update] 2019-03-09 - Kernels, KDE Apps, Nvidia, Deepin, LibreOffice, PHP, Xorg
#18

#19

Is that a systemd bug though? Sounds more like a Calamares bug to me, one that systemd has only started detecting / rejecting.

Maybe systemd could treat this as a warning and continue, instead of an error and exit, but IMO there should be no onus on systemd to support blatantly incorrect luks2 configurations simply because a popular installer messed up.

The fix is simple enough, surely users can handle editing one file?

Whatever systemd does the Calamares partition module needs fixing. Either leave the keyfile reference in crypttab and actually create it, or remove the keyfile reference from crypttab.

Personally, I think the more consistent solution is to create the keyfile and keyfile keyslot always, whether full system or individual partition encryption is being setup.


#20

You’re asking Manjaro users to read and apply instructions? You have a lot of faith, do you? :grinning:

Joke aside, yeah, perhaps Calamares should fix this behavior I guess, even if systemd ends up using the fallback approach instead of the “nah, I’m out” approach, even if there might be a real reason (by design) why Calamares does such a weird configuration.

If systemd refuse do change this, Calamares won’t have any choice but to remove that behavior (or actually generate the bin file), or else their installer will be unusable with crypted partitions, because not every distro will just revert the same commit than us on their systemd. Reverting the commit might also introduces other issues too in the future, so we can’t just keep it forever.

If systemd devs refuse to change how systemd handles that kind of situation, I’m afraid Manjaro will have no choice but to ask for a manual intervention (doing some sed magic seems risky as f-.)

If we need to ask user for manual intervention, I think it should be announced a couple of days in preparation for the incoming upgrade. I mean, if you ask for a manual intervention in a single announcement, it could make it look like “REALLY IMPORTANT”, more important than if it was like a single paragraph in a whole update announcement (or just in the wiki post). There might be people who won’t read anyway, but if it can save a little bit more installation, why not?

For now, wait and see?

Reported to Calamares by someone in the systemd issue discussion