Bug 118029 - "fatal RPM install error" corrupts the database: removes old packages w/o installing new ones!
Summary: "fatal RPM install error" corrupts the database: removes old packages w/o ins...
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
Keywords: Reopened
: 115182 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-11 10:07 UTC by Aleksey Nogin
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-10 09:26:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Full output of that up2date session. (10.87 KB, text/plain)
2004-03-11 10:07 UTC, Aleksey Nogin
no flags Details

Description Aleksey Nogin 2004-03-11 10:07:26 UTC
I was instaling yesterday's Raw Hide updates via "up2date -u" and it died:

########################################### [100%]
########################################### [100%]
There was a fatal RPM install error. The message was:
There was a rpm unpack error installing the package: tk-8.4.5-5

After that, it turned out that the first 21 packages were upgraded
correctly, but the remaining ones (started with tk) were simply erased.

Comment 1 Aleksey Nogin 2004-03-11 10:08:00 UTC
Created attachment 98453 [details]
Full output of that up2date session.

Comment 2 Aleksey Nogin 2004-03-11 10:19:06 UTC
Turnes out that the packages were still there _on disk_ (not sure
whether that were old ones or new ones), but were missing in the RPM
database. So this is very similar to bug 115182.

Comment 3 Adrian Likins 2004-04-07 21:13:47 UTC
rpm unpackage errors typically indicate a packaging issue
that causes the cpio payload format to break (replacing
dirs with symlinks is a common one). 

So reassigning to tk

Comment 4 Aleksey Nogin 2004-04-07 21:20:08 UTC
The tk error (which was already fixed AFAIK) is not what the bug is
about. Even when there is indeed "a packaging issue that causes the
cpio payload format to break", IMHO up2date should handle it much
better. Dropping packages _that are still installed_ from the db is
not just a big annoyance, it's also a security problem.

Comment 5 Jens Petersen 2004-04-08 11:03:55 UTC
This was fixed in tk-8.4.5-6.

*** This bug has been marked as a duplicate of 118030 ***

Comment 6 Jens Petersen 2004-04-08 11:36:26 UTC
Sorry, Aleksey, I didn't read comment 4 properly: reopening.

Comment 7 Adrian Likins 2004-06-17 18:46:05 UTC
the transaction behaviour in lieu of bad packages like that tk 
package is an rpm issue, reassigning there.

Comment 8 Jeff Johnson 2004-06-26 13:19:20 UTC
The above scenario is the only behavior possible for
up2date because there is no way to resume the current
transaction from an error callback from rpmlib.

AFAICT, the root cause of the problem was bad packaging.
Fixing the package is the correct approach.

Graceful exit under all possible error conditions,
including bad input from packages, etc., is not going
to happen soon, if ever.

Comment 9 Aleksey Nogin 2004-06-26 20:55:51 UTC
> there is no way to resume the current
> transaction from an error callback from rpmlib.

I completely agree. However there is a major problem with the way the
error is currently handled - the error message only talks about the
_new_ package failing to unpack, but the _old_ package also ends up
silently disappearing from the db! 

This bug does not request for up2date to be able to magically recover
from this error (that, of course, would be unreasonable), it just asks
for it to leave the db in consistent state (or at least in a state
would not add a potential security problem - see below) before bailing
out - it needs to retain the record that _some_ version of the package
is still installed.

To reiterate, the problem with the current behaviour is that there is
no record left that the old package is still there --- and because of
it even after the packaging issue is fixed, the old package will not
be updraded without manual intervention. And, of course, leaving old
bytes on the disk (without any record of that in the rpm database)
could be a security risk (hence "severity: security").

TIA for reconsidering the deferral.

Comment 10 Jeff Johnson 2006-01-20 20:07:41 UTC
Changing severity to "normal", red "security" text hurts my eyes.

Comment 11 John Thacker 2006-10-25 19:18:05 UTC
*** Bug 115182 has been marked as a duplicate of this bug. ***

Comment 12 Jeff Johnson 2006-10-25 20:03:57 UTC
The root cause of #115182 is that up2date-gnome crashed, not up2date.

The general problem has been addressed in rpm upstream with auto-rollback.
Packages in a partially installed transaction are automatically replaced, leaving
the rpmdb in the inital state. UPSTREAM.

segfaults need to be fixed in the programs that are segfaulting, which
is up2date and up2date-gnome, not rpm.

Comment 13 Red Hat Bugzilla 2007-02-05 19:18:26 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 14 Panu Matilainen 2007-08-10 09:26:14 UTC
If aborting from middle of transaction (well, callback) hurts, don't do it then
is also one possible answer...
This is pretty up2date-specific and up2date isn't in Fedora anymore, closing.

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