(This bug occurred with RH 7.3 gold). I upgraded from RH 7.2 to RH 7.3. The upgrade appeared to go okay, and it put new RH 7.3 RPMs on the system, but the RPM database only lists the old 7.2 RPMs (which aren't even installed any more): For example: [root@zummers root]# uname -a Linux zummers.gatech.edu 2.4.18-3smp #1 SMP Thu Apr 18 07:27:31 EDT 2002 i686 unknown [root@zummers root]# rpm -qa | grep kernel kernel-headers-2.4.9-13 kernel-source-2.4.9-13 kernel-smp-2.4.9-13 [root@zummers root]# grep kernel-smp upgrade.log Upgrading kernel-smp-2.4.18-3. [root@zummers root]# kernel-2.4.18-3smp installed, and it's what I'm running, but the db only shows the 2.4.9-13 kernels from 7.2. The same is true for all packages. I have kde3 installed and running, but rpm -qa | grep kde only shows kde2.2 packages, for example. There were some failed %post scripts in upgrade.log: execution of %post scriptlet from rpm-devel-4.0.4-7x.18 failed, exit status 0 execution of %post scriptlet from newt-devel-0.50.35-1 failed, exit status 0 execution of %post scriptlet from texinfo-4.1-1 failed, exit status 0 execution of %post scriptlet from kernel-source-2.4.18-3 failed, exit status 0 execution of %post scriptlet from kdetoys-3.0.0-3 failed, exit status 0 execution of %post scriptlet from xboard-4.2.3-2 failed, exit status 0 execution of %post scriptlet from db3x-3.2.9-4 failed, exit status 0 execution of %post scriptlet from g-wrap-1.2.1-4 failed, exit status 0 execution of %post scriptlet from g-wrap-devel-1.2.1-4 failed, exit status 0 execution of %post scriptlet from gimp-print-cups-4.2.0-9 failed, exit status 0 execution of %post scriptlet from glibc-utils-2.2.5-34 failed, exit status 0 execution of %post scriptlet from glut-3.7-4 failed, exit status 0 execution of %post scriptlet from gnucash-1.6.6-3 failed, exit status 0 execution of %post scriptlet from imap-2001a-10 failed, exit status 0 execution of %post scriptlet from kdebindings-3.0.0-1 failed, exit status 0 execution of %post scriptlet from libgal7-0.8-7 failed, exit status 0 execution of %post scriptlet from libgcj-2.96-29 failed, exit status 0 execution of %post scriptlet from mysql-3.23.49-3 failed, exit status 0 execution of %post scriptlet from nasm-0.98.22-2 failed, exit status 0 execution of %post scriptlet from pdksh-5.2.14-16 failed, exit status 0 execution of %post scriptlet from php-dbg-4.1.2-7 failed, exit status 0 execution of %post scriptlet from postgresql-odbc-7.2.1-5 failed, exit status 0 execution of %post scriptlet from qt-Xt-3.0.3-11 failed, exit status 0 execution of %post scriptlet from recode-3.6-4 failed, exit status 0 execution of %post scriptlet from rwho-0.17-11 failed, exit status 0 execution of %post scriptlet from unixODBC-kde-2.2.0-5 failed, exit status 0 execution of %post scriptlet from WindowMaker-libs-0.80.0-9 failed, exit status 0 execution of %post scriptlet from WindowMaker-0.80.0-9 failed, exit status 0 execution of %post scriptlet from xemacs-info-21.4.6-7 failed, exit status 0 execution of %post scriptlet from XFree86-truetype-fonts-4.2.0-8 failed, exit status 0 execution of %post scriptlet from xsane-gimp-0.84-2 failed, exit status 0 but other than that, no errors....
DId you install from CD? Did you mediacheck? It looks like your upgrade failed due to read errors.
Upgrade was from ISO images on the local (ext3) hard drive. All images have the correct md5sums: [root@zummers iso]# md5sum *.iso cb91810ce8173039fed24420407e4c59 Valhalla-i386-disc1.iso ec1b813d32ffdc8edc2be261735d17de Valhalla-i386-disc2.iso 5dc81ce523cfddf99b4d4d63e91bcaa7 Valhalla-i386-disc3.iso c9a4d963a49e384e10dec9c2bd49ad73 Valhalla-i386-disc4.iso 41b03d068e84d2a17147aa27e704f79b Valhalla-i386-disc5.iso 58caad7d93b06c1c0e2af1ce2111a4ae docs-7.3-i386.iso b5e24c1043cc190a0fe8a6fa559e7842 lacd-7.3-Productivity.iso 67779193951f92b887f98d9305c39d12 lacd-7.3-Server.iso c13f08b5b52d6a8f7a27edeb3287ebe8 rescue-cd-7.3.iso [root@zummers iso]# Furthermore, the upgrade doesn't exactly fail -- it puts the new software on the system, so it's able to read the sources just fine. It just fails to update /var/lib/rpm/* after it puts the new software on the system.
Understood. Its just not normal to see all those scriplets fail. It would be more interesting I think to first understand what thats all about.
If it helps any, rpm itself seems to work fine now: [kaboom@zummers i386]$ rpm -qa | grep p0f [kaboom@zummers i386]$ sudo rpm -Uvh p0f-1.8.2-0.i386.rpm Preparing... ########################################### [100%] 1:p0f ########################################### [100%] [kaboom@zummers i386]$ rpm -qa | grep p0f p0f-1.8.2-0 [kaboom@zummers i386]$ sudo rpm -e p0f [kaboom@zummers i386]$ rpm -qa | grep p0f [kaboom@zummers i386]$
And rpm upgrades work fine too: [kaboom@zummers i386]$ rpm -q p0f p0f-1.8.2-0 [kaboom@zummers i386]$ sudo rpm -Uvh p0f-1.8.2-2.i386.rpm Preparing... ########################################### [100%] 1:p0f ########################################### [100%] [kaboom@zummers i386]$ rpm -q p0f p0f-1.8.2-2 [kaboom@zummers i386]$ sudo rpm -Uvh p0f-1.8.3-1.i386.rpm Preparing... ########################################### [100%] 1:p0f ########################################### [100%] [kaboom@zummers i386]$ rpm -q p0f p0f-1.8.3-1 [kaboom@zummers i386]$
Whatever made the scripts fail does not fail now: [kaboom@zummers i386]$ sudo rpm -e xboard [kaboom@zummers i386]$ sudo rpm -Uvh /export/valhalla/i386/RedHat/RPMS/xboard-4.2.3-2.i386.rpm Preparing... ########################################### [100%] 1:xboard ########################################### [100%] [kaboom@zummers i386]$ Furthermore, the post scripts which failed are not all the same. Some (rpm-devel, for example) just run ldconfig, while others (xboard) are doing info nonsense.
Do you have the new rpmdb in /var/lib/anaconda-rebuilddb?
Yep. Want me to tar it up and attach it?
No, I was trying to make sure it's actually there.. the only way I can see the database not failing is if the move failed, but even that should have triggered an exception. Is /var low on disk space or anything of the like?
The backup it made was /var/lib/anaconda-rebuilddb1020349424 /var had something like 400 megs free at the time, so it wasn't a space issue
Don't know what caused it, but since a lot of the upgrade code has been rewritten for Milan, it should be fine now
kaboom, have you been able to replicate this? Could you try with the Null beta?
I can't try anything on there right now -- the box is in production. If null goes gold before the semester starts, I'll try an upgrade from 7.3 to null and see what happens.... My guess is that this isn't worth worrying about too much -- I've never seen this in upgrading any other machines from 7.2 to 7.3, so its probably a race that's specific to the exact cpu / mem combination in the machine or something similar. If upgrading to 8 from 7.3 works, I'll close it as fixed current.
I'm going to go ahead and close this. Reopen if you have the same problems with the next release.