Upgrade systemd from 255 to 256 #2145

ader1990 · 2024-07-23T11:26:27Z

Upgrade systemd from 255 to 256

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 entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

Patches required on other subprojects:

ader1990 · 2024-07-23T11:29:16Z

sdk_container/src/third_party/coreos-overlay/sys-apps/systemd/systemd-256.2.ebuild

@@ -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"


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

ader1990 · 2024-07-23T15:30:14Z

The github actions fail with vm being emergency shelled at boot with the error: systemd: system is tainted: unmerged bin, needs investigation.

github-actions · 2024-07-23T15:30:25Z

Build action triggered: https://github.com/flatcar/scripts/actions/runs/12409046532

ader1990 · 2024-07-24T09:53:04Z

After some investigation, it seems that ignition-setup.service fails to run because /usr is now read only.

From https://lists.freedesktop.org/archives/systemd-devel/2024-June/050407.html:

        Service Management:

        * New system manager setting ProtectSystem= has been added. It is
          analogous to the unit setting, but applies to the whole system. It is
          enabled by default in the initrd.

          Note that this means that code executed in the initrd cannot naively
          expect to be able to write to /usr/ during boot. This affects
          dracut <= 101, which wrote "hooks" to /lib/dracut/hooks/. See
          https://github.com/dracut-ng/dracut-ng/commit/a45048b80c27ee5a45a380.

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 ignition-setup.service fails to run at this line, as /usr is mount as ro: https://github.com/flatcar/bootengine/blob/flatcar-master/dracut/30ignition/ignition-setup.sh#L15.

ader1990 · 2024-07-24T10:03:00Z

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.

chewi · 2024-08-13T14:21:56Z

Independently of this, I have tried to update Dracut to 060, and am having trouble with cyclic boot dependencies. I wonder if this is somehow related to the above. Here's what it looks like with the verity stuff disabled, otherwise it's a bit more complicated.

ader1990 · 2024-08-13T14:32:03Z

Independently of this, I have tried to update Dracut to 060, and am having trouble with cyclic boot dependencies. I wonder if this is somehow related to the above. Here's what it looks like with the verity stuff disabled, otherwise it's a bit more complicated.

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.

ader1990 · 2024-09-25T08:22:16Z

Full error for the initrd break point:

journalctl -xeu ignition-setup.service

Sep 25 08:17:15 localhost systemd[1]: Starting ignition-setup.service - Ignition (setup)...
Sep 25 08:17:15 localhost ignition-setup[891]: cp: cannot create regular file '/bin/is-live-image': Read-only file system
Sep 25 08:17:15 localhost systemd[1]: ignition-setup.service: Main process exited, code=exited, status=1/FAILURE
Sep 25 08:17:15 localhost systemd[1]: ignition-setup.service: Failed with result 'exit-code'.
Sep 25 08:17:15 localhost systemd[1]: Failed to start ignition-setup.service - Ignition (setup).
Sep 25 08:17:15 localhost systemd[1]: ignition-setup.service: Triggering OnFailure= dependencies.

ader1990 · 2024-09-25T08:35:40Z

To overcome the current limitation imposed by systemd 256 regarding the ignition-setup[891]: cp: cannot create regular file '/bin/is-live-image': Read-only file system, there are two options I can think of:

use /mnt/oem or even /tmp as a temporary place to store the is-live-image but this needs a $PATH change so that it can be found by Ignition -> https://github.com/search?q=repo%3Acoreos%2Fignition%20is-live-image&type=code
Temporarily remount the /usr as mount -o remount,rw /usr, do the required change and then mount -o remount,ro /usr

I am not convinced these two ideas are the best, maybe there is another option?

Thanks.

ader1990 · 2024-09-25T15:43:28Z

With the is-live-image issue fixed, systemd 256 expects dracut 058 -> see systemd/systemd@1c585a4

Until dracut is updated, we need to revert this commit manually in systemd: systemd/systemd@1c585a4

