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)
*
The autopkgtest regressions were all resolved with retries.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064096
Title:
Services fail to start in noble deployed with TPM+FDE
To manage
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
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)
-
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
@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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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
** Changed in: systemd (Ubuntu Noble)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064096
Title:
Services fail to start in noble deployed with TPM+FDE
To manage
** Description changed:
[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
** Description changed:
+ [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
** Also affects: apparmor (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: rsyslog (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: cups (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: sssd (Ubuntu Noble)
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
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
(note that the version of systemd in my comment refers to the version in
the UC initramfs)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064096
Title:
Services fail to start in noble deployed with
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Nick Rosbrook (enr0n)
--
You received this bug notification because you are a member of Ubuntu
Bugs,
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
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.
--
You received this bug
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
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
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064096
Title:
Services fail to start in noble deployed with TPM+FDE
To
> /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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
** Attachment added: "autoinstall
Answering questions from #2064088
Q: Can you also show the output of: ps fauxwZ
A: See attached
** Attachment added: "ps"
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2064096/+attachment/5774011/+files/ps
--
You received this bug notification because you are a member of Ubuntu
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.
** Also affects:
** Description changed:
+ 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
+ - only after running
26 matches
Mail list logo