Created attachment 1679094 [details] microdnf_no_reported_error.log microdnf install httpd failed but return 0 error code at least for ppc64le f32 microdnf-3.4.0-2.fc32.ppc64le httpd-2.4.43-1.fc32.ppc64le Steps to Reproduce: === $wget https://kojipkgs.fedoraproject.org/compose/32/Fedora-32-20200414.1/compose/Container/ppc64le/images/Fedora-Container-Minimal-Base-32-1.3.ppc64le.tar.xz $image=Fedora-Container-Minimal-Base-32-1.3.ppc64le.tar.xz $latest=$(echo Fedora-Container-Minimal-Base-32-1.3.ppc64le | tr '[:upper:]' '[:lower:]') $podman load -i /tmp/$image $podman run --name test -dt $latest:latest bash; echo $? $podman ps -a $podman exec test microdnf update; echo $? $podman exec test microdnf repoquery microdnf httpd; echo $? $podman exec test microdnf install httpd; echo $? === Actual results: === $podman exec test microdnf install httpd; echo $? (microdnf:83): libdnf-WARNING **: 13:48:48.610: Loading "/etc/dnf/dnf.conf": IniParser: Can't open file Package Repository Size Installing: apr-1.7.0-3.fc32.ppc64le fedora 139.9\xc2\xa0kB apr-util-1.6.1-12.fc32.ppc64le fedora 113.9\xc2\xa0kB apr-util-bdb-1.6.1-12.fc32.ppc64le fedora 13.2\xc2\xa0kB apr-util-openssl-1.6.1-12.fc32.ppc64le fedora 15.5\xc2\xa0kB fedora-logos-httpd-30.0.2-4.fc32.noarch fedora 15.9\xc2\xa0kB httpd-2.4.43-1.fc32.ppc64le fedora 1.5\xc2\xa0MB httpd-filesystem-2.4.43-1.fc32.noarch fedora 14.5\xc2\xa0kB httpd-tools-2.4.43-1.fc32.ppc64le fedora 87.4\xc2\xa0kB mailcap-2.1.48-7.fc32.noarch fedora 31.8\xc2\xa0kB mod_http2-1.15.5-1.fc32.ppc64le fedora 176.6\xc2\xa0kB Transaction Summary: Installing: 10 packages Reinstalling: 0 packages Upgrading: 0 packages Removing: 0 packages Downgrading: 0 packages Downloading packages... Running transaction test... Installing: apr;1.7.0-3.fc32;ppc64le;fedora Installing: apr-util-bdb;1.6.1-12.fc32;ppc64le;fedora Installing: apr-util-openssl;1.6.1-12.fc32;ppc64le;fedora Installing: apr-util;1.6.1-12.fc32;ppc64le;fedora Installing: httpd-tools;2.4.43-1.fc32;ppc64le;fedora Installing: mailcap;2.1.48-7.fc32;noarch;fedora Installing: httpd-filesystem;2.4.43-1.fc32;noarch;fedora Installing: fedora-logos-httpd;30.0.2-4.fc32;noarch;fedora Installing: mod_http2;1.15.5-1.fc32;ppc64le;fedora Installing: httpd;2.4.43-1.fc32;ppc64le;fedora /usr/bin/systemctl: error while loading shared libraries: libsystemd-shared-245.so: cannot open shared object file: No such file or directory Complete. 0 === Expected results: expect a non null return code. Additional info: outputs of above commands in attached log file.
Please can you check whether the httpd package was actually correctly installed (from rpm perspective)? It's not clear from the bugreport: # rpm -V httpd
rpm -q reports httpd as installed, but trying to use systemctl in MinimalBase container is failing with same error message as when microdnf was called initially. === $podman exec test rpm -vq httpd; echo $? httpd-2.4.43-1.fc32.ppc64le 0 [root@abanb:/tmp] $podman exec test systemctl status httpd; echo $? systemctl: error while loading shared libraries: libsystemd-shared-245.so: cannot open shared object file: No such file or directory Error: non zero exit code: 127: OCI runtime error 127 [root@abanb:/tmp] $podman exec test systemctl; echo $? systemctl: error while loading shared libraries: libsystemd-shared-245.so: cannot open shared object file: No such file or directory Error: non zero exit code: 127: OCI runtime error 127 ===
I do not think this has anything to do with microdnf (btw dnf behaves the very same way). To see the error you don't even need to install anything, just issuing `systemctl` command in fresh container is enough. It looks like something is wrong with the container image - specifically with the systemd installation in it. Issuing `microdnf reinstall systemd` seemed to help: # systemctl systemctl: error while loading shared libraries: libsystemd-shared-245.so: cannot open shared object file: No such file or directory # ls /usr/lib/systemd ls: cannot access '/usr/lib/systemd': No such file or directory # microdnf reinstall systemd .... Downloading packages... Running transaction test... Installing: xkeyboard-config;2.29-1.fc32;noarch;fedora Installing: libxkbcommon;0.10.0-2.fc32;x86_64;fedora Installing: diffutils;3.7-4.fc32;x86_64;fedora Reinstalling: systemd;245.4-1.fc32;x86_64;fedora Complete. # ls /usr/lib/systemd/libsystemd-shared-245.so /usr/lib/systemd/libsystemd-shared-245.so # microdnf install httpd ..... Downloading packages... Running transaction test... Installing: apr;1.7.0-3.fc32;x86_64;fedora Installing: apr-util-bdb;1.6.1-12.fc32;x86_64;fedora Installing: apr-util-openssl;1.6.1-12.fc32;x86_64;fedora Installing: apr-util;1.6.1-12.fc32;x86_64;fedora Installing: httpd-tools;2.4.43-1.fc32;x86_64;fedora Installing: mailcap;2.1.48-7.fc32;noarch;fedora Installing: httpd-filesystem;2.4.43-1.fc32;noarch;fedora Installing: fedora-logos-httpd;30.0.2-4.fc32;noarch;fedora Installing: mod_http2;1.15.5-1.fc32;x86_64;fedora Installing: httpd;2.4.43-1.fc32;x86_64;fedora Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service. Created symlink /etc/systemd/system/sockets.target.wants/httpd.socket → /usr/lib/systemd/system/httpd.socket. Complete. # systemctl status httpd System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down Which is completly different problem - btw is there supposed to be systemd running in the container? I suggest to either reassign the bug to component that is responsible for building the image (not sure which one it is) or close it here as 'not a bug'.
as suggested by above investigation, assign to container image, assuming they know how it is built.
I do agree with comment 4, systemd is not expected to run on this kind of minimal container. The problem here is the httpd dependency on systemd. A pull request have been done on httpd on this subject https://src.fedoraproject.org/rpms/httpd/pull-request/7 but it seems httpd still depend some how on systemd. I re assign this problem to httpd.
$ podman run -ti registry.fedoraproject.org/fedora-minimal systemctl systemctl: error while loading shared libraries: libsystemd-shared-245.so: cannot open shared object file: No such file or directory It is not clear to me why this is anything close to an httpd bug. httpd has %post scripts (like many other packages) which run systemctl. The container image seems to have a broken systemctl. No, we are not going to remove systemd support from httpd.
Looks to me that the Minimal-Base container definition/content needs to be fixed if it contains systemctl binary, but not its libraries.
(In reply to Joe Orton from comment #6) > $ podman run -ti registry.fedoraproject.org/fedora-minimal systemctl > systemctl: error while loading shared libraries: libsystemd-shared-245.so: > cannot open shared object file: No such file or directory > > It is not clear to me why this is anything close to an httpd bug. httpd has > %post scripts (like many other packages) which run systemctl. The container > image seems to have a broken systemctl. No, we are not going to remove > systemd support from httpd. I was not thinking to remove systemd support from httpd but just have a smoother install when systemd is not activated but my knowledge %post scripts running systemctl is limited and it seems it is not the good way to resolve this problem. Looking to minimization work, I found this issue, that I believe it better addresses the problem https://pagure.io/minimization/issue/2
Although this deals with minimizing, this needs to stay with the container images team, not the minimization team. The container images team try to trim out alot of the unnecessary things, but it looks like they went too far. $ podman run -ti registry.fedoraproject.org/fedora-minimal bash bash-5.0# rpm -qa | grep systemd systemd-rpm-macros-245.4-1.fc32.noarch systemd-libs-245.4-1.fc32.x86_64 systemd-pam-245.4-1.fc32.x86_64 systemd-245.4-1.fc32.x86_64 So, all the systemd rpms are there bash-5.0# systemctl systemctl: error while loading shared libraries: libsystemd-shared-245.so: cannot open shared object file: No such file or directory Yet the library libsystemd-shared-245.so is missing. bash-5.0# rpm -V systemd ... missing /usr/lib/systemd/libsystemd-shared-245.so ... And there's the problem. Someone trimmed out the systemd shared library.
It is working fine still Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz systemd has been completely removed. Thanks
oups wrong copy, you must read It is working fine still Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz
But reopen it as it is still in error on f31 and f32, sorry for the noise...
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.