[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-06-04 Thread Launchpad Bug Tracker
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) *

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-28 Thread Nick Rosbrook
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-27 Thread Gabriel de Perthuis
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-24 Thread James Paton-Smith
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) -

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-22 Thread Nick Rosbrook
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-22 Thread Nick Rosbrook
@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.

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-22 Thread James Paton-Smith
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-22 Thread Łukasz Zemczak
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-17 Thread Nick Rosbrook
** 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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-17 Thread Nick Rosbrook
** 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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-17 Thread Nick Rosbrook
** 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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-17 Thread Nick Rosbrook
** 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)

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-06 Thread Nick Rosbrook
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-06 Thread Alfonso Sanchez-Beato
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-06 Thread Alfonso Sanchez-Beato
(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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-03 Thread Nick Rosbrook
** 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,

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-03 Thread Gauthier Jolly
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-03 Thread John Johansen
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-03 Thread James Paton-Smith
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-03 Thread John Johansen
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-02 Thread Nick Rosbrook
** 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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-02 Thread Andreas Hasenack
> /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.

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-02 Thread James Paton-Smith
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-02 Thread James Paton-Smith
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

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-01 Thread Christian Ehrhardt 
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:

[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

2024-05-01 Thread Andreas Hasenack
** 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