Description of problem: When running `podman system service` Podman fails with the following error: Error: mkdir /sys/fs/cgroup/init: read-only file system Version-Release number of selected component (if applicable): ubi9/podman:9.1.0-5@sha256:3a9d42016fdd273fb37d053644792aba1268638dd2a066d186c91fa8a357e365 podman-4.2.0-7.el9_1.x86_64 How reproducible: Always Steps to Reproduce: 1. podman run --rm registry.access.redhat.com/ubi9/podman:9.1.0-5@sha256:3a9d42016fdd273fb37d053644792aba1268638dd2a066d186c91fa8a357e365 podman system service Actual results: time="2023-04-11T05:17:01Z" level=warning msg="\"/\" is not a shared mount, this could cause issues or missing mounts with rootless containers" time="2023-04-11T05:17:01Z" level=warning msg="Using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids if not using a network user" Error: mkdir /sys/fs/cgroup/init: read-only file system Expected results: Podman should start as a service and listen for incoming connections Additional info: This has been fixed upstream and released in 4.3.0
It also doesn't work for podman-4.4.1-8.el9 on RHEL 9.3. [root@kvm-01-guest11 ~]# cat /etc/redhat-release Red Hat Enterprise Linux release 9.3 Beta (Plow) [root@kvm-01-guest11 ~]# rpm -q podman crun kernel podman-4.4.1-8.el9.x86_64 crun-1.8.3-2.el9.x86_64 kernel-5.14.0-295.el9.x86_64 [root@kvm-01-guest11 ~]# podman run --rm registry.access.redhat.com/ubi9/podman:9.1.0-5@sha256:3a9d42016fdd273fb37d053644792aba1268638dd2a066d186c91fa8a357e365 podman system service Trying to pull registry.access.redhat.com/ubi9/podman@sha256:3a9d42016fdd273fb37d053644792aba1268638dd2a066d186c91fa8a357e365... Getting image source signatures Checking if image destination supports signatures Copying blob ef82b56a7d83 done Copying blob d74e20a2726b done Copying config d6fb9bd0b4 done Writing manifest to image destination Storing signatures time="2023-04-11T10:43:10Z" level=warning msg="\"/\" is not a shared mount, this could cause issues or missing mounts with rootless containers" Error: mkdir /sys/fs/cgroup/init: read-only file system A workaround is to append --privileged option to podman run like below [root@kvm-01-guest11 ~]# podman run --privileged registry.access.redhat.com/ubi9/podman:9.1.0-5@sha256:3a9d42016fdd273fb37d053644792aba1268638dd2a066d186c91fa8a357e365 podman system service -t 0 & [1] 88852 [root@kvm-01-guest11 ~]# podman ps --no-trunc CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 75a2bb3189620e9b5c0dd5d061ec0d68a1b364be846ca756960b7e3bcbb6d7f2 registry.access.redhat.com/ubi9/podman@sha256:3a9d42016fdd273fb37d053644792aba1268638dd2a066d186c91fa8a357e365 podman system service -t 0 3 minutes ago Up 3 minutes magical_ellis
That's rather strange as I have it working on UBI 9.1 by installing podman-4.4.0-1.el9.x86_64.rpm from a 9.2 beta system. [build@aea5c6c3df67 ~]$ rpm -q podman podman-4.4.0-1.el9.x86_64 [build@aea5c6c3df67 ~]$ podman --log-level info system service INFO[0000] podman filtering at log level info INFO[0000] Setting parallel job count to 49 INFO[0000] podman filtering at log level info INFO[0000] Setting parallel job count to 49 INFO[0000] API service listening on "/tmp/podman-run-1000/podman/podman.sock". URI: "unix:/tmp/podman-run-1000/podman/podman.sock"
@ajia I read your comment more thoroughly now. The problem is Podman in the UBI image, not Podman on the host - in the production system our image is running under CRI-O, not Podman.
(In reply to raniz from comment #3) > @ajia I read your comment more thoroughly now. The problem is > Podman in the UBI image, not Podman on the host - in the production system > our image is running under CRI-O, not Podman. It works in root mode for running tests in nested podman container w/ --privileged option. 1. root a. w/ --privileged option [root@kvm-01-guest21 ~]# podman run --privileged -it registry-proxy.engineering.redhat.com/rh-osbs/rhel9-podman:9.1.0-13 Trying to pull registry-proxy.engineering.redhat.com/rh-osbs/rhel9-podman:9.1.0-13... Getting image source signatures Copying blob 1ac0cc55d713 done Copying blob fdf83fdf5c32 done Copying config 8336e53d79 done Writing manifest to image destination Storing signatures [root@81e629389117 /]# rpm -q podman crun podman-4.2.0-10.el9_1.x86_64 crun-1.5-1.el9.x86_64 [root@723e69b03590 /]# podman --log-level info system service -t 0 & [1] 11 [root@723e69b03590 /]# INFO[0000] podman filtering at log level info INFO[0000] Setting parallel job count to 7 INFO[0000] API service listening on "/run/podman/podman.sock". URI: "unix:///run/podman/podman.sock" INFO[0000] API service listening on "/run/podman/podman.sock" b. w/o --privileged option [root@kvm-01-guest21 ~]# podman run -it registry-proxy.engineering.redhat.com/rh-osbs/rhel9-podman:9.1.0-13 [root@81e629389117 /]# podman --log-level info system service INFO[0000] podman filtering at log level info WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers INFO[0000] podman filtering at log level info INFO[0000] Setting parallel job count to 7 Error: mkdir /sys/fs/cgroup/init: read-only file system 2. rootless [root@kvm-01-guest21 ~]# podman run --privileged -it registry-proxy.engineering.redhat.com/rh-osbs/rhel9-podman:9.1.0-13 [root@9f2454dac717 /]# su test [test@9f2454dac717 /]$ id uid=1001(test) gid=1001(test) groups=1001(test) [test@9f2454dac717 /]$ podman unshare cat /proc/self/uid_map 0 1001 1 1 100000 65536 [test@9f2454dac717 /]$ podman --log-level info system service INFO[0000] podman filtering at log level info INFO[0000] Setting parallel job count to 7 INFO[0000] podman filtering at log level info INFO[0000] Setting parallel job count to 7 Error: mkdir /sys/fs/cgroup/init: permission denied
It does, but using privileged containers is not an option for us.
@mheon thoughts on this one?
The issue has been fixed upstream in Podman, and will land in RHEL 9.2 with Podman 4.4. At some point, that content will be added to UBI9 (I do not know the lifecycle of UBI, so I cannot say when, that is a question for someone else). I don't really have any thoughts other than this. Is the request here is for a 9.1 backport of the specific patch and then subsequently getting a Podman build with that backport into UBI9? If so, the first questions would have to be to the maintainers of UBI, because their policy on accepting updates outside of major RHEL releases will control that.
@mheon For me this is a request of a backport since it seems to be fixed with 9.2 but I have no idea when that will hit - and until it does we need to maintain a workaround in our image (which is to keep the RPM from 9.2 Beta up to date and installed in the image).
(In reply to Matthew Heon from comment #7) > The issue has been fixed upstream in Podman, and will land in RHEL 9.2 with > Podman 4.4. At some point, that content will be added to UBI9 (I do not know > the lifecycle of UBI, so I cannot say when, that is a question for someone > else). I don't really have any thoughts other than this. UBI9 inherits RHEL rpms from the latest minor release. (In reply to raniz from comment #8) > @mheon For me this is a request of a backport since it seems to > be fixed with 9.2 but I have no idea when that will hit - and until it does > we need to maintain a workaround in our image (which is to keep the RPM from > 9.2 Beta up to date and installed in the image). Do you have a Customer Portal support case opened for this?
@(In reply to Josh Boyer from comment #9) > (In reply to Matthew Heon from comment #7) > > The issue has been fixed upstream in Podman, and will land in RHEL 9.2 with > > Podman 4.4. At some point, that content will be added to UBI9 (I do not know > > the lifecycle of UBI, so I cannot say when, that is a question for someone > > else). I don't really have any thoughts other than this. > > UBI9 inherits RHEL rpms from the latest minor release. So I guess that means this will resolve itself when RHEL 9.2 hits. Any estimate on when that is? > (In reply to raniz from comment #8) > > @mheon For me this is a request of a backport since it seems to > > be fixed with 9.2 but I have no idea when that will hit - and until it does > > we need to maintain a workaround in our image (which is to keep the RPM from > > 9.2 Beta up to date and installed in the image). > > Do you have a Customer Portal support case opened for this? I do not. I'm a consultant and don't have access to my customer's subscription. Perhaps I should ask my customer to open one?
(In reply to raniz from comment #11) > @(In reply to Josh Boyer from comment #9) > > (In reply to Matthew Heon from comment #7) > > > The issue has been fixed upstream in Podman, and will land in RHEL 9.2 with > > > Podman 4.4. At some point, that content will be added to UBI9 (I do not know > > > the lifecycle of UBI, so I cannot say when, that is a question for someone > > > else). I don't really have any thoughts other than this. > > > > UBI9 inherits RHEL rpms from the latest minor release. > > So I guess that means this will resolve itself when RHEL 9.2 hits. Any > estimate on when that is? RHEL has a 6 month minor release cadence. 9.1 shipped at the beginning of November, so 9.2 should be available sometime in May. > > (In reply to raniz from comment #8) > > > @mheon For me this is a request of a backport since it seems to > > > be fixed with 9.2 but I have no idea when that will hit - and until it does > > > we need to maintain a workaround in our image (which is to keep the RPM from > > > 9.2 Beta up to date and installed in the image). > > > > Do you have a Customer Portal support case opened for this? > > I do not. I'm a consultant and don't have access to my customer's > subscription. Perhaps I should ask my customer to open one? Customer cases are always appreciated. In this specific instance, if the customer can wait for the 9.2 release then it likely isn't necessary because the fix is already planned.
(In reply to Josh Boyer from comment #12) > > RHEL has a 6 month minor release cadence. 9.1 shipped at the beginning of > November, so 9.2 should be available sometime in May. In that case I'd say we'll just wait > > Customer cases are always appreciated. In this specific instance, if the > customer can wait for the 9.2 release then it likely isn't necessary because > the fix is already planned. Can and want is two different things :) But since 9.2 looks to be on the horizon I think it's ok. I'll have to keep an eye out and see if Podman in 9.2 beta gets any patches and keep our workaround updated in the interim. I consider this issue closed from our point of view then. Thanks!
NGL Mod APK is the PRO version of NGL APK. By using the NGL Mod APK, you can easily complete any tasks and requirements in it. Often you need to spend a lot of time or money to get rewards easily, but by using NGL Mod APK, you often achieve your goals in a very short time. https://apkscart.com/ngl-mod-apk/