Unable to start systemd-nspawn machines with LUKS encrypted storage (XFS in my case): #2121883

Starting systemd-nspawn@mymachine.service - Container mymachine... loop0: detected capacity change from 0 to 20975616 loop0: p1 Failed to dissect image '/var/lib/machines/mymachine.raw': Connection timed out systemd-nspawn@mymachine.service: Main process exited, code=exited, status=1/FAILURE systemd-nspawn@mymachine.service: Failed with result 'exit-code'. Failed to start systemd-nspawn@mymachine.service - Container mymachine.

Normally, and in 5.18.x kernels, I would get the prompt to enter the LUKS password to decrypt the volume.

Otherwise the update seems to be generally functional so neutral karma.

In-place upgrade from 3.2 worked well, following https://www.cyrusimap.org/3.4/imap/download/upgrade.html

Monitoring, but have not encountered the issue reported by @agurenko in #2055362. In my case, my NFS server is on kernel-5.16.9-200.fc35.x86_64, my NFS clients are on kernel-5.16.10-200.fc35.x86_64, and both server and clients have nfs-utils-2.5.4-2.rc3.fc35.x86_64.

Update functions well. Noted duplication of HoldQuarantinedMessages section before and after IgnoreAuthenticatedClients in /etc/opendmarc.conf

##  HoldQuarantinedMessages { true | false }
##      default "false"
##
##  If set, the milter will signal to the mta that messages with
##  p=quarantine, which fail dmarc authentication, should be held in
##  the MTA's "Hold" or "Quarantine" queue.  The name varies by MTA.
##  If false, messsages will be accepted and passed along with the 
##  regular mail flow, and the quarantine will be left up to downstream
##  MTA/MDA/MUA filters, if any, to handle by re-evaluating the headers,
##  including the Authentication-Results header added by OpenDMARC
#
# HoldQuarantinedMessages false

@kalvinist -- you are right -- thank you for the link.

New 1:30 boot delay noticed with this upgrade, though it may not be specifically related to the kernel. Occurs on Thinkpad X1 and several Intel NUCs:

Jul 02 21:33:36 systemd[1]: Found device /dev/mapper/fedora_ws1m-root.
Jul 02 21:33:36 systemd[1]: Reached target Initrd Root Device.
Jul 02 21:35:06 dracut-initqueue[895]: WARNING: D-Bus notification failed: Transport endpoint is not connected
Jul 02 21:35:06 systemd[1]: Found device /dev/mapper/fedora_ws1m-swap.

No negative Karma as otherwise general function seems unaffected.

Fixes #1943870

taglib-1.12-4.fc33 fixes #1943870. Thank you @rdieter.

#1943870

@kevin I have been running the web interface for a number of years with a public cert (LetsEncrypt). Since Fedora 14, I had used a Kerberos-enabled Koji infrastructure rather than one based on certificates so I only needed the cert for the public interfaces (web, kojihub, etc.)

I'm just noting that KojiHubCA wasn't required before (even when using TLS) and now it is.

Generally functional, but is seems now that the web.conf KojiHubCA option is now required after: https://pagure.io/koji/c/74061d5d710155c0888c155df0ac3c0c40a96d41?branch=master

Maybe a sane default if not provided, like /etc/pki/tls/cert.pem would be nice.

The upgrade from freeipa-4.9.1-1.fc33 (https://bodhi.fedoraproject.org/updates/FEDORA-2021-f9332084e0) processed smoothly. I received the following afterward:

ns-slapd[3564]: [16/Feb/2021:14:51:42.716922896 -0600] - ERR - set_krb5_creds - The server will use the external SASL/GSSAPI credentials cache [FILE:/tmp/krb5cc_389].  If you want the server to automatically authenticate with its keytab, you must remove this cache.  If you did not intend to use this cache, you will likely see many SASL/GSSAPI authentication failures.

Then restarted both of my FreeIPA instances and I haven't seen this again.