TR Forums

I stupidly did this today on a Fedora Core 6 box at work, figuring it would clean up after itself.

Nope!

It apparently caused yum's dependency database to go into a totally confused state. Any further attempts to update or install packages via yum resulted in failure, with numerous error messages about conflicting files.

Cross referencing the error messages with the list of installed packages revealed that all of the problem packages had something in common -- yum thought that there were two versions of the package installed! (The original version, and the version that was being installed by the interrupted update.)

Going back and removing all of the problem packages one by one, then reinstalling them (and any other packages which were automatically removed because they depended on the problem packages) seems to have straightened things out.

But jeez... what a PITA.

Oh, and if you're using the LILO bootloader instead of GRUB, automatic kernel updates via yum only sorta halfway work. The lilo.conf file got updated OK, but the updated config never got installed. The system was really flaky until I figured out what was going on (running an old kernel with other packages which expected the updated kernel). I suppose expecting it to work automatically was a bit naive on my part, given that LILO isn't officially supported by Fedora any more.

The Linux adventure continues...

yum is just a layer on top of rpm that handles repositories and resolving dependencies. I'm guessing you should probably be cursing rpm, because it keeps track of installed packages and definitely has well known issues of being very fragile. Underneath rpm they use Berkeley DB to store their package info and it likes to get corrupted if you ever terminate uncleanly.

This is one of the bigger gripes I have with rpm-based distros. You can mitigate the "rpm hell" problems with front-end dependency resolution, but you can't paper over rpm's fragility as easily. Don't build your house on sand.

I found a few people who ran into very similar issues and posted their scripts to fix it: http://readlist.com/lists/redhat.com/fe ... 25455.html
http://www.ivarch.com/personal/blog/200 ... grade.html

Easier than doing it one by one.

Sorry, that sucks... at you got it fixed though. I've had a system where yum ran out of memory while applying a bazillion updates and borked everything, so I can relate. I guess you can partly blame yum for your mess, because it might be possible to lower the damage radius caused by aborting it (i.e. only the package currently being installed will get duplicated, rather than all of them), but I don't know the kind of restrictions imposed by the lower-level rpm interface that it must deal with. It seems like some of these problems may be caused by an impedance mismatch between the interface rpm provides and what the layer above it needs to do.

Looks like there was some discussion on this a few years ago. The way they order the installation transactions is "all new installs" followed by "all old removals" because it was considered the least evil. If you did "install A, remove oldA; install B, remove oldB, ..." you could be left with fewer duplicates, but possibly broken dependencies. One thing I was idly thinking of, which someone on the mailing list also suggested, is doing smaller clusters of dependency related packages interleaved in the "installs; removals" order to minimize damage. The real problem that they can't get perfect transactional semantics is due to the fact that scripts running on preinstall or postinstall may modify files on the filesystem. Seems like you could leverage a snapshotting filesystem to help you out there; unfortunately, supporting lightweight snapshots is only now starting to become a common feature for new filesystems.

Yeah, the reason I killed it in the first place was that it was thrashing the swap partition as a result of my trying to apply a couple hundred updates all at once. Yum seems to be a major resource pig (memory and CPU) if you batch a large number of updates; I suspect there may be an algorithm in there somewhere that is exponential in memory usage and/or CPU cycles. At the rate it was going, it would've been running for hours.

