test: remove outdated checkpoint skip

[Luap99]

This should work again with the latest VM images.

Fixes: #26289

Does this PR introduce a user-facing change?

None

[baude]

LGTM

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[packit-as-a-service]

tmt tests failed for commit 029b462. @lsm5, @psss, @thrix please check.

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[Luap99]

Only aarch64 failing with a selinux problem?

         not ok 422 |520| podman checkpoint --export, with volumes in 2487ms
         # tags: ci:parallel
         # (from function `bail-now' in file test/system/helpers.bash, line 230,
         #  from function `die' in file test/system/helpers.bash, line 967,
         #  from function `wait_for_output' in file test/system/helpers.bash, line 693,
         #  from function `wait_for_ready' in file test/system/helpers.bash, line 704,
         #  in test file test/system/520-checkpoint.bats, line 158)
         #   `_PODMAN_TEST_OPTS="$p_opts" wait_for_ready $cid' failed
         #
<+     > # # podman  image exists quay.io/libpod/testimage:20241011
<+055ms> # [ rc=1 ]
         # # skopeo copy --all oci-archive:/tmp/CI_rkFm/podman-systest-imagecache-0/quay.io--libpod--testimage--20241011.tar containers-storage:[overlay@/tmp/CI_rkFm/podman_bats.Jg8xet/root+/tmp/CI_rkFm/podman_bats.Jg8xet/runroot]quay.io/libpod/testimage:20241011
         # Getting image source signatures
         # Copying blob sha256:5be41df7978d85a664af00d0a7cdb0ebb1a479f421db7c2c63ff5cc6492870b1
         # Copying blob sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
         # Copying config sha256:13dc0b3d0b0ab2d7068069d03d18d0c4ac8f07e2eb2d4bf37fc72b4d9dbf9378
         # Writing manifest to image destination
         #
<+1.32s> # # podman  --root /tmp/CI_rkFm/podman_bats.Jg8xet/root --runroot /tmp/CI_rkFm/podman_bats.Jg8xet/runroot --tmpdir /tmp/CI_rkFm/podman_bats.Jg8xet/tmpdir --events-backend file volume create v-t422-7889mn2s
<+053ms> # v-t422-7889mn2s
         #
<+102ms> # # podman  --root /tmp/CI_rkFm/podman_bats.Jg8xet/root --runroot /tmp/CI_rkFm/podman_bats.Jg8xet/runroot --tmpdir /tmp/CI_rkFm/podman_bats.Jg8xet/tmpdir --events-backend file run -d --name c-t422-7889mn2s --volume v-t422-7889mn2s:/myvol -p 5379:80 -w /myvol quay.io/libpod/testimage:20241011 sh -c /bin/busybox-extras httpd -p 80;echo c-t422-7889mn2s >cname;echo READY;while :;do cat /proc/uptime >mydate.tmp;mv -f mydate.tmp mydate;sleep 0.1;done
<+183ms> # f6677e38df0542078c79b32187a2adbf214f29d0fd54ae68b62282766efc37bb
         #
<+045ms> # # podman  logs f6677e38df0542078c79b32187a2adbf214f29d0fd54ae68b62282766efc37bb
<+057ms> # Error relocating /bin/sh: RELRO protection failed: No error information
         #
<+018ms> # # podman  inspect --format {{.State.Running}} f6677e38df0542078c79b32187a2adbf214f29d0fd54ae68b62282766efc37bb
<+062ms> # false
         #
<+020ms> # # podman  inspect --format {{.State.ExitCode}} f6677e38df0542078c79b32187a2adbf214f29d0fd54ae68b62282766efc37bb
<+049ms> # 127
         #
<+023ms> # # podman  logs f6677e38df0542078c79b32187a2adbf214f29d0fd54ae68b62282766efc37bb
<+067ms> # Error relocating /bin/sh: RELRO protection failed: No error information
         # #/vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
         # #| FAIL: Container exited (status: 127) before we saw 'READY': Error relocating /bin/sh: RELRO protection failed: No error information
         # #\^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

AVC avc:  denied  { read } for  pid=222507 comm="sh" path="/bin/busybox" dev="tmpfs" ino=34578 scontext=system_u:system_r:container_t:s0:c203,c847 tcontext=system_u:object_r:container_var_run_t:s0 tclass=file permissive=0

The container_var_run_t label on the container content seems clearly wrong.

The logs form the job show

container-selinux-2.247.0-1.fc43-noarch

which is the same version as on the passing x86_64 host and selinux should not be arch specific so what is going on with this?
cc @lsm5

[lsm5]

that's weird. Looking into this ..

[lsm5]

So, this doesn't occur on a testing-farm f43 aarch64 instance, the differences being selinux-policy and kernel versions.

Cirrus env:
selinux-policy-43.1-1.fc43
kernel-6.19.8-200.fc43

TF:
selinux-policy-43.6-1.fc43
kernel-6.19.12-200.fc43

I suspect some kernel/overlay issue which has since been fixed. I can track this further and also enable testing-farm jobs for aarch64.

For Cirrus, maybe an image update to fetch newer packages would do it?

[lsm5]

I can track this further and also enable testing-farm jobs for aarch64.

#28565

[Luap99]

I suspect some kernel/overlay issue which has since been fixed. I can track this further and also enable testing-farm jobs for aarch64.

I don't think that matters, per AVC the content is labelled wrong, it should not be container_var_run_t but I do not see how the kernel would change that all of the sudden. I suspect some environmental thing we are missing which could explain that it works on tmt.

[lsm5]

I did try a dnf reinstall container-selinux in the Cirrus VM terminal on the failed aarch64 job but a subsequent run seems to have failed too. I don't know off-hand if the reinstall took effect on that env though.

[Luap99]

I wonder if this relates to #26473 (comment) in how the tmp dir is created first. But again not sure how the arch matters for anything here as the policies are the same.