Services fail to start in noble deployed with TPM+FDE

[James Paton-Smith]

[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)

[Gauthier Jolly (gjolly)]

Azure CVM images are impacted by the same issue. I see on #2064088 that this is an tpm-backed FDE system. So I think it's the same problem here if those desktop images use an systemd-based initramfs.

For now I suspect that the issue is due to systemd starting services and setting up UNIX sockets (eg /run/systemd/journal/dev-log, /run/systemd/notify and others) before doing the pivot_root and reexec. Then, when apparmor tries to resolve the path of the peer socket it fails here[1] I believe.

[1] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble/tree/fs/d_path.c#n125

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Simon Déziel (sdeziel)]

Here's how to reproduce this in a LXD VM:

Download Ubuntu 24.04 Desktop image into ~/Downloads

Import the ISO
$ lxc storage volume import default ~/Downloads/ubuntu-24.04-desktop-amd64.iso 24.04-desktop --type=iso

Prepare a LXD VM
$ lxc init --empty --vm lxd-noble-fde -c limits.memory=6GiB -c limits.cpu=4 -d root,size=32GiB
$ lxc config device add lxd-noble-fde iso-volume disk pool=default source=24.04-desktop boot.priority=10
$ lxc config device add lxd-noble-fde tpm tpm
$ lxc start --console=vga lxd-noble-fde

Go through the manual install process but at the "Disk Setup" step, select "Erase disk and install Ubuntu" and click "Advanced features...".
Select "Enable hardware-backed full disk encryption" then click "OK"

Once the installation is done, force the LXD VM to stop
$ lxc stop --force lxd-noble-fde

Remove the ISO
$ lxc config device remove lxd-noble-fde iso-volume

Start the VM back
$ lxc start lxd-noble-fde

Once logged in, rsyslog should eventually fail to start and the same Apparmor denials should show up in `journalctl -k`.

[James Paton-Smith (jamesps)]

I've just found that the cups.service is also experiencing the same behaviour. Again it has the service type 'notify'.

I suspect other services using this type will have the same problem.

[Andreas Hasenack (ahasenack)]

So far it's rsyslog, cups, and sssd (just confirmed via https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2064088).

[Sergio Durigan Junior (sergiodj)]

Andreas and I spent some time this afternoon investigating this issue. Here are our findings.

First, we noticed that the paths being reported by apparmor on dmesg appear to be relative to /run. This is just an impression, though: I believe that, for some reason, apparmor/systemd/something-else is actually seeing the paths as "/systemd/notify" instead of "/run/systemd/notify". Therefore, we decided to try to list those paths inside the apparmor profile, like:

  /systemd/journal/dev-log rwkl,
  /systemd/notify rwkl,

Note that we're using "rwkl" just because we don't want to deal with limiting the scope of each access.

After adding these paths to /etc/apparmor.d/usr.sbin.rsyslogd and reloading the profile, the service can finally be (re)started. This indicates that there's a discrepancy between the paths seeing by apparmor/systemd/Linux and those seeing by the userspace application.

With that in mind, our next idea was to try to use "systemd-run" to mimic what's happening with rsyslogd. This could help us determine which component is problematic, but unfortunately we were unable to make the failure happen. We tried many combinations of commands; some of them are listed below:

# Try to "ls" the notify socket using different paths
systemd-run -p AppArmorProfile=rsyslogd ls /run/systemd/notify
systemd-run -p AppArmorProfile=rsyslogd ls /systemd/notify

# Likewise, but running the command using the syslog user
systemd-run --uid 102 -p AppArmorProfile=rsyslogd ls /run/systemd/notify
systemd-run --uid 102 -p AppArmorProfile=rsyslogd ls /systemd/notify

Strangely, "ls" was able to properly list the contents of /run/systemd/notify on both cases (which it shouldn't, because the apparmor profile doesn't allow it). It also reported that "/systemd/notify", which is correct but unexpected (because we thought that systemd might be the problematic component which doesn't use "/run" in the paths). We also double checked and confirmed that the processes started by "systemd-run" have "systemd" as their parent, so in theory we should have seen the same problem here.

There is also the fact that these file accesses are being denied even when the apparmor profile is running in complain mode. AFAIU, this shouldn't happen. Unless apparmor is affecting the path resolution that happens when the service tries to connect to the socket, effectively mangling the final path... but that would be very weird, I believe.

Either way, it is unclear:

1) Why we're seeing these "partial" paths in the logs.

2) Why these accesses are being denied even when the apparmor profile is in complain mode.

3) Why "systemd-run" can't seem to reproduce the problem.

[James Paton-Smith (jamesps)]

Do you think we should mark #2064088 as a duplicate of this (or vice-versa), if we're confident this is the same underlying issue?

There are some outstanding questions for me on that bug, but it might make sense to focus our comments in one place going forward.

[Andreas Hasenack (ahasenack)]

I think neither rsyslog, nor cups, or sssd, are the correct packages for this bug, but I agree that spreading out the investigation over two different bugs is not good.

