bump coreos-init and bootengine commit for cgroupv1-runtime-revert support

[jepio]

bump coreos-init and bootengine commit for cgroupv1-runtime-revert support

This introduces changes to bootengine and coreos-init to support dynamically switching back to legacy cgroups when the /etc/flatcar-cgroupv1 flag file is found. This is done by running a binary before sysroot init is started by the initramfs, right after switch-root. This binary unmounts any cgroups initramfs may have set up and overlays /proc/cmdline with the right kernel arguments to convince systemd to setup legacy cgroups.

Pulls in:

• support flag file to runtime switch to cgroupv1 flatcar/bootengine#35
• add init.wrapper to force switch to legacy cgroups after initramfs flatcar/init#62

How to use

Build image and boot with the following ignition:

storage:
  files:
  - path: /etc/flatcar-cgroupv1
    mode: 0444

Testing done

Mantle test: flatcar/mantle#298.

CI started with newly added mantle test: http://jenkins.infra.kinvolk.io:8080/job/os/job/manifest/4935/cldsv/

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)

[jepio]

Test cl.cgroupv1 passed with this change.

[JAORMX]

Out of curiosity is Flatcar now using cgroups v2 by default?

[pothos]

Out of curiosity is Flatcar now using cgroups v2 by default?

Yes, for new installations, details here: https://www.flatcar.org/docs/latest/container-runtimes/switching-to-unified-cgroups/

[jepio]

I'll merge this, ok @pothos?

[pothos]

A changelog entry would be good when this PR gets cherry-picked it will also be taken

[jepio]

Added the changelog entry.

[skshandilya]

have you guys thought of the long term effects of this, because we are now introducing two ways of updating the kernel command line, one via initramfs and the other old and proven method via bootloader. People are going to wonder where these kernel options came from in the future.

[jepio]

Yes, that is a concern we had when going down this road. We do prefer the proven bootloader method, but we heard from many users that they:

• need cgroups v1
• can't deal with the required reboot to apply the kernel command line settings

Did this change cause issues for you? Do you have any suggestions of how better to deal with this and the tradeoffs?

[pothos]

This is only meant for the first boot. The correct kernel parameters should still be set the old way for persistence.

[pothos]

@jepio Should we add logic to skip the bind-mounting if the parameters are already present?

[pothos]

Or is this already done through the /sys/fs/cgroup/cgroup.subtree_control check?
Edit: Yes.

[jepio]

Yes (it is skipped if cgroupv2 is not mounted via the cgroup.subtree_control check)