After cleaning up the dependency database mess, I re-ran the updates in smaller batches (couple dozen updates per batch). At least the package wildcarding made it relatively easy to batch the updates in manageable chunks from the command line (I'd already given up on using the GUI interface to Fedora's package management system anyhow, so I'm pretty comfortable with the yum CLI).

I wonder if apt-rpm is any better than yum... probably not, since it's not the primary package management system on Fedora (so probably receives less attention), and it's still layered on top of RPM in any case.

just brew it! wrote:

I wonder if apt-rpm is any better than yum... probably not, since it's not the primary package management system on Fedora (so probably receives less attention), and it's still layered on top of RPM in any case.

I don't know if it's any better (though I believe it's faster and less memory hungry), but regardless, yum has stolen apt-rpm's thunder since RedHat is now fully behind yum. I think yum will get better now that RedHat dropped up2date in favor of yum for RHEL 5. Also, RPM will probably get better now too since the RPM "ownership" controversy has been settled. It was basically rotting for three or so years while the longtime maintainer (Jeff Johnson) was like an anti-Pope with his fork that was unrecognized as official by the major rpm distros. The LWN article "Who maintains RPM?" is pretty amusing.

Thanks for the link; I was aware that there was some major politics surrounding the status of rpm, but hadn't bothered to look into it until now. WTF was Redhat thinking? They really ought to have had a strategy in place for moving forward (or at least put one together ASAP) when they fired the maintainer.

It looks like FC6 is in fact using one of the more recent versions (4.4.2.1)... and Fedora 8 is using a yet newer version, 4.4.2.2. The release notes for 4.4.2.2 appear to include quite a few bug fixes.

I'd been planning to migrate to Fedora 8 anyhow. (It seems that I only do the even numbered versions -- I've used 4 and 6, but skipped 5 and 7.)

just brew it! wrote:

Oh, and if you're using the LILO bootloader instead of GRUB, automatic kernel updates via yum only sorta halfway work. The lilo.conf file got updated OK, but the updated config never got installed. The system was really flaky until I figured out what was going on (running an old kernel with other packages which expected the updated kernel). I suppose expecting it to work automatically was a bit naive on my part, given that LILO isn't officially supported by Fedora any more.

The Linux adventure continues...

Beats the behavior of ubuntu on my system. It overwrites the old config with a new one that points at the wrong disk whenever I install a kernel update package.

On a sidenote, that whole rpm kerfuffle is pretty shockingly awful. What a rotten foundation.

Oh, and the reason I was using LILO in the first place was that there's some sort of weird incompatibility between GRUB and the motherboard BIOS on that system, which causes GRUB to fail...

mattsteg wrote:

Beats the behavior of ubuntu on my system. It overwrites the old config with a new one that points at the wrong disk whenever I install a kernel update package.

Is this with lilo or grub?

bitvector wrote:

mattsteg wrote:

Beats the behavior of ubuntu on my system. It overwrites the old config with a new one that points at the wrong disk whenever I install a kernel update package.

Is this with lilo or grub?

grub.

Well, you've probably looked at these, but that should be entirely controlled by the automatic comments in menu.lst:

Those are what get propagated to the managed kernel lists every time update-grub runs (which is on every kernel update). The groot and kopt values shouldn't be touched unless they are missing or malformed. Apparently removing the space between the # and the start of the option will cause the script to miss them and regenerate the values (or extra spaces, or adding another # or removing it, etc.).

just brew it! wrote:

Thanks for the link; I was aware that there was some major politics surrounding the status of rpm, but hadn't bothered to look into it until now. WTF was Redhat thinking? They really ought to have had a strategy in place for moving forward (or at least put one together ASAP) when they fired the maintainer.

It looks like FC6 is in fact using one of the more recent versions (4.4.2.1)... and Fedora 8 is using a yet newer version, 4.4.2.2. The release notes for 4.4.2.2 appear to include quite a few bug fixes.

I'd been planning to migrate to Fedora 8 anyhow. (It seems that I only do the even numbered versions -- I've used 4 and 6, but skipped 5 and 7.)

When I tried out 8, I still found Yum to be quite slow and resource intensive. They changed quite a bit from 7 to 8, Ubuntu was still noticeably faster. I'll probably give 8 another chance since I don't have anything critical on the L-BoX yet, but I'm more skeptical now that I've managed to try out two of the bigger names successfully.

lex-ington wrote:

When I tried out 8, I still found Yum to be quite slow and resource intensive. They changed quite a bit from 7 to 8, Ubuntu was still noticeably faster. I'll probably give 8 another chance since I don't have anything critical on the L-BoX yet, but I'm more skeptical now that I've managed to try out two of the bigger names successfully.

My continued use of Fedora is more due to inertia than anything... my first Linux system was a Redhat 8 box, so I'm already familiar with many of Redhat/Fedora's quirks. I also think it's kinda cool that Linus Torvalds uses Fedora (yeah I know, that's actually a silly reason for me to stick with it... sort of like if someone upgrades to Vista "because Bill Gates says uses it"... oh well).

Anyhow, back on topic -- another significant contributor to the sluggishness of yum on Fedora seems to be the remote repositories it is configured to use by default. I've been dealing with this by maintaining my own local Fedora rsync mirror, and pointing yum at a local copy of the repositories. At work, I've got the mirrored repository exported on the LAN via HTTP, so anyone else in the office can grab all of the updates without having to pull everything over the Internet.