-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade systemd from 255 to 256 #2145
base: main
Are you sure you want to change the base?
Conversation
@@ -254,14 +254,11 @@ src_prepare() { | |||
"${FILESDIR}/systemd-test-process-util.patch" | |||
# Flatcar: Adding our own patches here. | |||
"${FILESDIR}/0001-wait-online-set-any-by-default.patch" | |||
"${FILESDIR}/0002-networkd-default-to-kernel-IPForwarding-setting.patch" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be investigated if the 256 changes are making this patch irelevant or not: https://github.com/systemd/systemd-stable/blob/v256/src/network/networkd-network.c#L470
The github actions fail with vm being emergency shelled at boot with the error: |
After some investigation, it seems that From https://lists.freedesktop.org/archives/systemd-devel/2024-June/050407.html:
dracut-ng/dracut-ng@a45048b80c27ee5a45a380 -> this commit shows how to fix dracut 100, not applicable, as dracut used by Flatcar is an older version 0.53. But |
One option, is, obviously, to disable the default ProtectSystem, as the initrd Flatcar workflow is reliant on writing to rootfs, similar to this, in bootengine, using a dracut module definition, similar to: https://github.com/flatcar/bootengine/blob/flatcar-master/dracut/99switch-root/nocgroup.conf Another would be to fix all the bootengine /usr writes and maybe move those to /etc or /var. |
9d88f29
to
a3f885c
Compare
Last time I tried a few months ago, I also got the same cyclical dependencies and gave up. Our bootengine heavily modifies the dracut upstream logic, so things need to be modified (again) there to make the dracut upgrade. |
Full error for the initrd break point:
|
To overcome the current limitation imposed by systemd 256 regarding the
I am not convinced these two ideas are the best, maybe there is another option? Thanks. |
With the Until dracut is updated, we need to revert this commit manually in systemd: systemd/systemd@1c585a4 |
Updating Dracut has proven tricky, mainly due to size issues, so I wouldn't wait for that. |
yeap, will add the patch to systemd ebuild. |
AMD64 Flatcar running with systemd 256 and linux 6.10:
|
a3f885c
to
af427b9
Compare
The github actions failed because of the Mantle tests using cgroupv1. See https://github.com/systemd/systemd/releases/tag/v256-rc3 -> systemd will refuse to boot in normal circumstances.
|
We should add code to our update postinstall hook to detect if the user is still on cgroups v1 and abort the update.
…________________________________
From: Adrian Vladu ***@***.***>
Sent: Thursday, September 26, 2024 3:39:36 AM
To: flatcar/scripts ***@***.***>
Cc: Jeremi Piotrowski ***@***.***>; Review requested ***@***.***>
Subject: Re: [flatcar/scripts] Upgrade systemd from 255 to 256 (PR #2145)
The github actions failed because of the Mantle tests using cgroupv1. See https://github.com/systemd/systemd/releases/tag/v256-rc3 -> systemd will refuse to boot in normal circumstances.
Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is now
considered obsolete and systemd by default will refuse to boot under
it. To forcibly reenable cgroup v1 support,
SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must be set on kernel command
line. The meson option 'default-hierarchy=' is also deprecated, i.e.
only cgroup v2 ('unified' hierarchy) can be selected as build-time
default.
—
Reply to this email directly, view it on GitHub<#2145 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABXINVQUZN6IBMQMAL3GTWLZYPP6RAVCNFSM6AAAAABLKHBRBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZWGU4DGMZWHA>.
You are receiving this because your review was requested.Message ID: ***@***.***>
|
Or is it worth still letting users stay with cgroups v1 if they set this flag? we would still want to validate before commiting the update.
…________________________________
From: Jeremi Piotrowski ***@***.***>
Sent: Thursday, September 26, 2024 8:15:27 PM
To: flatcar/scripts ***@***.***>; flatcar/scripts ***@***.***>
Cc: Review requested ***@***.***>
Subject: Re: [flatcar/scripts] Upgrade systemd from 255 to 256 (PR #2145)
We should add code to our update postinstall hook to detect if the user is still on cgroups v1 and abort the update.
________________________________
From: Adrian Vladu ***@***.***>
Sent: Thursday, September 26, 2024 3:39:36 AM
To: flatcar/scripts ***@***.***>
Cc: Jeremi Piotrowski ***@***.***>; Review requested ***@***.***>
Subject: Re: [flatcar/scripts] Upgrade systemd from 255 to 256 (PR #2145)
The github actions failed because of the Mantle tests using cgroupv1. See https://github.com/systemd/systemd/releases/tag/v256-rc3 -> systemd will refuse to boot in normal circumstances.
Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is now
considered obsolete and systemd by default will refuse to boot under
it. To forcibly reenable cgroup v1 support,
SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must be set on kernel command
line. The meson option 'default-hierarchy=' is also deprecated, i.e.
only cgroup v2 ('unified' hierarchy) can be selected as build-time
default.
—
Reply to this email directly, view it on GitHub<#2145 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABXINVQUZN6IBMQMAL3GTWLZYPP6RAVCNFSM6AAAAABLKHBRBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZWGU4DGMZWHA>.
You are receiving this because your review was requested.Message ID: ***@***.***>
|
Hello @jepio, indeed, we have just a few paths forward:
Thanks. |
I am for 1, deprecate cgroup v1 and document as much as possible. |
I agree with Dongsu to take the 1 approach, and add to the notes section in the Release notes section, and into documentation. |
During the office hours there was an idea of adding the kernel parameter to the nodes that were still using cgroupv1. This probably would be a smooth way of updating Flatcar to a version with systemd 256. Of course, with cgroupv1 being on chopping block, we would need to define how long we are going to support cgroupv1. My proposal would be to spin up new LTS version (which is due anyway) and announce that support for cgroupv1 in Flatcar will bound to the lifetime of the new LTS. For other channels we could say support will be until end of this year or something. For people still needing cgroupv1 after that, we could point them to use LTS, so they'll have a bit more time to move off to cgroupv2 (like until mid-2026, I think). |
Thank you @krnowak . Summing things up:
|
af427b9
to
bf245d2
Compare
bf245d2
to
feb5d5f
Compare
feb5d5f
to
5bac742
Compare
…ork with systemd >= v256 See: flatcar/scripts#2145
Patches required on other subprojects:
Would be great to receive some feedback on those too, thanks! |
b779d39
to
bc6a2a8
Compare
…ork with systemd >= v256 See: flatcar/scripts#2145
Mantle tests cannot be fixed via ignition setting of the Linux kernel cmdline param SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1, as ignition starts after systemd (of course). So, the cgroup v1 mantle tests can only be done by changing the image before booting (hard) or using a specialized image (no go). At this moment, I recomend to just skip those cgroup v1 mantle tests on version higher than this one. |
It's from Gentoo commit 473b0997ba121fcc629f94a480238f8e664f900d
Signed-off-by: Adrian Vladu <[email protected]>
bc6a2a8
to
4aa515f
Compare
Upgrade systemd from 255 to 256
Fixes: flatcar/Flatcar#1501
Testing done
[Describe the testing you have done before submitting this PR. Please include both the commands you issued as well as the output you got.]
changelog/
directory (user-facing change, bug fix, security fix, update)/boot
and/usr
size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.Patches required on other subprojects: