Bug 106514 - rpm -F from amd-mounted NFS may remove packages from database
Summary: rpm -F from amd-mounted NFS may remove packages from database
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
: 108691 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-10-07 22:00 UTC by Alexandre Oliva
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-10-18 20:13:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2003-10-07 22:00:51 UTC
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):
rpm-4.2.1-0.30

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 13:51:28 UTC
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 16:45:48 UTC
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 13:04:13 UTC
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
erasures.

Don't install from automounted NFS is the answer.

Comment 4 Alexandre Oliva 2003-10-18 17:43:39 UTC
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 20:13:46 UTC
Yes.

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

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 20:51:31 UTC
I see.  Thanks for the clarification.  I guess I was just expecting too much
from it :-(

Comment 7 Alexandre Oliva 2003-10-31 13:28:03 UTC
*** 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.