chewi · 2024-09-25T15:50:34Z

Updating Dracut has proven tricky, mainly due to size issues, so I wouldn't wait for that.

ader1990 · 2024-09-25T15:57:34Z

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.

ader1990 · 2024-09-26T07:30:42Z

AMD64 Flatcar running with systemd 256 and linux 6.10:

root@localhost ~ # cat /etc/os-release

NAME="Flatcar Container Linux by Kinvolk"
ID=flatcar
ID_LIKE=coreos
VERSION=4102.0.0+nightly-20240923-2100-26-g730775213c
VERSION_ID=4102.0.0
BUILD_ID=nightly-20240923-2100-26-g730775213c
SYSEXT_LEVEL=1.0
PRETTY_NAME="Flatcar Container Linux by Kinvolk 4102.0.0+nightly-20240923-2100-26-g730775213c (Oklo)"
ANSI_COLOR="38;5;75"
HOME_URL="https://flatcar.org/"
BUG_REPORT_URL="https://issues.flatcar.org"
FLATCAR_BOARD="amd64-usr"
CPE_NAME="cpe:2.3:o:flatcar-linux:flatcar_linux:4102.0.0+nightly-20240923-2100-26-g730775213c:*:*:*:*:*:*:*"

root@localhost ~ # uname -a
Linux localhost 6.10.9-flatcar #1 SMP PREEMPT_DYNAMIC Thu Sep 26 06:21:38 -00 2024 x86_64 Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz GenuineIntel GNU/Linux

root@localhost ~ # systemctl --version
systemd 256 (256.2)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL -ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP -SYSVINIT +LIBARCHIVE

root@localhost ~ # df /boot
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/vda1         129039 62922     66118  49% /boot

ader1990 · 2024-09-26T10:39:13Z

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.

jepio · 2024-09-27T03:15:43Z

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: ***@***.***>

jepio · 2024-09-27T03:17:10Z

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: ***@***.***>

ader1990 · 2024-09-30T08:30:04Z

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 unsubscribehttps://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:

follow systemd approach no questions asked related to the cgroupv1 and block the Flatcar upgrade in the postinstall hook.
Document the transition and disseminate the information on all possible channels about it.
Document the usage of SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 with ignition / manual update for the new/old instances.
set SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 on all images (not the best), this flag might be also removed in subsequent versions
patch systemd to remove the check (even less)
block the systemd upgrade until another option appears. Meanwhile, announce this future upgrade path and wait for more feedback from the community.

Thanks.

dongsupark · 2024-09-30T11:11:02Z

we have just a few paths forward:

1. follow systemd approach no questions asked related to the cgroupv1 and block the Flatcar upgrade in the postinstall hook.
   Document the transition and disseminate the information on all possible channels about it.
   Document the usage of SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 with ignition / manual update for the new/old instances.

2. set SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 on all images (not the best), this flat might be also removed in subsequent versions

3. patch systemd to remove the check (even less)

4. block the systemd upgrade until another option appears. Meanwhile, announce this future upgrade path and wait for more feedback from the community.

I am for 1, deprecate cgroup v1 and document as much as possible.
Other options look like nothing more than delaying issues.
Even if we go for 1, users still have workaround to revert the behavior.

sayanchowdhury · 2024-10-09T10:13:45Z

follow systemd approach no questions asked related to the cgroupv1 and block the Flatcar upgrade in the postinstall hook.

I agree with Dongsu to take the 1 approach, and add to the notes section in the Release notes section, and into documentation.

Cutout version: > 4816 See: https://github.com/systemd/systemd/releases/tag/v256-rc3 See: flatcar/scripts#2145

It's from Gentoo commit 473b0997ba121fcc629f94a480238f8e664f900d

Signed-off-by: Adrian Vladu <[email protected]>

…4e7ed8be80

tormath1 · 2024-12-17T13:24:38Z

sdk_container/src/third_party/coreos-overlay/sys-apps/systemd/Manifest

