Remove Cgroups v1 support (podman6)

[lsm5]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

Removes Cgroups v1 support. Required as part of Podman v6

How to verify it

Try doing anything on a cgroups v1 env and ensure nothing works (I guess).

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

Only merge whenever we're merging for Podman6

Does this PR introduce a user-facing change?

Cgroups v1 is no longer supported.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lsm5]

Please remind me if we included the debian test for cgroups v1 testing (because we couldn't reliably do RHEL in CI or something else).

[TomSweeneyRedHat]

@lsm5 I'm not sure on the Debian,

But it does look like you might have a real error in the Fedora-41 runc w/ overlay:

[+0608s] not ok 761 net-namespace
[+0608s] # (from function `die' in file ./helpers.bash, line 443,
[+0608s] #  from function `run_buildah' in file ./helpers.bash, line 430,
[+0608s] #  from function `general_namespace' in file ./namespaces.bats, line 325,
[+0608s] #  in test file ./namespaces.bats, line 377)
...
[+0608s] # # /var/tmp/go/src/github.com/containers/buildah/tests/./../bin/buildah run --cni-config-dir=/tmp/buildah_tests.ijzkfr/no-cni-configs --net=container alpine-working-container-5 readlink /proc/self/ns/net
[+0608s] # net:[4026532942]
[+0608s] # time="2025-10-10T09:59:09-05:00" level=error msg="seek /sys/fs/cgroup/system.slice/runc-buildah-buildah4248988723.scope/cgroup.freeze: no such device"
[+0608s] # error running container: deleting container: exit status 1
[+0608s] # Error: while running runtime: exit status 1
[+0608s] # [ rc=1 (** EXPECTED 0 **) ]
[+0608s] # #/vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
[+0608s] # #| FAIL: exit code is 1; expected 0
[+0608s] # #\^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[+0608s] # /var/tmp/go/src/github.com/containers/buildah/tests

[TomSweeneyRedHat]

I wonder if we can just do away with this function call entirely?

[nalind]

@lsm5 I'm not sure on the Debian,

But it does look like you might have a real error in the Fedora-41 runc w/ overlay:
...
[+0608s] # time="2025-10-10T09:59:09-05:00" level=error msg="seek /sys/fs/cgroup/system.slice/runc-buildah-buildah4248988723.scope/cgroup.freeze: no such device"

That's a known flake which should be fixed in runc 1.3.2. Not sure if/when we'll see an updated runc package for that Fedora release. Until then we don't block on CI jobs failing with runc.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[TomSweeneyRedHat]

@lsm5 some possible compilation issues.

[lsm5]

@nalind @flouthoc if i add a single cgroupsv2 check in main(), it causes chroot with overlay root system test to fail as in https://cirrus-ci.com/task/5933237815476224?logs=integration_test#L870 , and without that check everything passes as in the current CI results (excluding runc jobs which I'm ignoring per one of the above comments). Any idea if it's an issue in the test itself or if I messed up somewhere?

[nalind]

The test sets up a chrooted environment in a user namespace with ID mappings to ensure that we can use chrooted isolation in such an environment, but that set up does not include a mount at /sys/fs/cgroup, and it looks like cgroups.IsCgroup2UnifiedMode() returns false in such an environment.

[lsm5]

The test sets up a chrooted environment in a user namespace with ID mappings to ensure that we can use chrooted isolation in such an environment, but that set up does not include a mount at /sys/fs/cgroup, and it looks like cgroups.IsCgroup2UnifiedMode() returns false in such an environment.

@nalind ack. So, would you suggest modifying the test to include a /sys/fs/cgroup mount, or perhaps placing the v1/v2 check somewhere else instead?

[nalind]

The test sets up a chrooted environment in a user namespace with ID mappings to ensure that we can use chrooted isolation in such an environment, but that set up does not include a mount at /sys/fs/cgroup, and it looks like cgroups.IsCgroup2UnifiedMode() returns false in such an environment.

@nalind ack. So, would you suggest modifying the test to include a /sys/fs/cgroup mount, or perhaps placing the v1/v2 check somewhere else instead?

Well, I wouldn't want it to start failing in such an environment, so if the test has to be there, my preference would be to move it elsewhere.