Bug 118029
Summary: | "fatal RPM install error" corrupts the database: removes old packages w/o installing new ones! | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Aleksey Nogin <aleksey> | ||||
Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> | ||||
Status: | CLOSED CANTFIX | QA Contact: | Mike McLean <mikem> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | alikins | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-08-10 09:26:14 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: | |||||||
Attachments: |
|
Description
Aleksey Nogin
2004-03-11 10:07:26 UTC
Created attachment 98453 [details]
Full output of that up2date session.
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. 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 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. This was fixed in tk-8.4.5-6. *** This bug has been marked as a duplicate of 118030 *** Sorry, Aleksey, I didn't read comment 4 properly: reopening. the transaction behaviour in lieu of bad packages like that tk package is an rpm issue, reassigning there. 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. > 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.
Changing severity to "normal", red "security" text hurts my eyes. *** Bug 115182 has been marked as a duplicate of this bug. *** 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. REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred. 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. |