I think we can update this to pull the latest version of upstream Gentoo and we need to be sure that it's a regular copy (i.e no modification).

it is already to the latest gentoo upstream and checked.

Ok, I asked because I see this commit here: gentoo/gentoo@44519e4 that brings 256.9 (what we do in the next commit: "apply flatcar modification")

tormath1 · 2024-12-17T13:29:09Z

sdk_container/src/third_party/coreos-overlay/sys-apps/systemd/systemd-256.9.ebuild

While at here, can you drop the following Flatcar modification:

+ # Flatcar: Drop sec-policy/selinux-ntp from deps (under selinux use + # flag). The image stage fails with "Failed to resolve + # typeattributeset statement at + # /var/lib/selinux/mcs/tmp/modules/400/ntp/cil:120" selinux? ( sec-policy/selinux-base-policy[systemd] - sec-policy/selinux-ntp

and add selinux-ntp to the selinux policies:

Add the package to ::portage-stable

Add the package to .github/workflows/portage-stable-packages-list

Add the package to sdk_container/src/third_party/coreos-overlay/coreos-base/coreos/coreos-0.0.1-r316.ebuild

This will help in the SELinux effort.

I can do it after this change in another patch, as it is already complicated to properly test as is.

tormath1 · 2024-12-17T13:31:34Z

sdk_container/src/third_party/coreos-overlay/sys-apps/systemd/systemd-256.9.ebuild

+	# the filesystem is already read-write.  Conveniently the
+	# systemd Makefile sets this up completely wrong.
+	#
+	# Flatcar: TODO: Is this still a problem?


I see quite a few TODO here. Can we open a tracking issue and track those TODO? These can be done on the side but they will be forgot if it's not tracked somewhere.

sdk_container/src/third_party/coreos-overlay/sys-apps/systemd/systemd-256.9.ebuild

Use flatcar/bootengine#101, that fixes systemd 256 Ignition quirk. See: coreos/fedora-coreos-config@44d0ff8

…setting.patch According to https://github.com/systemd/systemd-stable/blob/v256/src/network/networkd-network.c#L470, the forwarding settings have changed on systemd 256. From the discussions upstream, if a systemd is configured to manage an interface, it will manage it completely, and it will set that interface to not forward packets by default. From the current systemd code, it would be easy to either enable the forwarding or disable it, but there does not seem to be a way now to inherit it from the sysctl / kernel implementation.

ader1990 · 2024-12-18T09:30:50Z

This PR is ready to be merged as-is, with the following to do items:

Suggested by @tormath1: handle the selinux-ntp in another PR (the functionality is unrelated to this PR, the issue to be solved is an historical one)

flatcar/update_engine#41 -> needs to be merged during the same release window - MERGED

Investigation needed for 0002-networkd-default-to-kernel-IPForwarding-setting.patch - this patch is not appliable anymore and has been dropped because of that. My local checks are good and the CI passes - the IP forwarding works without a similar patch, but more careful investigation is required to see if there are real-world usecase affected

sayanchowdhury · 2024-12-18T14:04:57Z

CI http://localhost:8080/job/container/job/sdk/1883/

...ner/src/third_party/coreos-overlay/coreos-base/update_engine/update_engine-0.4.10-r24.ebuild

See: flatcar/update_engine#41

tormath1 · 2024-12-19T08:33:10Z

CI http://localhost:8080/job/container/job/sdk/1883/

@sayanchowdhury can you restart a CI please? I'd like to see the update test passing (as the update-engine commit was missing in this run)

ader1990 had a problem deploying to development July 23, 2024 11:26 — with GitHub Actions Error

ader1990 temporarily deployed to development July 23, 2024 11:27 — with GitHub Actions Inactive

ader1990 commented Jul 23, 2024

View reviewed changes

ader1990 force-pushed the ader1990/systemd-major-version-upgrade-256 branch from 9d88f29 to a3f885c Compare July 25, 2024 07:43

