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]
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]
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
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
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.