Created attachment 1720004 [details] Kickstart script which triggers the bug The attached kickstart script causes a Fedora 32 installation to abort roughly 20% through the package install process with the message "DNF error: Error in PREIN scriptlet in rpm package xml-common". This is highly dependent on the selected packages, and the error does not lie in the xml-common package. If you un-comment line 297, which says "-dnfdragora" (i.e. exclude the dnfdragora from the package install selection), the installation completes without error. But I assume that this is a butterfly effect and the error isn't in the dnfdragora package either. The version of Anaconda being used is 32.24.7-1.fc32 and this comes with the ISO for "Fedora-Server-dvd-x86_64-32-1.6.iso" (after extracting the kernel+initrd and putting them on a netboot server). The crash is being tested on a VMware guest and currently happens reliably 100% of the time, but has also been observed on real hardware (Dell laptop) using an NFS-based version of the kickstart file. Once the message has happened, clicking the "Exit Installer" button seems to do nothing. In fact it seems the installation is continuing in the background, although since the post-install tasks are never carried out, the system won't boot afterwards. Neither the displayed message, nor the logfiles in /tmp, offer any explanation of what the PREIN scriptlet error actually was. The logfiles do contain several subsequent packaging errors, however. It may be significant that the scriptlet in question is being run immediately after the 'bash' postinstall scriptlet has run, and maybe there is a race condition somewhere. I apologise for the massive selection of packages in the kickstart script; this has been built up over many years of successive installs!
Hello Ian Collier, thank you for the report! There's two parts to this: a) That the installation continues and "Exit Installer" button does nothing is worth investigating. Can you please attach the logs? Without these it's impossible to do anything. b) I am a bit confused by this: "This is highly dependent on the selected packages, and the error does not lie in the xml-common package" ... "the error isn't in the dnfdragora package either". So, have you observed the same problem with any other packages?
Created attachment 1720008 [details] packaging.log Sorry, was in the process of transferring the logs and got distracted. Regarding why I don't think those two packages are to blame: we have done many, many successful installs which include the xml-common package (including the one-line change to the kickstart script which I mentioned earlier). In fact, even while the error is on the screen it is possible to switch to a text console and install it manually without errors. And I believe the dnfdragora package hasn't been installed yet when the error occurs, so it can't be that.
Created attachment 1720009 [details] anaconda.log
Created attachment 1720015 [details] packaging.log when the install is successful This is what the packaging log looks like when we exclude dnfdragora and create a successful install. That's the only change to the kickstart script, and yet now there are 200 log lines between the bash scriptlet and the xml-common scriptlet which were adjacent in the log of the failed install. This is what I mean by 'butterfly effect'.
To answer, your other question: no, I have not recently observed this error involving any other package. When it happens, the error always mentions xml-common. But probably that's a coincidence because no other package with a PREIN script happens to ever be placed right after bash in the install order. This is what the preinstall script of xml-common actually says: preinstall scriptlet (using /bin/sh): if [ $1 -gt 1 ] && [ -e /etc/xml/catalog ]; then # I've removed a bunch of stuff here fi If I understand RPM correctly, "$1" should equal 1 here because it's the first time the package was installed, and so all the lines I've removed aren't relevant because they are never executed. So this has to be a problem with Anaconda invoking the script, not with the script itself.
Thanks for the logs! So, I am not the best expert on this, but I believe the "butterfly effect" you observe is just that the resulting *list* of packages is based on the dependency resolution *tree*. So changes in the tree just manifest as "unpredictable" changes in the list. But what they really mean is that some changes in what is needed push many package earlier or later in the list, so together the effect appears unpredictable. But it must be actually deterministic, given the same system (dnf, rpm, whatever else) and inputs (groups, packages to install or avoid, and actual package files available). With that in mind, I believe your issue really means that either (a) the scriptlet fails but only in some condition, which exclusion of dnfdragora semi-randomly brings to light, or (b) dnf fails that way. Either way, Anaconda is not directly involved with this: It just converts the list from Kickstart to the right format and gives that to dnf. Thus reassigning to sgml-common (which is the source for xml-common), and if they think that's not their fault, dnf would be probably next stop... Regardless of the above, a workaround might be to not mention dnfdragora at all, and remove it in a %post script.
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.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. 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 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.