ader1990 temporarily deployed to development July 25, 2024 07:43 — with GitHub Actions Inactive

github-actions bot mentioned this pull request Aug 22, 2024

Monthly contributions report 2024-07-22 - 2024-08-21 flatcar/Flatcar#1519

Closed

ader1990 self-assigned this Sep 25, 2024

ader1990 requested a review from a team September 25, 2024 08:36

ader1990 force-pushed the ader1990/systemd-major-version-upgrade-256 branch from a3f885c to af427b9 Compare September 26, 2024 07:33

ader1990 temporarily deployed to development September 26, 2024 07:33 — with GitHub Actions Inactive

ader1990 marked this pull request as ready for review September 26, 2024 07:34

dongsupark added the main label Sep 26, 2024

ader1990 mentioned this pull request Dec 2, 2024

cgroupv1: do not run tests for version >= 4179 flatcar/mantle#569

Merged

ader1990 force-pushed the ader1990/systemd-major-version-upgrade-256 branch from 4aa515f to 1514993 Compare December 2, 2024 12:43

ader1990 temporarily deployed to development December 2, 2024 12:43 — with GitHub Actions Inactive

ader1990 added a commit to flatcar/update_engine that referenced this pull request Dec 17, 2024

cgroupv1: abort the update if Flatcar version does not support it

1ad22ef

Cutout version: > 4816 See: https://github.com/systemd/systemd/releases/tag/v256-rc3 See: flatcar/scripts#2145

ader1990 and others added 4 commits December 17, 2024 09:38

sys-apps/systemd: Sync with Gentoo

ca868e8

It's from Gentoo commit 473b0997ba121fcc629f94a480238f8e664f900d

overlay sys-apps/systemd: Apply Flatcar modifications

3279f8c

Signed-off-by: Adrian Vladu <[email protected]>

sys-apps/systemd: remove unncessary patches

4b4182d

sys-apps/systemd: revert systemd patch 1c585a4ccda3258088d7bc27b27a31…

97ad543

…4e7ed8be80

ader1990 force-pushed the ader1990/systemd-major-version-upgrade-256 branch from 1514993 to 120668a Compare December 17, 2024 09:55

ader1990 temporarily deployed to development December 17, 2024 09:55 — with GitHub Actions Inactive

tormath1 reviewed Dec 17, 2024

View reviewed changes

sdk_container/src/third_party/coreos-overlay/sys-apps/systemd/systemd-256.9.ebuild Show resolved Hide resolved

ader1990 added 2 commits December 17, 2024 14:43

bootengine: use latest upstream

b2fd2c6

Use flatcar/bootengine#101, that fixes systemd 256 Ignition quirk. See: coreos/fedora-coreos-config@44d0ff8

ader1990 force-pushed the ader1990/systemd-major-version-upgrade-256 branch from 120668a to e8996b1 Compare December 17, 2024 14:57

ader1990 temporarily deployed to development December 17, 2024 14:57 — with GitHub Actions Inactive

ader1990 requested a review from a team December 18, 2024 09:22

sys-apps/systemd: add changelog 255.8 -> 256.9

6ee1d50

ader1990 had a problem deploying to development December 18, 2024 09:34 — with GitHub Actions Error

ader1990 temporarily deployed to development December 18, 2024 10:07 — with GitHub Actions Inactive

tormath1 reviewed Dec 18, 2024

View reviewed changes

...ner/src/third_party/coreos-overlay/coreos-base/update_engine/update_engine-0.4.10-r24.ebuild Outdated Show resolved Hide resolved

coreos-base/update_engine: fail upgrade if cgroupv1 is enabled

089df88

See: flatcar/update_engine#41

ader1990 force-pushed the ader1990/systemd-major-version-upgrade-256 branch from 93e3768 to 089df88 Compare December 18, 2024 21:17

ader1990 temporarily deployed to development December 18, 2024 21:17 — with GitHub Actions Inactive

tormath1 approved these changes Dec 20, 2024

View reviewed changes

