Bug 106514 - rpm -F from amd-mounted NFS may remove packages from database
rpm -F from amd-mounted NFS may remove packages from database
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
: 108691 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-10-07 18:00 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-18 16:13:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2003-10-07 18:00:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031003

Description of problem:
Last night I ran rpm -F /net/free/l/mirror/redhat/rawhide/i386/RedHat/RPMS/*.rpm
on may laptop.  /net/free/l/mirror is amd-NFS-mounted from my desktop box.

For some reason, during the update, the amd mount seems to have broken (3 other
boxes were updating from the same server at the same time, and they didn't
fail).  rpm said the rpms were gone, and bailed out.  However, the database no
longer listed any of the packages that were meant to be updated, namely,
XFree86, glibc, mozilla and a few others.  XFree86 was actually broken, but
glibc was still there (the system survived a reboot).  Rebuilding the database
didn't fix it.

I managed to reinstall the missing packages, and no conflicts arose.

It's scare though to think that rpm -F may not only fail to install packages,
but also remove the original files from the package database.

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

How reproducible:
Didn't try

Steps to Reproduce:
1.Enable amd
2.Have it NFS-mount from another box a directory containing a bunch of updates
3.run rpm -F <thatdir>/*.rpm

Actual Results:  If amd happens to fail the way it did for me, you end up
without some of the packages that you didn't mean to remove.

Expected Results:  This shouldn't happen (TM).  It should either complete update
transaction, or roll it back.

Additional info:
Comment 1 Jeff Johnson 2003-10-09 09:51:28 EDT
rpm opens the files from the CLI twice, first to check
dependencies, later to actually install. If amd
umounts in between, then, yes, the packages cannot be
reopened, and the upgrade will fail in peculier ways.

Don't do that is the best answer I got. Reopening original pkgs
is necessary for anaconda to remount install media, and is unlikely
to be changed. Keeping file descriptors open has been known to
run out of file descriptors (although limits are probably
larger these days).
Comment 2 Alexandre Oliva 2003-10-09 12:45:48 EDT
See, I don't have much of a problem if it fails, but I think it's a major
problem that it ends up *removing* the packages that were meant to be replaced,
instead of leaving them alone.
Comment 3 Jeff Johnson 2003-10-10 09:04:13 EDT
The point at which the original package is reopened
is after all checks on package content have been performed.

The attempt to upgrade is final. Any failure after the
checks can/will have irreversible side effects, either
partially installed packages, or, in this case package

Don't install from automounted NFS is the answer.
Comment 4 Alexandre Oliva 2003-10-18 13:43:39 EDT
Does this mean that an unexpected reboot in the middle of an upgrade could have
results that are just as disastrous?
Comment 5 Jeff Johnson 2003-10-18 16:13:46 EDT

Failures of package scriptlets too,

Then there's kill -9 ...

ENOSPC makes a bloody mess as well, space is checked
before entering install state machine, leaving a largish

rpm has never provided any of the traditional
database commit semantics, never has, never will.

Sh*t happens, up to the user to clean up the mess afterwards,
or avoid siturations like NFS automounts.
Comment 6 Alexandre Oliva 2003-10-18 16:51:31 EDT
I see.  Thanks for the clarification.  I guess I was just expecting too much
from it :-(
Comment 7 Alexandre Oliva 2003-10-31 08:28:03 EST
*** Bug 108691 has been marked as a duplicate of this bug. ***

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