[Bug 2064096] Autopkgtest regression report (systemd/255.4-1ubuntu8.1)

Thu May 23 01:07:09 UTC 2024

All autopkgtests for the newly accepted systemd (255.4-1ubuntu8.1) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

389-ds-base/unknown (armhf, s390x)
aide/unknown (s390x)
amavisd-new/unknown (s390x)
apport/2.28.1-0ubuntu3 (arm64)
apport/unknown (s390x)
appstream/unknown (s390x)
apt/2.7.14build2 (armhf)
apt/unknown (s390x)
asterisk/unknown (s390x)
at-spi2-core/unknown (s390x)
ayatana-indicator-session/unknown (s390x)
bind9/unknown (amd64, armhf, i386, s390x)
bolt/unknown (amd64, s390x)
casper/unknown (s390x)
casync/unknown (s390x)
ceph/unknown (s390x)
clamav/unknown (amd64)
clevis/unknown (s390x)
cloudflare-ddns/unknown (s390x)
clutter-1.0/unknown (amd64)
cockpit/unknown (s390x)
collectd/unknown (s390x)
colord/unknown (s390x)
comitup/unknown (amd64, s390x)
conntrack-tools/unknown (amd64)
corosync/3.1.7-1ubuntu3 (arm64)
corosync/unknown (s390x)
corosync-qdevice/unknown (amd64, s390x)
coturn/unknown (armhf, s390x)
cron/unknown (ppc64el, s390x)
crun/unknown (amd64, s390x)
cryptsetup/2:2.7.0-1ubuntu4 (arm64)
csync2/unknown (amd64, s390x)
cups/unknown (amd64, s390x)
dbus/1.14.10-4ubuntu4 (i386)
dbus/unknown (amd64, armhf, s390x)
dbus-broker/unknown (amd64, s390x)
debos/unknown (amd64)
dhcpcd/unknown (armhf, s390x)
dlm/unknown (amd64)
dovecot/unknown (amd64)
dpdk/23.11-1build3 (amd64)
dq/20240101-1 (amd64)
exim4/unknown (amd64, armhf)
expeyes/unknown (amd64)
fcgiwrap/unknown (amd64)
fluidsynth/unknown (amd64, i386)
freedom-maker/unknown (amd64, armhf, i386)
freedombox/unknown (amd64)
freeradius/unknown (amd64)
fwupd/unknown (amd64)
gamemode/unknown (i386)
gdm3/unknown (amd64)
golang-github-coreos-go-systemd/unknown (amd64)
gpsd/unknown (amd64)
gvfs/unknown (s390x)
haproxy/unknown (amd64)
hddemux/unknown (amd64)
hwloc/unknown (amd64, s390x)
incus/unknown (amd64)
init-system-helpers/unknown (amd64)
initramfs-tools/unknown (amd64)
interception-tools/unknown (amd64)
janus/unknown (amd64)
keyman/unknown (amd64)
knot/unknown (amd64)
knot-resolver/unknown (amd64)
libcamera/0.2.0-3fakesync1build6 (amd64, armhf)
libei/1.2.1-1 (amd64)
libinput/unknown (amd64)
liblinux-systemd-perl/unknown (amd64)
libreswan/unknown (amd64)
libsdl2/unknown (amd64)
libsfml/2.6.1+dfsg-2build2 (armhf)
libsfml/unknown (amd64)
libsoup2.4/2.74.3-6ubuntu1 (ppc64el)
libsoup2.4/unknown (amd64)
libsoup3/unknown (amd64)
libusbauth-configparser/unknown (amd64)
libvirt/unknown (amd64)
lighttpd/unknown (amd64)
linux-ibm/unknown (amd64)
logiops/unknown (amd64)
logrotate/unknown (amd64)
mariadb/unknown (amd64)
mediawiki/unknown (amd64)
mir/unknown (amd64)
mkosi/unknown (amd64)
monitoring-plugins-systemd/unknown (amd64)
mosquitto/unknown (amd64)
multipath-tools/unknown (amd64)
munin/unknown (amd64)
mutter/unknown (amd64)
nagios-tang/unknown (amd64, s390x)
ndctl/unknown (armhf, s390x)
network-manager/unknown (amd64, s390x)
nextepc/unknown (amd64)
nix/unknown (amd64, armhf)
nut/unknown (amd64, armhf, s390x)
open-build-service/unknown (amd64)
openssh/unknown (amd64)
openvpn/unknown (amd64)
openzwave/unknown (amd64)
ovn/unknown (amd64)
pam/unknown (amd64, i386)
pdns-recursor/unknown (amd64)
pgagroal/unknown (amd64)
pgbouncer/unknown (amd64)
pglistener/unknown (amd64)
php8.3/unknown (amd64)
pipewire/unknown (amd64)
policykit-1/unknown (amd64)
polkit-qt-1/unknown (amd64)
postgresql-16/unknown (amd64, s390x)
procps/unknown (armhf)
prometheus-homeplug-exporter/unknown (armhf)
prometheus-postfix-exporter/0.3.0-4build1 (armhf)
pulseaudio/unknown (amd64)
puppet-agent/unknown (armhf)
pystemd/0.13.2-1build2 (armhf)
pystemd/unknown (amd64, s390x)
python-dbusmock/unknown (s390x)
python-sdbus/unknown (s390x)
python-systemd/unknown (s390x)
pyudev/unknown (amd64, s390x)
qlcplus/unknown (amd64, armhf, s390x)
rbldnsd/unknown (amd64, armhf, s390x)
redis/unknown (amd64)
remctl/unknown (amd64, s390x)
rsyslog/8.2312.0-3ubuntu9 (amd64)
rtkit/unknown (s390x)
rust-whoami/unknown (amd64)
samba/2:4.19.5+dfsg-4ubuntu9 (arm64)
samba/unknown (s390x)
seatd/unknown (i386)
shibboleth-sp/unknown (s390x)
sks/unknown (s390x)
smcroute/unknown (amd64, s390x)
snapd/unknown (s390x)
squid/unknown (s390x)
sssd/unknown (amd64)
stayrtr/unknown (s390x)
strongswan/unknown (amd64, arm64)
stunnel4/unknown (amd64)
tgt/unknown (amd64, s390x)
tinyssh/20240101-2 (arm64, s390x)
tinyssh/unknown (amd64)
tmux/unknown (s390x)
tpm2-abrmd/unknown (amd64, s390x)
udisks2/unknown (amd64)
umockdev/unknown (amd64, s390x)
upower/1.90.3-1 (armhf)
upower/unknown (s390x)
usbauth/unknown (amd64, s390x)
util-linux/unknown (amd64)
vlc/3.0.20-3build6 (arm64)
vlc/unknown (i386)
weston/unknown (amd64)
yder/unknown (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/noble/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/2064096

Title:
  Services fail to start in noble deployed with TPM+FDE

Status in apparmor package in Ubuntu:
  New
Status in cups package in Ubuntu:
  Confirmed
Status in rsyslog package in Ubuntu:
  Confirmed
Status in sssd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in apparmor source package in Noble:
  New
Status in cups source package in Noble:
  New
Status in rsyslog source package in Noble:
  New
Status in sssd source package in Noble:
  New
Status in systemd source package in Noble:
  Fix Committed

Bug description:
  [Impact]

  On systems that have systemd in the initrd, after the switch root,
  services trying to access resources in /run (e.g. /run/systemd/notify)
  will get AppArmor denials. This is because as a part of the switch
  root, before the pivot_root(), the /run (and /proc, /sys, /dev) are
  "moved" with a bind mount. Hence the new /run has a different mount
  id, and AppArmor thinks that e.g. /run/systemd/notify is disconnected
  from the current mount tree.

  [Test Plan]

  The simplest way to test this is to use dracut on a classic Ubuntu
  system:

  1. Create a VM running Ubuntu 24.04 LTS. The virtualization implementation is not important.
  2. Install dracut, and then reboot.

  $ apt install -y dracut

  3. Once rebooted, verify that systemd did a switch root:

  $ journalctl -b --grep "Switching root"

  4. Check for rsyslog AppArmor denials:

  $ dmesg | grep rsyslog

  On an affected system, the denials will be present. With the patch,
  there should be no denials (or at least not related to accessing files
  in /run).

  [Where problems could occur]

  Using MS_MOVE rather than MS_BIND for /run during the switch root means that there is a brief time where /run (in the old root) is not available for units running before the pivot_root(). So, if we were to see problems, it would likely
  be related to problems with resources in /run, very close to the switch root timeframe. However, before noble, the switch root *is* done using MS_MOVE on /run (and /proc, /sys, and /dev), so have reasonable evidence that this is a safe change.

  [Other information]

  We only change the flags for /run because that is the filesystem that
  seems affected in practice. In particular, we leave /proc alone
  because code in systemd may use /proc between the time it is moved to
  the new root, but before the pivot_root(), which would be a riskier
  change.

  [Original Description]

  What's known so far:
  - 24.04 desktop deployed with TPM+FDE shows this bug
  - services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
  - only after running aa-disable <path> can the service start fine
  - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......".
  - When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
  - other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
  - comment #2 also states that azure CVM images are also impacted
  - comment #4 has instructions on how to create such a VM locally with LXD vms

  Original description follows:

  This might be related to #2064088

  The rsyslog service is continually timing out and restarting. If I use
  a service drop-in file and change the 'Type' from 'notify' to
  'simple', the service starts and appears to work normally.

  In the journal, I can see the attached apparmor errors. I can't make
  sense of them, but if it's a similar issue to #2064088, then I suspect
  apparmor is preventing the systemd notify function from alerting
  systemd that the service is up and running.

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: rsyslog 8.2312.0-3ubuntu9
  ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
  Uname: Linux 6.8.0-31-generic x86_64
  ApportVersion: 2.28.1-0ubuntu2
  Architecture: amd64
  CasperMD5CheckMismatches: ./boot/grub/grub.cfg
  CasperMD5CheckResult: fail
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr 29 10:37:46 2024
  ProcEnviron:
   LANG=en_GB.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=<set>
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2064096/+subscriptions