ader1990 merged commit 6b96a3f into main Dec 20, 2024
5 of 7 checks passed

github-actions bot mentioned this pull request Dec 22, 2024

Monthly contributions report 2024-11-22 - 2024-12-21 flatcar/Flatcar#1603

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrade systemd from 255 to 256 #2145

Upgrade systemd from 255 to 256 #2145

ader1990 commented Jul 23, 2024 •

edited

Loading

ader1990 Jul 23, 2024

ader1990 commented Jul 23, 2024

github-actions bot commented Jul 23, 2024 •

edited

Loading

ader1990 commented Jul 24, 2024 •

edited

Loading

ader1990 commented Jul 24, 2024

chewi commented Aug 13, 2024

ader1990 commented Aug 13, 2024

ader1990 commented Sep 25, 2024

ader1990 commented Sep 25, 2024

ader1990 commented Sep 25, 2024 •

edited

Loading

chewi commented Sep 25, 2024

ader1990 commented Sep 25, 2024

ader1990 commented Sep 26, 2024 •

edited

Loading

ader1990 commented Sep 26, 2024

jepio commented Sep 27, 2024 via email

jepio commented Sep 27, 2024 via email

ader1990 commented Sep 30, 2024 •

edited

Loading

dongsupark commented Sep 30, 2024

sayanchowdhury commented Oct 9, 2024

tormath1 Dec 17, 2024

ader1990 Dec 17, 2024

tormath1 Dec 17, 2024

tormath1 Dec 17, 2024

ader1990 Dec 17, 2024

tormath1 Dec 17, 2024

ader1990 commented Dec 18, 2024 •

edited

Loading

sayanchowdhury commented Dec 18, 2024

tormath1 commented Dec 19, 2024

Upgrade systemd from 255 to 256 #2145

Upgrade systemd from 255 to 256 #2145

Conversation

ader1990 commented Jul 23, 2024 • edited Loading

Upgrade systemd from 255 to 256

Testing done

ader1990 Jul 23, 2024

Choose a reason for hiding this comment

ader1990 commented Jul 23, 2024

github-actions bot commented Jul 23, 2024 • edited Loading

ader1990 commented Jul 24, 2024 • edited Loading

ader1990 commented Jul 24, 2024

chewi commented Aug 13, 2024

ader1990 commented Aug 13, 2024

ader1990 commented Sep 25, 2024

ader1990 commented Sep 25, 2024

ader1990 commented Sep 25, 2024 • edited Loading

chewi commented Sep 25, 2024

ader1990 commented Sep 25, 2024

ader1990 commented Sep 26, 2024 • edited Loading

ader1990 commented Sep 26, 2024

jepio commented Sep 27, 2024 via email

jepio commented Sep 27, 2024 via email

ader1990 commented Sep 30, 2024 • edited Loading

dongsupark commented Sep 30, 2024

sayanchowdhury commented Oct 9, 2024

tormath1 Dec 17, 2024

Choose a reason for hiding this comment

ader1990 Dec 17, 2024

Choose a reason for hiding this comment

tormath1 Dec 17, 2024

Choose a reason for hiding this comment

tormath1 Dec 17, 2024

Choose a reason for hiding this comment

ader1990 Dec 17, 2024

Choose a reason for hiding this comment

tormath1 Dec 17, 2024

Choose a reason for hiding this comment

ader1990 commented Dec 18, 2024 • edited Loading

sayanchowdhury commented Dec 18, 2024

tormath1 commented Dec 19, 2024

ader1990 commented Jul 23, 2024 •

edited

Loading

github-actions bot commented Jul 23, 2024 •

edited

Loading

ader1990 commented Jul 24, 2024 •

edited

Loading

ader1990 commented Sep 25, 2024 •

edited

Loading

ader1990 commented Sep 26, 2024 •

edited

Loading

ader1990 commented Sep 30, 2024 •

edited

Loading

ader1990 commented Dec 18, 2024 •

edited

Loading