| 2022-02-25 16:27:15 |
Dan Streetman |
bug |
|
|
added bug |
| 2022-02-25 16:27:22 |
Dan Streetman |
nominated for series |
|
Ubuntu Xenial |
|
| 2022-02-25 16:27:22 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Xenial) |
|
| 2022-02-25 16:27:28 |
Dan Streetman |
systemd (Ubuntu): status |
New |
Fix Released |
|
| 2022-02-28 17:45:20 |
Launchpad Janitor |
systemd (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2022-02-28 18:00:00 |
Frank Heimes |
systemd (Ubuntu Xenial): assignee |
|
Canonical Foundations Team (canonical-foundations) |
|
| 2022-02-28 18:00:10 |
Frank Heimes |
tags |
|
rls-jj-incoming |
|
| 2022-02-28 23:20:24 |
Dan Streetman |
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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
[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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
|
| 2022-03-01 19:49:05 |
Nicolas Bock |
bug |
|
|
added subscriber Nicolas Bock |
| 2022-03-01 20:05:40 |
Jay Vosburgh |
bug |
|
|
added subscriber Jay Vosburgh |
| 2022-03-01 23:22:53 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2022-03-04 13:03:20 |
Dimitri John Ledkov |
systemd (Ubuntu Xenial): importance |
Undecided |
Critical |
|
| 2022-03-04 13:09:45 |
Dimitri John Ledkov |
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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
[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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
|
| 2022-03-04 13:22:20 |
Dimitri John Ledkov |
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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
[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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
|
| 2022-03-04 17:21:16 |
Frank Heimes |
bug |
|
|
added subscriber Frank Heimes |
| 2022-03-07 16:17:49 |
Dimitri John Ledkov |
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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
[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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
|
| 2022-03-15 11:34:43 |
Leonidas S. Barbosa |
attachment added |
|
systemd_229-4ubuntu22.32.debdiff https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+attachment/5569222/+files/systemd_229-4ubuntu22.32.debdiff |
|
| 2022-03-18 17:01:32 |
Frank Heimes |
bug |
|
|
added subscriber Ubuntu Release Team |
| 2022-03-22 18:13:38 |
Lukas Märdian |
tags |
rls-jj-incoming |
fr-2124 rls-jj-incoming |
|
| 2022-05-06 11:11:54 |
Dimitri John Ledkov |
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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
[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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
|
| 2022-05-10 12:17:16 |
Dimitri John Ledkov |
summary |
xenial systemd fails to start if cgroup2 is mounted |
xenial systemd fails to start if unified-only (non-hybrid) cgroup2 is mounted on jammy hosts |
|
| 2022-05-10 12:19:50 |
Dimitri John Ledkov |
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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. |
[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 <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit
(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+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. However that patch alone is insufficient, does not implement hybrid group setup, and breaks a lot of xenial userspace expectations.
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. |
|
| 2022-06-13 03:55:10 |
Matthew Ruffell |
bug |
|
|
added subscriber Matthew Ruffell |
