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

update
testing

#61

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.

Summary

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?


Encrypted /home inaccessible with systemd 241
#62

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


#63

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.

https://wiki.archlinux.org/index.php/acpid
https://wiki.archlinux.org/index.php/Power_management#ACPI_events

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.


#64

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


#65

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.


#66

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.


#67

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.


#68

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.


#69

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


#70

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].


#71

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.


#72

Worms or yabbies?


#73

Maybe passing the keyfile as a boot parameter could work?
rd.luks.key=b40f1abf-2a53-400a-889a-2eccc27eaa40=/keyfile:LABEL=keydev
(adapt UUID, and filename accordingly)


#74

Tis all getting a bit too voodoo black magic for lil ol’ moi atm. I might retreat to loungeroom & NF away the next few hours, to soothe my jaded nerves.

Oh if only i had taken that snapshot this morning in my VM before doing the update. Ha! I would have, too, but dumb me actually forgot she had a LUKS-home in this VM, & so thought “my Unstable update went fine, ipso facto so shall this one”. Sigh.


#75

Big question is why do some luks systems fail and others do not.

The 4 fully encrypted luks systems I have updated on unstable and testing all had no issues, no errors thrown during update, no boot journal errors, nada.

These are all old installs though, what has changed?

Has to be something to do with the default Calamares encryption config when individual partitions are selected for encryption in manual partitioning.

I triggered the same error as @kdemeoz by simply installing with the latest ISO build based on these packages, with an encrypted home partition. When I tried a full encryption install it installed a completely unencrypted system, so something is definitely screwy.


#76

I set up my LUKS devices on my own. I did not use the Calamares encryption option or the architect.


#77

That is well and good but the vast majority of Manjaro users use this distro so they don’t have to do this manually … it is kinda the whole selling point of Manjaro, ease of installation.


#78

The issue has been acknowledge as a bug and will be fixed soon they say.


#79

I know. I just wanted to say the reason why it might be working for me is because of that.
So, confirming your theory.

I don’t wanted to say that everybody should create it’s own LUKS devices.


#80

if your problem is the same as mine you can try with a systemd downgrade that worked for me