I'll mark https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2064088 as a duplicate, and add cups and sssd tasks to this one for tracking purposes, but I suspect the fix will be elsewhere in the end.

[Christian Ehrhardt  (paelzer)]

Thanks for the great debug work so far already, I think it is "apparmor or kernel" enough that we should add those packages and subscribe a few folks we know dealing with those details - I'd start with jjohansen as he'd be the best to map us to either knowledge or a known case.

[James Paton-Smith (jamesps)]

Answering questions from #2064088

Q: Did you install this fde/tpm setup using the ubuntu desktop noble installer? Or was hit some manual setup?
A: The install was performed using autoinstall with the desktop ISO. Attached is a copy of the autoinstall yaml

[James Paton-Smith (jamesps)]

Answering questions from #2064088

Q: Can you also show the output of: ps fauxwZ

A: See attached

[Andreas Hasenack (ahasenack)]

> /usr/lib/systemd/systemd --switched-root --system --deserialize=40 splash

Ok, --switched-root is there in PID 1, it's something I was looking to confirm.

[John Johansen (jjohansen)]

Does the profile have the attach_disconnected flag set?

Does the profile have the attach_disconnected flag set while in complain mode?

It looks to me that we are looking at open file descriptors that exist out of the current namespace. This will result in a partial unattached path that will not be allowed in complain mode. The denied path will not start with /.

If the attach_disconnected flag is add, that will attach the disconnected path to the root of the current mount namespace. Which is what I believe is happening with

  /systemd/...
vs
  /run/systemd/......".

Unless unconfined is involved, both the ends of a socket are required to exist in the namespace for v7/v8 unix socket mediation (what is in noble). Unconfined is special in that it can delegate access to an open fd which is not generically allowed atm.

If all the above is correct then you can use the attach_disconnected.path flag to attach the accesses to disconnected fds.

The full flags parameter to apparmor would then look like

  profile example flags=(attach_disonnected attach_disconnected.path=/run/) { ...)

and for complain mode

  profile example flags=(complain attach_disonnected attach_disconnected.path=/run/) { ...)

This of course is a less than satisfactory work around. There is work to address the above better but none of it is in noble.

[James Paton-Smith (jamesps)]

On my test VM I can see the cupsd profile DOES have 'attach_disconnected' flag, but not 'attach_disconnected.path=/run/'
If I add it and restart the cups.service, it starts successfully.

rsyslogd and sssd apparmor profiles do not have either these flags.

Could an apparmor abstraction work for this? i.e. if the system has 'boot-managed-by-snapd' package we could pull in an apparmor abstraction which adds these flags? Not sure what would be appropriate.

[John Johansen (jjohansen)]

Unfortunately there isn't a way to do this via abstractions or configs. It would be possible to add a patch to the userspace and SRU it. This would be the quickest solution while we work on the necessary kernel changes to make the use of attach_disconnected unnecessary.

[Gauthier Jolly (gjolly)]

To help with the investigations: I was able to reproduce the issue by simply installing dracut on a normal (non tpm-backed FDE) VM. Dracut replaces initramfs-tools and build a systemd-base initramfs.

# start the lxd VM
$ lxc launch --vm ubuntu:24.04 noble-vm

# in the VM install dracut and reboot
$ sudo apt update && sudo apt install -y dracut && sudo reboot

# check the logs after reboot
$ sudo journalctl -b0 | grep DENIED

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

We are seeing this issue with Ubuntu Core 24 too, for instance when running logger from a confined snap. The workaround of adding "attach_disonnected attach_disconnected.path=/run/" does work as well.

As an interesting data point, I have done some experiments and I see that using systemd 253.5-1ubuntu1 (an older version that was at some point in noble) with kernel 6.8 does not show the issue, while systemd 255.4-1ubuntu8 with kernel 6.8 triggers it. So some change in systemd triggers this.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

(note that the version of systemd in my comment refers to the version in the UC initramfs)

[Nick Rosbrook (enr0n)]

Yes, I found that systemd switched from using MS_MOVE to MS_BIND | MS_REC when moving /run (and other filesystems) during the switch root. Although this is ultimately a shortcoming in AppArmor, this change in systemd is why we are seeing the issue now.

Discussing with upstream in https://github.com/systemd/systemd/pull/32645.

[Łukasz Zemczak (sil2100)]

Hello James, or anyone else affected,

Accepted systemd into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/255.4-1ubuntu8.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[James Paton-Smith (jamesps)]

Hi Łukasz,

Here is the testing I have performed.

- Enabled noble-proposed
- Installed latest systemd from noble-proposed (255.4-1ubuntu8.1)
- removed all systemd drop-in files for cups
- Rebooted the device

After rebooting I monitored the cups.service but it still is failing to start.
I can see the following in the systemd journal:
```
May 22 14:43:15 ubu-n-b5c04f594433 kernel: audit: type=1400 audit(1716385395.378:290): apparmor="DENIED" operation="sendmsg" class="file" profile="/usr/sbin/cupsd" name="/systemd/notify" pid=10265 comm="cupsd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
```

[Nick Rosbrook (enr0n)]

