Description of problem: When installing Fedora Workstation, Czech language, default settings, Anaconda fails with an error message (see screenshot and provided logs) Version-Release number of selected component (if applicable): The image used was: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180302.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-28-20180302.n.0.iso Expected results: Anaconda installs system successfully.
The error mentioned above is: packaging.log:16:07:47,786 ERR dnf.rpm: Non-fatal POSTTRANS scriptlet failure in rpm package kernel-core
Created attachment 1406295 [details] Anaconda log
Created attachment 1406296 [details] Dnf librepo log
Created attachment 1406297 [details] Hawkey log
Created attachment 1406298 [details] Packaging log
Created attachment 1406306 [details] Program log
Created attachment 1406312 [details] Storage log
Created attachment 1406313 [details] Syslog
Created attachment 1406315 [details] Screenshot
I think this needs to be looked at by the anaconda team first because a) the error is supposed to be non-fatal b) I can't actually find logs that explain what the error is c) the posttrans script would probably be /bin/kernel-install which is maintained by systemd-udev
Potential duplicate of bug 1398847.
It is a fatal error. See https://bugzilla.redhat.com/show_bug.cgi?id=1565123. Reassigning to systemd.
Hmm, any reason why such an old image was used? I don't see the actual failure in the logs, but similar errors were fixed during the last month or so. Could you check with Fedora-28-20180409.n.0 ?
Created attachment 1419557 [details] journalctl My Kickstart IPXE install fails because of a "Non-fatal" scriptlet failure in systemd package The interesting part of the logs is this one: anaconda[1886]: packaging: Configuring (running scriptlet for): systemd-238-7.fc28.x86_64 1522220916 cf77ea519bf5cb426ee112ad6820e6149bc1ce5eeb821742f6b9ed21e6d1b253 anaconda[1886]: packaging: Configuring (running scriptlet for): systemd-238-7.fc28.x86_64 1522220916 cf77ea519bf5cb426ee112ad6820e6149bc1ce5eeb821742f6b9ed21e6d1b253 anaconda[1886]: packaging: Configuring (running scriptlet for): systemd-238-7.fc28.x86_64 1522220916 cf77ea519bf5cb426ee112ad6820e6149bc1ce5eeb821742f6b9ed21e6d1b253 systemd-binfmt[9335]: Failed to add binary format: No such file or directory systemd-binfmt[9335]: Failed to add binary format: No such file or directory anaconda[3146]: dnf: Non-fatal <unknown> scriptlet failure in rpm package systemd not sure if is the same bug, or i need to open another one
> My Kickstart IPXE install fails because of a "Non-fatal" scriptlet failure in systemd package Might be a different bug, because the package that has the scriptlet is different. Best if you open a new bug.
This is a copy of my Comment 21 to RHBZ 1398847: I get the same fatal non-fatal POSTIN scriptlet errors on the following packages during an F28 kickstart installation: clamav-update-0.99.4-3.fc28 (also happened in F25) dpkg-1.18.24-6.fc28 starplot-gliese3-0.95-15.fc28 starplot-yale5-0.95-15.fc28 And the same thing in the past with these: mozplugger (during F26 kickstart installation) lirc-core (during F27 Kickstart installation) All of these are repeatable. Even if the packages themselves are faulty, anaconda and dnf need to settle their differences about whether this is fatal or non-fatal. (In any case, it would be nice if anaconda could wait until all packages are tried before croaking; as it is, one has to re-run the installation to get to the next fatality.) As others have reported, the package installations succeed when done in the running system (after excluding them from the kickstart installation). UPDATE: According to https://kb.vmware.com/s/article/2040939 : By default, the RPM installer unpacks a temporary JRE to the /tmp directory, which is used for the remainder of the installation process. The error Non-fatal POSTIN scriptlet failure is the result of an SElinux policy that prevents executables from running in the /tmp directory. Even though the directory and unpacked files may have execute permissions, the system prevents the executables from running. That article provides a workaround (setting an alternative TMPDIR).
As I already replied to you on 2 other bugs. This is already resolved in bug 1565123. For future if you want us to reply on your question, then please use NEED INFO flag and link those bugs by see also. This copying comment on all bugs make our work harder and creates too much noise. Thank you.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. 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 '28'. 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 28 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 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 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.