Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: After upgrading to Fedora 29 (using gnome-software), many of these are logged: Nov ... HOST packagekitd[20189]: error: rpmdbNextIterator: skipping h# 5917 tag[34]: BAD, tag 1096 type 5 offset 36008 count 564 len 2256 Nov ... HOST plasmashell[5646]: PK error: "Failed to load system repo: failed loading RPMDB" type: "invalid-package-file" The first message is shown when running dnf or rpm commands: # rpm -qa | grep -i oracle oracle-xe-11.2.0-1.0.x86_64 error: rpmdbNextIterator: skipping h# 5917 tag[34]: BAD, tag 1096 type 5 offset 36008 count 564 len 2256 Version-Release number of selected component (if applicable): dnf-4.0.4-2.fc29.noarch Actual results: RPM db appears to be damaged after upgrade. Expected results: An upgrade should not damage anything. Additional info: The computer was never powered off without shutting it down first. The (KDE) session is sometimes lost for some unknown reason, though rarely (after resuming; most recently after simply locking and unlocking the screen). Since KDE is once again showing dozens of identical popups ("failed loading RPMDB"), I have created a screenshot and added it to Bug 1316705, which is where I complain about KDE filling my screen with identical popups.
For the record, I have now attempted to repair the database: # rpm --rebuilddb error: rpmdbNextIterator: skipping h# 5917 tag[34]: BAD, tag 1096 type 5 offset 36008 count 564 len 2256 But even if that fixes the symptoms, it can't be right that a release upgrade damages the rpmdb.
Sounds like something going wrong in rpm.
It's unlikely that the actual upgrade did anything, there's an invalid header in the rpmdb that would've probably been undetected by rpm < 4.14.2. What Fedora version did you upgrade from? More importantly, do you have a backup of the rpmdb prior to doing --rebuilddb which will have thrown away the invalid header? Without that, it's going to be impossible to say what the invalid package was and why it might be that way.
I had Fedora 28, from which I upgraded to 29. I did not skip a release if that's what you mean. No, unless Fedora creates backups of the rpmdb on its own by default, I don't have any. I asked on IRC and I was advised to try --rebuilddb. If there's something in the logs I should look for, I'd be happy to do so. Are you saying there was something wrong with a package all along but the version of rpm included in Fedora 28- didn't detect that problem?
(In reply to Basic Six from comment #4) > No, unless Fedora creates backups of the rpmdb on its own by default, I > don't have any. I asked on IRC and I was advised to try --rebuilddb. > Okay, then there's not going to be anything we can do about it. For the future, it's always a good idea to take a backup prior to attempting repair, and that's not at all limited to the rpmdb. That way if something goes wrong you can always try again, and provide more data to developers if it the situation requires it. > If there's something in the logs I should look for, I'd be happy to do so. If you happen to have rpm-cron installed, then /var/log/rpmpkgs* prior to the --rebuilddb would have the package name (but finding it might prove hard). > Are you saying there was something wrong with a package all along but the > version of rpm included in Fedora 28- didn't detect that problem? That's what it looks like, but with the data gone, we can only guess. Tag 1096 is RPMTAG_FILEINODES, and it's supposed to be 32bit integer (type 5) but in that mystery package it was a 64bit int. No idea what exactly might happen but it's not a good thing. Such a package would've almost certainly come from outside Fedora, so there's one clue as to what it might be. The problem here is that after the rebuild, the item will be gone from the rpmdb but remain on disk, so there's no way to tell exactly, but it's also a possible clue where to hunt. I'm going to have to close this because there's just not enough info to do anything at all about it. Since it's from a package you had installed, chances are you'll come across it again sooner or later. If/when that happens, feel free to reopen for investigation. Even if it turns out to be just an invalid package, it'd be good to know where it came from.
Erm, should've been: Tag 1096 is RPMTAG_FILEINODES, and it's supposed to be 32bit integer (type 4) but in that mystery package it was a 64bit int (type 5).