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:
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 erasures. 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?
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.
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. ***