[Testing Update] 2019-02-14 - Kernels, Systemd, Browsers, Calamares, Firmware, Plasma5, KDE Framework

Sorry my last post's final Edit got aborted. FF-Dev suddenly went mad & used up 100% cpu on at least one core, & stole ~15 extra GB RAM. I had to kill it in a hurry. This is about the half-dozenth time that this Dev version has done this, over the past ~week.

The pics themselves are not truncated; they comprise 100% of the visible text in the VM tty tiny window. It is there that the text is cropped, & i know not how to access the complete lines w/o that cropping. I am still in the tty not to make your life miserable, but simply because i made my first post herein immediately after my Testing VM failed on its reboot, & neither i nor anyone else til now had suggested going Live... i've been just flat out trying to comprehend & diligently perform all your [extremely helpful] instructions... but getting churlish at me now is rather unbecoming.

All good on this end!

That is exactly the point!

Diagnosing and troubleshooting from tty is next to useless compared to a fully functional live desktop enviroment ... where no text is cropped and cut and paste actually works.

Anyway your problem is the keyfile is not being read, hence the luks partition could not be opened. I can't tell exactly why because important text is truncated.

I've just rebooted VM via LiveISO, & have now chrooted in. Happily i can access my VM's home contents therein*. Now to catch my breath & contemplate my next steps.

Some time later... *am just now rephrasing my original words above, as i see now they might be unintentionally misleading. So far i have not attempted to access my encrypted /home data from within the chroot running in the LiveISO's Konsole. When i mentioned that i can happily see all my /home data, i simply meant that if i launch Dolphin in this LiveISO i can [after supplying my password] access all my directories & files within /home. So, really, i've not actually yet done much of anything in the Konsole chroot, other than simply access some of my / system files to confirm correct UUIDs etc.

Edit: Um, sad:

[root@manjaro /]# systemctl list-units systemd-cryptsetup*
Running in chroot, ignoring request: list-units
[root@manjaro /]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        30G   21G  6.9G  76% /
/dev/dm-0       7.9G  4.2G  3.3G  56% /home
dev             5.9G     0  5.9G   0% /dev
tmpfs           5.9G  8.0K  5.9G   1% /tmp
run             5.9G   69M  5.8G   2% /run
[root@manjaro /]# systemctl status systemd-cryptsetup@luks\\x2db6163f1a\\x2d778f\\x2d4c0d\\x2daa9a\\x2d28ae8f712ef1.service
Running in chroot, ignoring request: status
[root@manjaro /]#

I have not yet done your...

...[coz atm i've not deduced the specific command string i need to use] - is this likely to explain the un-success listed in my codebox above?


All good here on an Ryzen/Vega Desktop system with no encryption. Updated systemd, rebooted several times and played some games for some hours, all stable. Version 240 already crashed several times while testing it that way.

Installed a KDE VM system, manually partitioned with efi boot partition, root partition and separate encrypted home partition.

Getting same error as @Kadee on first boot ...

manjaro-kde systemd-cryptsetup[269]: Failed to open key file.
manjaro-kde systemd-cryptsetup[269]: Failed to activate with the key file '/crypto_keyfile.bin' : Invalid argument
manjaro-kde systemd[1]: Failed to start Cryptography Setup for luks-[UUID]

Not sure what argument is failing, but systemd has changed and current config crashes.

I'll now try an installation with full disk encryption and auto partitioning.


"systemd-libs and libsystemd are in conflict. Remove libsystemd? [y/N] "

What to do?

To open an encrypted luks partition

sudo cryptsetup open /dev/sdXX [label]

To mount this opened luks partition

sudo mount /dev/mapper/[label] [mount-point]

The label can be anything your want, like home, or whatever.

Running in chroot, ignoring request: list-units

Systemctl doesn't work in chroot, many service specific systemd commands don't work within chroot.

Only real option on systemd distros like Arch and Manjaro is systemd-nspawn, but in this case it is not necessary as the error message has been captured.


FWIW I don't think the issue is with your system, but actually a systemd 241 regression.


Accept. I had the same behaviour here and no problems on next boot. Besides waiting for user managing change on restart.

1 Like

I'm sensing that there's likely not much more value to be gained atm from persisting with this now-borked VM, but for the record, here's apropos info copied from my chrooted VM [no pics]. As far as i can see, my UUIDs continue to match up correctly... after all, my VM had been working very sweetly up until the reboot following this morning's big update.


From chrooting into my borked Testing VM:

[root@manjaro /]# sudo blkid
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/sda1: UUID="57a0d4a6-a099-4e13-a7a0-20d5415482f8" TYPE="ext4" PARTUUID="f65eb127-75af-469f-ab5e-c2c54efc4f90"
/dev/sda2: UUID="c553c991-5785-440c-a63f-8e0103d75235" TYPE="crypto_LUKS" PARTUUID="1089b78d-3fc1-43d5-95c9-baa41bdaec0b"
/dev/sda3: UUID="b6163f1a-778f-4c0d-aa9a-28ae8f712ef1" TYPE="crypto_LUKS" PARTUUID="5a249bdc-3640-4fd6-989b-14a7e946ae8d"
/dev/sr0: UUID="2018-04-15-11-39-13-00" LABEL="MJRO1718" TYPE="iso9660" PTTYPE="dos"
/dev/mapper/luks-b6163f1a-778f-4c0d-aa9a-28ae8f712ef1: UUID="527f1069-0642-488a-b3f1-a73e252583ea" TYPE="ext4"
[root@manjaro /]# 

[root@manjaro /]# sudo nano /etc/crypttab

 /etc/crypttab: mappings for encrypted partitions.
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/<name> paths for encrypted devices.
# See crypttab(5) for the supported syntax.
# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
#       to encrypted swap, which should be set up with mkinitcpio-openswap
#       for resume support.
# <name>                                        <device>                                      <password>            <options>
# luks-c553c991-5785-440c-a63f-8e0103d75235     UUID=c553c991-5785-440c-a63f-8e0103d75235     /crypto_keyfile.bin   luks
luks-b6163f1a-778f-4c0d-aa9a-28ae8f712ef1       UUID=b6163f1a-778f-4c0d-aa9a-28ae8f712ef1     /crypto_keyfile.bin   luks

[root@manjaro /]# sudo nano /etc/fstab

# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=57a0d4a6-a099-4e13-a7a0-20d5415482f8 /              ext4    defaults,noatime 0 1
# kdemeoz 10/8/18:   I've DISABLED my hitherto encrypted Swap partition by commenting out the following, here & also in /etc/crypttab [i grew fed up with having to enter my password **twice** each boot, once to mount+decrypt /home, then again for Swap]. So that i still have a Swap capacity i've now also installed & enabled+started zramswap from AUR.
# /dev/mapper/luks-c553c991-5785-440c-a63f-8e0103d75235 swap           swap    defaults,noatime 0 2
/dev/mapper/luks-b6163f1a-778f-4c0d-aa9a-28ae8f712ef1 /home          ext4    defaults,noatime 0 2
# [kdemeoz@Manjaro_KDE_VM ~]$ sudo blkid    # 11/8/18, AFTER deactivating my encrypted Swap partition, & using zramswap:
# [sudo] password for kdemeoz:
# /dev/sda1: UUID="57a0d4a6-a099-4e13-a7a0-20d5415482f8" TYPE="ext4" PARTUUID="f65eb127-75af-469f-ab5e-c2c54efc4f90"
# /dev/sda2: UUID="c553c991-5785-440c-a63f-8e0103d75235" TYPE="crypto_LUKS" PARTUUID="1089b78d-3fc1-43d5-95c9-baa41bdaec0b"
# /dev/sda3: UUID="b6163f1a-778f-4c0d-aa9a-28ae8f712ef1" TYPE="crypto_LUKS" PARTUUID="5a249bdc-3640-4fd6-989b-14a7e946ae8d"
# /dev/mapper/luks-b6163f1a-778f-4c0d-aa9a-28ae8f712ef1: UUID="527f1069-0642-488a-b3f1-a73e252583ea" TYPE="ext4"
# /dev/zram0: LABEL="zram0" UUID="7eb6759d-5535-4044-90ef-82b38fd27665" TYPE="swap"
# /dev/zram1: LABEL="zram1" UUID="f6e2ceb1-38e0-455c-93d1-9d8874e1e318" TYPE="swap"
# [kdemeoz@Manjaro_KDE_VM ~]$

So should i just set this dead VM aside for now, & await some singular magic from @philm re a putative better future systemd 241 version that i could install then via chroot to resucitate my poor VM?

Question, and forgive my ignorance, shouldn't the acpid.service be enabled by default ?

I'm even way more ignorant, but:

Note: Desktop environments, such as GNOME, systemd login manager and some extra key handling daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.


I guess nowadays it's functions are superseded by systemd and udev rules to the point of being almost deprecated. Unless special arbitrary conditions are required.

1 Like

No issue updating 3 KDE installations from tty as @sueridgepipe suggested. Need to say that I have no encrypted partition.

Cryptsetup changelog 2.1 has some info, not sure if it helps:

Cryptsetup 2.1 version uses a new on-disk LUKS2 format as the default
LUKS format and increases default LUKS2 header size.

The legacy LUKS (referenced as LUKS1) will be fully supported forever
as well as a traditional and fully backward compatible format.

When upgrading a stable distribution, please use configure option
--with-default-luks-format=LUKS1 to maintain backward compatibility.

This release also switches to OpenSSL as a default cryptographic
backend for LUKS header processing. Use --with-crypto_backend=gcrypt
configure option if you need to preserve legacy libgcrypt backend.

Please do not use LUKS2 without properly configured backup or
in production systems that need to be compatible with older systems.

1 Like

Where is that set?

Small, niche Manjaro user base being used as systemd guinea pigs without upstream quality assurance testing really is BS.

Ever since we started rolling our own before Arch it has been a complete clusterf**k, totally unacceptable TBH.

1 Like

Probably with luksOpen, but I haven't updated yet.

EDIT: or as a boot parameter with luks.options=options which will be used by systemd-cryptsetup-generator. forget what I wrote.

In the ./configure command before make? But I'm not sure.

But I thought it is only for newly created LUKS devices. Because I can start my system with cryptsetup-2.1.0-1 and the LUKS header shows

Version:       1
Cipher name:   aes
Cipher mode:   xts-plain64
Hash spec:     sha512

But I use the sd-encrypt hook for the / partition.

1 Like

One could also try converting from LUKS1 to LUKS2 with cryptsetup convert (backup of LUKS header mandatory!).

Is that something viable for those of us with already-broken systems can do... or is my horse bolted now? [if not bolted, then maybe in the glue factory].

I would not do it just yet, and I have no idea whether it will actually help with the issue. I'm fishing in the dark and I haven't done the update yet.

1 Like

Forum kindly sponsored by