Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1886501 - Fedora 32 kickstart installation aborts on a PREIN scriptlet
Summary: Fedora 32 kickstart installation aborts on a PREIN scriptlet
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: sgml-common
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-10-08 15:32 UTC by Ian Collier
Modified: 2021-05-04 13:43 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)
Kickstart script which triggers the bug (6.62 KB, text/plain)
2020-10-08 15:32 UTC, Ian Collier
no flags Details
packaging.log (722.34 KB, text/plain)
2020-10-08 16:10 UTC, Ian Collier
no flags Details
anaconda.log (29.75 KB, text/plain)
2020-10-08 16:12 UTC, Ian Collier
no flags Details
packaging.log when the install is successful (2.08 MB, text/plain)
2020-10-08 16:33 UTC, Ian Collier
no flags Details

Description Ian Collier 2020-10-08 15:32:16 UTC
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!

Comment 1 Vladimír Slávik 2020-10-08 15:53:20 UTC
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?

Comment 2 Ian Collier 2020-10-08 16:10:58 UTC
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.

Comment 3 Ian Collier 2020-10-08 16:12:33 UTC
Created attachment 1720009 [details]

Comment 4 Ian Collier 2020-10-08 16:33:10 UTC
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'.

Comment 5 Ian Collier 2020-10-08 16:58:19 UTC
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

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.

Comment 6 Vladimír Slávik 2020-10-23 18:42:24 UTC
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.

Comment 7 Fedora Program Management 2021-04-29 16:40:25 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.