Bug 1398847

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.

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.

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.

Created attachment 1240320 [details]
Error from Anaconda

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.

This is the wrong component, reassigning to Anaconda. Please see https://fedoraproject.org/wiki/How_to_debug_installation_problems#Writing_the_Report

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.

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.

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.

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:

----------------------------------------------------
Error

   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 ? :)

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.

Created attachment 1306027 [details]
packaging log file for failed kickstart install

Created attachment 1306028 [details]
another log file mentioning dovecot left behind in /tmp on the failed kickstart

(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 :)

I ran into this installing F27.

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?

Ran into this with the F27 server dvd install

(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

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?

Reassigning to dovecot.

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

Hi Bruce,

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

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

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.

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

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

Sorry it couldnot be fixed what the fuck?

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.