[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. - [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. + [backported patch] + + the backported patch adds support to mount cgroup2 (new way) in addition + to the old way (cgroup + __DEVEL_ option) and also adds a fallback to do + that when mounting cgroups1 fails (because host is already using non- + hybrid v2 cgroups). This way the default behaviour remains the same, + apart from when trying to boot xenial on latest kernels and userspace + that opts into using cgroups2-only. + [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [backported patch] the backported patch adds support to mount cgroup2 (new way) in
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
** Tags added: fr-2124 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
It's the SRU team's purview to make exceptions here. The rationale that this only benefits images is and therefore needs to be in the main archive is sound. So for the SRU team, I'm +1 on going ahead with this. But someone still needs to prepare the SRU, which I think falls to Foundations. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
I feel like this special case should be decided and handled by the release team, not Foundations. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
Just for clarification, and doc, this approach was took as since it needs to go the archive, it need to be handled as an SRU bye the SRU team. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
I see, I do agree, sorry for noise. I did remove the one from -esm ppas and here is the debdiff. Could someone please sponsor/follow with it? Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
** Patch added: "systemd_229-4ubuntu22.32.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+attachment/5569222/+files/systemd_229-4ubuntu22.32.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
+1 to Dan Having it in ESM is not really helpful (esp. not for package tests). If it's patched in the regular archives (xenial-updates), I am happy to re-try and test. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
> I have update ongoing on esm-infa-staging for it just to clarify, if the systemd patch isn't added to the actual main (currently closed) xenial-updates repo, it won't be very much help to anyone wanting to create new xenial containers on jammy. So, just patching systemd in the esm repo likely is not enough - especially if the prebuilt LXD container images don't pick up the ESM version of systemd. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
I have update ongoing on esm-infa-staging for it, but without consider these issues Dimitri pointed, so, with the clean patch pointed here. It would be nice if any of you folks could give a test on it. Also adding other folks from security to this discussion with better background. Also, tips on how to test it would be nice. I was trying lxc image export with a systemd updated and a non systemd update xenial, but hadn't any luck as both work as the same if you lxc import into a jammy from .tar.gz image exported. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
Backporting 099619957a0 to xenial will mean that systemd will gain ability to use cgroups2 as shipped in the xenial's ga v4.4 kernel. it will mean that xenial containers on top of bionic's ga kernel will fail to use cgroups2. however at the time it was an experimental feature which was not widely used at all, and there are likely to be very few users of it. it would be nice to if backport of 099619957a0 was done in a backwards- compatible way and allow using cgroups2 like code paths using both pre-v4.4 and v4.4+ kernels. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. + + [workaround] + On Jammy host edit default kernel command line to include + + systemd.unified_cgroup_hierarchy=false + + update your bootloader configuration; and reboot + + then hybrid cgroups will be on the host, and one can launch xenial + container then. + [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
hm, $ lxc launch --vm ubuntu:xenial fails for me ** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. - - [workaround] - - Instead of: - $ lxc launch ubuntu:xenial - - use: - $ lxc launch --vm ubuntu:xenial - - Until this is fixed. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. + + [workaround] + + Instead of: + $ lxc launch ubuntu:xenial + + use: + $ lxc launch --vm ubuntu:xenial + + Until this is fixed. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] Instead of: $ lxc launch ubuntu:xenial use: $ lxc launch --vm ubuntu:xenial Until this is fixed. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
Irrespective of ESM status, we have always had extremely long support overlaps both backwards and forwards between ubuntu releases. At the moment, my only solution is to use lxd vms; i.e. do $ lxc launch --vm ubuntu:xenial However, I say for the sake of ease of development, testing, upgrades, migration, and bug hunting we should support xenial lxd on jammy, irrespective of xenial's status, especially since trusty lxd on jammy still works. ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] Instead of: $ lxc launch ubuntu:xenial use: $ lxc launch --vm ubuntu:xenial Until this is fixed. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
> "so this is fixed already in f and later" - think you mean "b and later" here? yes sorry, fixed in b and later ** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, - so this is fixed already in f and later. + so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
(not reassigning because I'm not sure of a public team that can be used for ESM bug assignments, but I've contacted the engineering team internally.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
NB this has been assigned to Canonical Foundations, but as Ubuntu 16.04 is in Extended Security Maintenance now, this is actually a decision for our ESM Team to make regarding the path forward on whether xenial containers will be supported on jammy hosts, and if so, to update systemd for it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
"so this is fixed already in f and later" - think you mean "b and later" here? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
This bug is a consequence of LP#1962286. ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Tags added: rls-jj-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu Xenial) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
