From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
My kernel crashed in the middle of a yum upgrade, while yum was
installing and upgrading packages.
When I rebooted and run yum upgrade again, it failed with:
--> Finished Dependency Resolution
Error: Missing Dependency: xorg-x11 is needed by package xorg-x11-Xvfb
Error: Missing Dependency: bind is needed by package bind-chroot
Error: Missing Dependency: xorg-x11-devel is needed by package
Error: Missing Dependency: httpd is needed by package httpd-suexec
Error: Missing Dependency: openoffice.org is needed by package
Error: Missing Dependency: kdegraphics is needed by package
Error: Missing Dependency: xorg-x11-deprecated-libs is needed by
The cause of this turns out to be that old packages were left hanging
around in the rpm database - as shown below:
[root@pob ~]# rpm -q xorg-x11-Xvfb bind-chroot
xorg-x11-deprecated-libs-devel httpd-suexec openoffice.org-i18n
I am not sure whether this is actually a bug in rpm or yum, but there
I am rating this as severity High because it is not obvious to a
non-technical user what to do to work around it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: See above
Expected Results: The operations of
1. Removing the old version of a package
2. Installing the new version of a package
should have been part of one single ACID transaction on the rpm
database, so that if a crash or power failure occurs during the
transaction, after a reboot, running yum upgrade again will fix
(The actual files on the filesystem, as opposed to the rpm database,
are probably not transactionally updated, but that doesn't matter so
much because yum upgrade would fix any transient problems caused by a
half-done package upgrade.)
Root filesystem (which contains the rpm database) is ext3
There's nothing yum can do about this. yum doesn't control the
granularity of the process. Yum packs an rpm transaction set and then
runs the transaction. There's no way to make it more or less granular.
and since transactions to your filesystem are not ACID, even if yum
could control access to the rpmdb like that you can't make it all that
I'm reassigning this to rpm, see what Jeff thinks.
yum surely chooses what goes into a transaction, and
the size of the transaction determines how much needs
to be cleaned up.
Meanwhile, an rpmdb has never promised Durability in the face
of execptional events like "kernel crashed while updating".
Sure Durability could be added with apply/commit transactions
to an rpmdb, but adding durability comes at a considerable
maintenance cost for the database, and ultimately does not
solve the real problem, that files can and will be changed
on the file system unpacking payloads no matter whether an
rpmdb has transactional durability support.
So even if rpmlib provided durability, the problem of "kernel
crashing while updating" cannot be solved adequately.
I'd much prefer that yum do one package upgrade per transaction, rather than
packing potentially hundreds into a single transaction. I've had a lot of
problems that would have been much easier to clean up if it was done as many
Even if you don't make this the default behavior, please at least add it as an
This is a yum, not an rpm, problem atm. So back to yum, as rpm ain't about to start providing
Durable db4 transactions tomorrow, or next month.
There's the infrastructure for transaction splitting in yum now -- if you want
smaller transactions, it should be easy enough to write a plugin to break apart
at the appropriate points, but it's not going to be the default.