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):
Steps to Reproduce:
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.
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).
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.
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.
Does this mean that an unexpected reboot in the middle of an upgrade could have
results that are just as disastrous?
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.
I see. Thanks for the clarification. I guess I was just expecting too much
from it :-(
*** Bug 108691 has been marked as a duplicate of this bug. ***