I installed CentOS 3.4 from a CD image I'd burned a while ago, and then attempted to update with yum to 3.7. All the packages installed OK, but at the very end of final cleanup I got an error message from db4 saying to "RUN RECOVERY".
I did "rpm --rebuilddb" which may have been the wrong thing -- it issued an error about "pages missing". I then ran it again, and it came back with no errors, but after rebooting (for the kernel update) "rpm -qa" lists only a dozen packages or so, of which "rpm" is not one, and "yum check-update" chokes, showing Null for $releasever and the empty string for $basearch.
This was a brand-new system, so I'm thinking I'll just download the 3.7 ISOs and re-install, but on the off chance there's some other way to recover from this I thought I'd ask. There doesn't seem to be anything missing other than a large chunk of the RPM database itself.
On Thu, 2006-07-06 at 17:40 -0700, Bart Schaefer wrote:
I installed CentOS 3.4 from a CD image I'd burned a while ago, and then attempted to update with yum to 3.7.
I have done the exact thing form 3.4 to 3.7 w/out issue. Not sure what caused it in this case.
All the packages installed OK, but at the very end of final cleanup I got an error message from db4 saying to "RUN RECOVERY".
I did "rpm --rebuilddb" which may have been the wrong thing -- it issued an error about "pages missing". I then ran it again, and it came back with no errors, but after rebooting (for the kernel update) "rpm -qa" lists only a dozen packages or so, of which "rpm" is not one, and "yum check-update" chokes, showing Null for $releasever and the empty string for $basearch.
I would try reinstalling CentOS-release and see how that goes.
This was a brand-new system, so I'm thinking I'll just download the 3.7 ISOs and re-install, but on the off chance there's some other way to recover from this I thought I'd ask. There doesn't seem to be anything missing other than a large chunk of the RPM database itself.
You can try rebuilding the database again ... and then if there are any other issues, I would just reinstall 3.7.
On Thu, Jul 06, 2006 at 05:40:10PM -0700, Bart Schaefer enlightened us:
I installed CentOS 3.4 from a CD image I'd burned a while ago, and then attempted to update with yum to 3.7. All the packages installed OK, but at the very end of final cleanup I got an error message from db4 saying to "RUN RECOVERY".
I did "rpm --rebuilddb" which may have been the wrong thing -- it issued an error about "pages missing". I then ran it again, and it came back with no errors, but after rebooting (for the kernel update) "rpm -qa" lists only a dozen packages or so, of which "rpm" is not one, and "yum check-update" chokes, showing Null for $releasever and the empty string for $basearch.
This was a brand-new system, so I'm thinking I'll just download the 3.7 ISOs and re-install, but on the off chance there's some other way to recover from this I thought I'd ask. There doesn't seem to be anything missing other than a large chunk of the RPM database itself.
Coincidentally, there is a thread regarding this happening right now over on the nahant mailing list:
https://www.redhat.com/archives/nahant-list/2006-July/msg00011.html
Matt
On Fri, 2006-07-07 at 07:13 -0400, Matt Hyclak wrote:
On Thu, Jul 06, 2006 at 05:40:10PM -0700, Bart Schaefer enlightened us:
<snip>
I got an error message from db4 saying to "RUN RECOVERY".
I did "rpm --rebuilddb" which may have been the wrong thing -- it issued an error about "pages missing". I then ran it again, and it came back with no errors, but after rebooting (for the kernel update) "rpm -qa" lists only a dozen packages or so, of which "rpm" is not one, and "yum check-update" chokes, showing Null for $releasever and the empty string for $basearch.
This was a brand-new system, so I'm thinking I'll just download the 3.7 ISOs and re-install, but on the off chance there's some other way to recover from this I thought I'd ask. There doesn't seem to be anything missing other than a large chunk of the RPM database itself.
Coincidentally, there is a thread regarding this happening right now over on the nahant mailing list:
https://www.redhat.com/archives/nahant-list/2006-July/msg00011.html
Having been around (but nevertheless still ignorant of RPM) when RPM suffered the indignity of having its DBM upgraded, I have been creating three yum-based lists in /var after each update. The one which I think I love the most is the installed list. However, my ardor may be misplaced due to my relative ignorance about these things. My thinking is that I can use that list, with a small amount of scripting and/or manual editing, to recover the rpmdb if I need to. I could also make a list from RPM itself, but I like the "trust but verify" philosophy that is satisfied by getting a list from a different source (hmmm... is *that* source trustworthy? ;-).
Anyway, all that presumes that recovery from my periodic backups are not reasonable for some reason.
My question: am I missing the mark? Should I really be doing a list only from RPM or is the YUM list (suf/de)ficient?
Matt
TIA
On Fri, Jul 07, 2006 at 09:08:42AM -0400, William L. Maltby enlightened us:
Having been around (but nevertheless still ignorant of RPM) when RPM suffered the indignity of having its DBM upgraded, I have been creating three yum-based lists in /var after each update. The one which I think I love the most is the installed list. However, my ardor may be misplaced due to my relative ignorance about these things. My thinking is that I can use that list, with a small amount of scripting and/or manual editing, to recover the rpmdb if I need to. I could also make a list from RPM itself, but I like the "trust but verify" philosophy that is satisfied by getting a list from a different source (hmmm... is *that* source trustworthy? ;-).
Creating the lists is an excellent idea.
Anyway, all that presumes that recovery from my periodic backups are not reasonable for some reason.
My question: am I missing the mark? Should I really be doing a list only from RPM or is the YUM list (suf/de)ficient?
It's the same list. Yum is merely an interface/dependency resolver on top of the RPM database.
Matt
On Fri, 2006-07-07 at 09:15 -0400, Matt Hyclak wrote:
On Fri, Jul 07, 2006 at 09:08:42AM -0400, William L. Maltby enlightened us:
<snip>
... been creating three yum-based lists in /var after each update. The one which I think I love the most is the installed list. However, my
ardor may be misplaced
due to my relative ignorance about these things. My thinking is that I can use that list, with a small amount of scripting and/or manual editing, to recover the rpmdb if I need to. I could also make a list from RPM itself, but I like the "trust but verify" philosophy that is satisfied by getting a list from a different source (hmmm... is *that* source trustworthy? ;-).
Creating the lists is an excellent idea.
Anyway, all that presumes that recovery from my periodic backups are not reasonable for some reason.
My question: am I missing the mark? Should I really be doing a list only from RPM or is the YUM list (suf/de)ficient?
It's the same list. Yum is merely an interface/dependency resolver on top of the RPM database.
Matt
On Fri, 2006-07-07 at 09:15 -0400, Matt Hyclak wrote:
On Fri, Jul 07, 2006 at 09:08:42AM -0400, William L. Maltby enlightened us:
<snip>
Sorry! Forgot what software I was using and sent a previous partially constructed post!
... I have been creating three yum-based lists in /var after each update. The one which I think I love the most is the installed list. ... can use that list, ... to recover the rpmdb if I need to. <snip>
Creating the lists is an excellent idea.
Anyway, all that presumes that recovery from my periodic backups are not reasonable for some reason.
My question: am I missing the mark? Should I really be doing a list only from RPM or is the YUM list (suf/de)ficient?
It's the same list. Yum is merely an interface/dependency resolver on top of the RPM database.
Thanks. That gives me a tad more confidence I'm "Doing The Right Thing" (TM). As the last step of the list creations, there is a diff run between the previous and new list version. Any major unexpected change will (hopefully) catch DB destruction right then and prevent my on-going blissful ignorance morphing into angst.
It also serves to verify that what I think I saw in interactive feedback during the YUM RUN (alliteration alert!) was really what I saw.
Matt
Thanks again.
On Thu, 6 Jul 2006, Bart Schaefer wrote:
I installed CentOS 3.4 from a CD image I'd burned a while ago, and then attempted to update with yum to 3.7. All the packages installed OK, but at the very end of final cleanup I got an error message from db4 saying to "RUN RECOVERY".
I did "rpm --rebuilddb" which may have been the wrong thing -- it issued an error about "pages missing". I then ran it again, and it came back with no errors, but after rebooting (for the kernel update) "rpm -qa" lists only a dozen packages or so, of which "rpm" is not one, and "yum check-update" chokes, showing Null for $releasever and the empty string for $basearch.
Never, ever do "rpm --rebuilddb" with the __db.* files in place. First remove the __db* files then see if that fixes your problem.
If you have to run "rpm --rebuilddb", make sure you remove the __db.* files first otherwise this will most likely corrupt your database (especially when the __db* files are the cause of your problems).
If you happen to have cache-corruption again, always make a copy of /var/lib/rpm, because rpm in that case thinks it has fixed the problem while it made it worse and does not leave a directory behind.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
-
Bart Schaefer -
Dag Wieers -
Johnny Hughes -
Matt Hyclak -
William L. Maltby