Created attachment 1503292 [details] screenshot Description of problem: please see the attached screenshot for more information,thanks. Version-Release number of selected component (if applicable): Fedora-Server-dvd-x86_64-Rawhide-20181105.n.1.iso How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1503293 [details] anaconda.log
Created attachment 1503294 [details] packaging.log
Okay, so here are the scriptlets in fedora-logos: %post touch --no-create %{_datadir}/icons/hicolor || : touch --no-create %{_datadir}/icons/Bluecurve || : touch --no-create %{_datadir}/icons/Fedora || : touch --no-create %{_kde4_iconsdir}/oxygen ||: %postun if [ $1 -eq 0 ] ; then touch --no-create %{_datadir}/icons/hicolor || : touch --no-create %{_datadir}/icons/Bluecurve || : touch --no-create %{_datadir}/icons/Fedora || : touch --no-create %{_kde4_iconsdir}/oxygen ||: gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : gtk-update-icon-cache %{_datadir}/icons/Bluecurve &>/dev/null || : gtk-update-icon-cache %{_datadir}/icons/Fedora &>/dev/null || : gtk-update-icon-cache %{_kde4_iconsdir}/oxygen &>/dev/null || : fi %posttrans gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : gtk-update-icon-cache %{_datadir}/icons/Bluecurve &>/dev/null || : gtk-update-icon-cache %{_datadir}/icons/Fedora &>/dev/null || : gtk-update-icon-cache %{_kde4_iconsdir}/oxygen &>/dev/null || : **** Now, you might note that _every_ invocation has "|| :" at the end, which means if the first command fails for any reason, the shell should return ":", which is shell for "true". Thus, it should not be possible for any of these commandlines to fail in the shell. The gtk-update-icon-cache invocation for hicolor is not needed (and $DEITY help you if you are using older icon sets in 2018), and it does not look like gtk-update-icon-cache is installed in the packaging.log... but this is _fine_, because those scriptlets should never return false even if gtk-update-icon-cache is missing. It is also note worthy that the dnf transaction actually continued past this point, as you can see it installing packages after fedora-logos, and even hitting another "POSTIN" error here: 18:05:48,637 ERR dnf.rpm: Error in POSTIN scriptlet in rpm package crypto-policies That package seems to only have one scriptlet: /usr/bin/update-crypto-policies --no-check >/dev/null I strongly suspect something else weird is happening on this system. Since fedora-logos is installed on _every_ Fedora instance, this would be failing all over the place. In the absence of any obvious flaw in the scriptlets (none of which are new in the case of fedora-logos), I have to suspect the following (in order of likelyhood): * Failing hardware (possibly a bad disk or bad memory) * bug in "minimal" install configuration (not sure how though) * dnf bug (somehow?) * anaconda bug (somehow?) * cosmic rays I will leave this bug open, but I really have no idea how to address this.
I can say that this is a real issue & we are seeing this consistently in Anaconda integration tests (kickstart tests), from the full test run we got this 6 times (and 4 times the cryto-policies error): groups-and-envs-3 | modular-kstest1 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package fedora-logos: packages-excludedocs | modular-kstest1 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package fedora-logos: module-install-1 | modular-kstest4 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package fedora-logos: module-install-3 | modular-kstest4 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package crypto-policies: module-install-4 | modular-kstest1 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package fedora-logos: module-enable-one-module-multiple-times | modular-kstest3 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package crypto-policies: module-install-2 | modular-kstest4 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package crypto-policies: module-enable-many | modular-kstest3 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package fedora-logos: module-install-one-module-multiple-profiles | modular-kstest1 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package crypto-policies: module-install-many | modular-kstest3 | FAILED | error in log: dnf: Error in POSTIN scriptlet in rpm package fedora-logos: The tests run on Open Stack VMs via nested virtualization (one Open Stack VM runs 4 nested VMs for the installation runs). This generally means the actual installation is rather slow (can take 60+ minutes), which I guess could be the cause of the issue if the scriptlet or tools it uses contain a race condition that can be "won" only if the system is slow. Still, on the same testing setup, we have not been seeing these scriptlet errors before, so something must have changed, either in the scriptlet itself, the tools it uses or even possibly RPM/DNF. I'll attach kickstart & logs from one of the test runs so that they can be compared with the existing ones.
Created attachment 1503600 [details] a journal dump from the failed installation run The log starts around Anaconda startup in the VM and ends after log monitor noticed the scriptlet failure and shut down the VM.
Created attachment 1503601 [details] kickstart for the failed test run This is a kickstart corresponding to the log file from the failed test run.
Again, I have no idea how scriptlets that have not changed in years (and have been crafted in such a way that it is impossible for them to return "false" in the shell) would start throwing errors in the dnf transaction. I am highly suspicious of some change in dnf. That said, these scriptlets are no longer very useful in 2018, so I've removed them. This is almost certainly shifting the problem, not solving it, but eh. :D
(In reply to Tom "spot" Callaway from comment #7) > Again, I have no idea how scriptlets that have not changed in years (and > have been crafted in such a way that it is impossible for them to return > "false" in the shell) would start throwing errors in the dnf transaction. > > I am highly suspicious of some change in dnf. I find that likely as well - there have been many changes recently in DNF and this could be some harder to track down fallout from that. > > That said, these scriptlets are no longer very useful in 2018, so I've > removed them. This is almost certainly shifting the problem, not solving it, > but eh. :D Hey, problem solved - and I'm fine with that. :) We can always track the issue down if it shows up in a different package, rather than trying to do that via an effectively unneeded scriptlet.
Created attachment 1505931 [details] screenshot2
Still unable to finish the installation with server dvd, due to a different scriptlet error.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. 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 '31'. 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 31 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 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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.