Bug 106514

Summary:	rpm -F from amd-mounted NFS may remove packages from database
Product:	[Fedora] Fedora	Reporter:	Alexandre Oliva <oliva>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED WONTFIX	QA Contact:	Mike McLean <mikem>
Severity:	high	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	michael-ring
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-10-18 20:13:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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