Bug 1398847 - Fedora 25 Install from DVD ISO Fails DNF error: Non-fatal POSTIN scriptlet failure ... dovecot
Summary: Fedora 25 Install from DVD ISO Fails DNF error: Non-fatal POSTIN scriptlet fa...
Alias: None
Product: Fedora
Classification: Fedora
Component: dovecot
Version: 27
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
Depends On: 1565123
TreeView+ depends on / blocked
Reported: 2016-11-26 15:48 UTC by Ron Edge
Modified: 2019-11-27 15:23 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-11-30 22:03:14 UTC
Type: Bug

Attachments (Terms of Use)
Error from Anaconda (76.94 KB, image/jpeg)
2017-01-13 11:36 UTC, John Kissane
no flags Details
packaging log file for failed kickstart install (271.89 KB, text/plain)
2017-07-28 20:07 UTC, Gabriel Somlo
no flags Details
another log file mentioning dovecot left behind in /tmp on the failed kickstart (607 bytes, text/plain)
2017-07-28 20:08 UTC, Gabriel Somlo
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1553814 0 unspecified CLOSED "non-fatal" rpm error in kernel-core scriptlets is treated as fatal in anaconda and causes installation to fail 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1555931 0 unspecified CLOSED Installation fails due to a scriptlet failure of tex-fonts-hebrew 2021-02-22 00:41:40 UTC

Internal Links: 1553814 1555931

Description Ron Edge 2016-11-26 15:48:15 UTC
Description of problem:

Downloaded DVD iso Fedora 25. Verified burn of DVD. Went through install options. Just short of halfway through install, get fatal error as follows:

The following error occurred while installing. This is a fatal error and installation will be aborted.

DNF error: Non-fatal POSTIN scriptlet failure in rpm package dovecot.

Install at bottom shows installing dovecot.x86_64

Version-Release number of selected component (if applicable):

x64 DVD iso of Fedora 25: dvd-x86_64-25-1.3.iso

How reproducible:

First DVD failed. Fresh download, fresh burn with verify after burn. Both downloads and DVDs failed with same error.

This on an x96_64 ASUS board/box on which I have successfully installed Fedora 24 several times.

Steps to Reproduce:
1. Burn DVD, init install, fail.

Actual results:

Expected results:

Additional info:

Comment 1 Ron Edge 2016-11-27 14:58:32 UTC
To eliminate my hardware as source of problem, this morning I tried to install Fedora 25 server iso from same DVD to my old email box, different ASUS motherboard, different RAM, different new WD Black 1 TB SATA drive. The install fails fatally at the same place, on dovecot, with same error. The only option is to "Exit the install" in the error dialog which pops. FWIW, I opened the first to check, the MoBo was a newer supermicro, not an ASUS, on which as I said I had installed 24 server several times in past year playing with it.

Comment 2 Ron Edge 2016-11-28 11:44:38 UTC
I just had to do the following workaround to get around this fatal error doing iso install from DVD.

I used the same older ASUS board with new WD Black drive, and installed Fedora 24 server with all options, set networking.

I then ran a full dnf update and refresh.

I then found the Fedora doc on dnf-plugin-system-upgrade.

Followed each step in the doc, and the full upgrade to 25 of the fresh install of 24 appears to have worked and is up and running as Kernel 4.8.8-300 Fedora 25..

This on same hardware as the failed 25 install from DVD iso, so at this point, I am confident there is a problem in the ISO image at some point having to do with a dovecot scriptlet. Don't see how it could be anything else.

I also posted this in the install forum at fedoraproject.org, and someone else responded they had the same problem trying to do fresh install from iso.

Comment 3 John Kissane 2017-01-13 11:34:43 UTC
This may be unrelated but I've been trying a kickstart install of Fedora 25 which is failing with the same error message but for a different package:

"DNF error: Non-fatal POSTIN scriptlet failure in rpm package dpkg"

The ks.cfg file is the working one I use for Fedora 24 installs with updated paths to the local 25 repository.

Comment 4 John Kissane 2017-01-13 11:36:35 UTC
Created attachment 1240320 [details]
Error from Anaconda

Comment 5 John Kissane 2017-01-16 11:53:36 UTC
I've tried this with the just the original released set of packages (i.e. not listing the updates repository in the kickstart file) but the same thing happens. It does not appear possible to stop the attempt to install the dpkg package so not possible to carry out a kickstart install as far as I can see.

Comment 6 Michel Alexandre Salim 2017-01-18 21:13:28 UTC
This is the wrong component, reassigning to Anaconda. Please see https://fedoraproject.org/wiki/How_to_debug_installation_problems#Writing_the_Report

Comment 7 John Kissane 2017-01-19 16:33:30 UTC
For what's worth I've gotten round the kickstart error by tracking down the package whose dependency caused dpkg to be installed & removing it from the kickstart config file.

Strangely they're no problem installing the dpkg package via dnf after the install is complete.