@jamesps the affected systemd is the one runnning in the initrd. For desktop running TPM FDE, this will require having the pc-kernel(?) snap updated.

[Nick Rosbrook (enr0n)]

I have verified the fix according to the test plan above, using 255.4-1ubuntu8.1 from noble-proposed. Note, as I mentioned in an earlier comment, this fix is NOT available on Desktop with TPM FDE until the appropriate snap is rebuilt.

I have previously prepared a noble VM, and installed dracut for generating the initrd, which means running systemd in the initrd. Currently, I can see the AppArmor denials for rsyslog:

ubuntu@ubuntu:~$ sudo dmesg | grep rsyslog
[ 2.816998] systemd[1]: unit_file_build_name_map: normal unit file: /usr/lib/systemd/system/rsyslog.service
[ 5.588869] audit: type=1400 audit(1716388183.334:149): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="rsyslogd" pid=993 comm="apparmor_parser"
[ 5.676353] audit: type=1400 audit(1716388183.422:150): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="systemd/notify" pid=1055 comm="rsyslogd" requested_mask="w" denied_mask="w" fsuid=102 ouid=0
[ 5.676388] audit: type=1400 audit(1716388183.422:151): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="systemd/journal/dev-log" pid=1055 comm="rsyslogd" requested_mask="w" denied_mask="w" fsuid=102 ouid=0
[ 5.676407] audit: type=1400 audit(1716388183.422:152): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="systemd/journal/dev-log" pid=1055 comm="rsyslogd" requested_mask="w" denied_mask="w" fsuid=102 ouid=0
[ 5.676425] audit: type=1400 audit(1716388183.422:153): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="systemd/journal/dev-log" pid=1055 comm="rsyslogd" requested_mask="w" denied_mask="w" fsuid=102 ouid=0
[ 5.676440] audit: type=1400 audit(1716388183.422:154): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="systemd/journal/dev-log" pid=1055 comm="rsyslogd" requested_mask="w" denied_mask="w" fsuid=102 ouid=0
[ 95.610731] audit: type=1400 audit(1716388273.356:166): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="systemd/journal/dev-log" pid=1055 comm="rsyslogd" requested_mask="w" denied_mask="w" fsuid=102 ouid=0
[ 95.974029] audit: type=1400 audit(1716388273.719:167): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="rsyslogd" pid=2072 comm="apparmor_parser"
[ 96.010658] audit: type=1400 audit(1716388273.756:168): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="systemd/notify" pid=2073 comm="rsyslogd" requested_mask="w" denied_mask="w" fsuid=102 ouid=0
[ 96.010664] audit: type=1400 audit(1716388273.756:169): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=...

[Ubuntu SRU Bot (ubuntu-sru-bot)]

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

[James Paton-Smith (jamesps)]

I've finally had time to test this on a non TPM-FDE machine and can confirm that services like cups are now working after installing the systemd version from noble-proposed.

Testing:
- Install clean Ubuntu 24.04 (no TPM-FDE)
- Install dracut & reboot
- Check cups status (failing to start)
- Install systemd 255.4-1ubuntu8.1 from noble-proposed
- Run 'dracut --regenerate-all --force
- Reboot

After doing this, services like cups and rsyslog now are starting without issue.

[Gabriel de Perthuis (g2p)]

This also affects unbound: the name resolution service didn't start (it was possible to start unbound outside of service management, because it doesn't look for /run/systemd/notify in that case). I do use dracut.

Upgrading systemd and related packages to 255.4-1ubuntu8.1 (upgrading udev regenerates the initramfs) fixes it.

Before that, errors looked like:
journalctl -k -b-1 --grep 'apparmor.*unbound'
mai 27 10:02:22 host kernel: audit: type=1400 audit(1716796942.487:146): apparmor="DENIED" operation="sendmsg" class="file" profile="unbound" name="/systemd/journal/dev-log" pid=1175 comm="unbound" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
mai 27 10:02:22 host kernel: audit: type=1400 audit(1716796942.487:147): apparmor="DENIED" operation="connect" class="file" profile="unbound" name="/systemd/userdb/io.systemd.DynamicUser" pid=1175 comm="unbound" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
mai 27 10:02:22 host kernel: audit: type=1400 audit(1716796942.542:153): apparmor="DENIED" operation="sendmsg" class="file" profile="unbound" name="/systemd/notify" pid=1175 comm="unbound" requested_mask="w" denied_mask="w" fsuid=126 ouid=0

[Nick Rosbrook (enr0n)]

The autopkgtest regressions were all resolved with retries.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 255.4-1ubuntu8.1

---------------
systemd (255.4-1ubuntu8.1) noble; urgency=medium

  * debian/systemd-resolved.postinst: ignore cp failure (LP: #2047975)
  * debian/systemd.postinst: don't restart user managers if too old (LP: #2054761)
  * switch-root: use MS_MOVE for /run when switchig from initrd (LP: #2064096)
  * test: check for kernel.apparmor_restrict_unprivileged_userns (LP: #2065964)

 -- Nick Rosbrook <email address hidden> Fri, 17 May 2024 10:47:34 +0200

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.