v2.243.0 breaks podman-machine-os

[lsm5]

run image tests when the podman machine is up and running should have zero critical error messages journalctl
/var/tmp/podman-machine-os/verify/image_test.go:122
  /usr/bin/podman-remote machine ssh ZdTklNDzezDY journalctl -p 0..2 -q
  Nov 11 14:18:40 localhost.localdomain sshd-session[2050]: fatal: Access denied for user core by PAM account configuration [preauth]
  [FAILED] in [It] - /var/tmp/podman-machine-os/verify/image_test.go:136 @ 11/11/25 14:18:49.287
• [FAILED] [0.514 seconds]
run image tests when the podman machine is up and running [It] should have zero critical error messages journalctl
/var/tmp/podman-machine-os/verify/image_test.go:122
  [FAILED] Expected
      <string>: Nov 11 14:18:40 localhost.localdomain sshd-session[2050]: fatal: Access denied for user core by PAM account configuration [preauth]
  to be empty
  In [It] at: /var/tmp/podman-machine-os/verify/image_test.go:136 @ 11/11/25 14:18:49.287

as seen at https://cirrus-ci.com/task/4689859949887488 and https://cirrus-ci.com/task/5815759856730112

This didn't break in v2.242.0 .

We should add podman-machine-os tests here in the process of fixing this.

Ref: containers/podman-machine-os#195

[Luap99]

The machine-os CI is complex due the need for bare metal systems so I am not sure it is worth it because...

It is not clear to me that there is a bug in this policy here, the error you show here in not the actual problem AFAICT, instead

  /usr/bin/podman-remote run -it --add-host=foobar123:host-gateway quay.io/libpod/testimage:20241011 cat /etc/hosts
  time="2025-11-11T14:19:28Z" level=warning msg="The input device is not a TTY. The --tty and --interactive flags might not work properly"
  Error relocating /lib/ld-musl-x86_64.so.1: RELRO protection failed: No error information
  Error relocating /bin/cat: RELRO protection failed: No error information

that is the real problem because it seems the container storage has incorrectly labelled files. We have seen these errors countless of times on the podman repo reported and in basically all cases it were install failures during container-selinux. I am not sure how these install scripts work in the image based design of coreos so I wonder if something weird is happening with it there somehow.

[lsm5]

ack. gotta check how to test on coreos. Testing farm doesn't show coreos composes https://api.testing-farm.io/v0.1/composes/public .

[Luap99]

yeah I guess we need to look closer what is going on, I mean AFAICT podman-next has been working fine on the main branch of podman-machine-os.

The thing there is that this only failed at runtime on our tests not at build time, so the dnf install didn't fail only when we run a container. So you would need to build such an image and then boot it in a VM to actually test whlich well gets complicated

Upgrading:
 container-selinux                   noarch 4:2.243.0-1.fc42 @commandline  72.6 KiB
   replacing container-selinux       noarch 4:2.242.0-1.fc42 <unknown>     72.6 KiB
 crun                                x86_64 1.25-1.fc42      @commandline 577.5 KiB
   replacing crun                    x86_64 1.24-1.fc42      <unknown>    577.5 KiB
 selinux-policy                      noarch 42.14-1.fc42     updates       31.6 KiB
   replacing selinux-policy          noarch 42.12-1.fc42     <unknown>     31.6 KiB
 selinux-policy-targeted             noarch 42.14-1.fc42     updates       18.7 MiB
   replacing selinux-policy-targeted noarch 42.12-1.fc42     <unknown>     18.6 MiB
Transaction Summary:
 Upgrading:          4 packages
 Replacing:          4 packages
 Removing:           1 package
[1/2] selinux-policy-0:42.14-1.fc42.noa 100% |   4.7 MiB/s |  62.2 KiB |  00m00s
[2/2] selinux-policy-targeted-0:42.14-1 100% | 141.5 MiB/s |   6.8 MiB |  00m00s
--------------------------------------------------------------------------------
[2/2] Total                             100% | 139.9 MiB/s |   6.9 MiB |  00m00s

This shows selinux-policy was updated as well so maybe container-selinux was not the real problem but rather that it always forces a new selinux-policy. IIRC we had this problem before where something else was broken there containers/podman-machine-os@04a239a