Comment 8 john_freer 2017-04-16 22:57:31 UTC
Confirming - experiencing the same bug.  Attempting to workaround by not installing the mail servers group (hopefully avoid dovecot).  Interestingly I ran the installer 3 times various ways working directly on the target system... the rpm installations would begin, and I'd come back to a black screen with a cursor.  Basically the install would fail and reboot the PC, but the install hadn't finished, leaving a black screen (no linux boot prompt or anything).  I attempted a text mode install, and subsequently a VNC install.  The VNC window retained the error message, which is how I now know the error was from the failed scriptlet from dovecot.  Frustrating.

Comment 9 john_freer 2017-04-17 12:46:45 UTC
Confirming that workaround I noted above works.  De-select the "Mail Servers" subgroup in package selection, and just install the base Server package set.  Installation completed successfully.  I was then able to install the packages I needed (sendmail, apache, etc) post install.

Comment 10 Gabriel Somlo 2017-07-28 19:22:23 UTC
Happens in F26, while using kickstart.

I *have* to install a package which depends on (requires) dovecot, so the workaround of eliminating the problematic package isn't an option...

The error message I get from (text-mode) anaconda is cute:


   The following error occurred while installing.  This is a fatal error and
   installation will be aborted.

   DNF error: Non-fatal POSTIN scriptlet failure in rpm package dovecot

Press ENTER to exit:

Now, is it is, or is it ain't, a *fatal* error ? :)

Comment 11 Gabriel Somlo 2017-07-28 20:06:11 UTC
Also, after installation fails, running all of dovecot's "%post" commands manually from a shell console works without error:

    systemctl --no-reload preset dovecot.service
    // all directories under /var/run/dovecot exist, group ownership checks out
    /sbin/restorecon -R /var/run/dovecot

Attaching "packaging.log" and "tmp9s6g650k", which are the two files containing plausibly related logging data to the attempt by anaconda to install dovecot.

Comment 12 Gabriel Somlo 2017-07-28 20:07:14 UTC
Created attachment 1306027 [details]
packaging log file for failed kickstart install

Comment 13 Gabriel Somlo 2017-07-28 20:08:31 UTC
Created attachment 1306028 [details]
another log file mentioning dovecot left behind in /tmp on the failed kickstart

Comment 14 Gabriel Somlo 2017-09-28 16:18:40 UTC
(In reply to comments #7 and #9)
> Strangely they're no problem installing the dpkg package via dnf after the
> install is complete.

Even better, it just dawned on me I could simply add this to %post:

dnf -y install <whatever-depends-on-dovecot>

and still get the same unattended-install effect from kickstart, without manual follow-up. Still be nice if the actual problem got fixed, though :)

Comment 15 Samuel Sieb 2017-12-16 01:18:35 UTC
I ran into this installing F27.

Comment 16 Jiri Konecny 2017-12-18 12:32:02 UTC
If I understand it correctly every error in the process of package installation should be taken as FATAL.

Could the DNF developers agree or disagree on this statement please?

Comment 17 Ferry Huberts 2017-12-29 17:29:00 UTC
Ran into this with the F27 server dvd install

Comment 18 Ferry Huberts 2017-12-29 17:44:08 UTC
(In reply to Ferry Huberts from comment #17)
> Ran into this with the F27 server dvd install

It works ok with the F27 server netinstall iso

Comment 19 George R. Goffe 2018-04-05 15:48:43 UTC
This bug appears to be a show stopper with the "latest" Netinstall iso for rawhide (FC 29 now). That bug was reported on 14 March 2018 and apparently still exists. Please see bug "https://bugzilla.redhat.com/show_bug.cgi?id=1555931".

I believe the problem is with the package itself and not Anaconda since it is readily recreatable with the procedure listed in the above bug report. 

Is someone working this problem?

Comment 20 Vendula Poncova 2018-04-06 10:08:51 UTC
Reassigning to dovecot.

Comment 21 Bruce Jerrick 2018-05-25 10:25:43 UTC
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)

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

Comment 22 Jiri Konecny 2018-05-28 07:33:13 UTC
Hi Bruce,

Please look on the depend bug 1565123 which is answer to your question.

Comment 23 Bruce Jerrick 2018-06-22 06:15:22 UTC
(In reply to Jiri Konecny from comment #22)
> Hi Bruce,
> Please look on the depend bug 1565123 which is answer to your question.

Thanks, and I'm sorry about the delay in responding.
But it looks like that just changes the message; i.e., the installation will still abort.

By the way, I'm now getting it repeatably (well, twice) at 'Configuring systemd' (which seems *very* strange), but only with a 5500+ packages install, and not when installing only 1020 packages.

Comment 24 Ben Cotton 2018-11-27 15:06:50 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. 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 '27'.

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

Comment 25 Ben Cotton 2018-11-30 22:03:14 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 26 Jasper O'neal Hartline 2019-03-21 07:03:22 UTC
Sorry it couldnot be fixed what the fuck?

Comment 27 Samuel Sieb 2019-03-21 23:12:15 UTC
If it's still happening with current releases, then comment here.  If that's the case, then hopefully either the reporter or someone else with access can bump the version and reopen it.

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