On 27 Mar 2010, at 22:01, Solar Designer wrote: > On Thu, Mar 25, 2010 at 12:28:35PM +0000, Simon Baker wrote: >> ... there's probably not much point in you guys trying to track it >> down > > Yet I researched the issue some further. It appears to be quite > normal > that the expected file format of /var/lib/rpm/__db.001 changes when > RPM > built against NPTL is installed on a system that was previously using > RPM built against LinuxThreads. That file is memory-mapped and it > contains mutexes. Unfortunately, RPM does not distinguish this file > format change from it having accessed the file in an inconsistent > state, > so it treats this as a temporary error and keeps retrying with the > confusing message that you saw. > > The workaround is to ensure that there's no rpm process running and to > "rm /var/lib/rpm/__db.00?". There's no need to run "rpm --rebuilddb" > after that, even though this is commonly suggested (cure for a > different > disease). Once the old __db.00? files are removed, RPM works again > (it > silently re-creates the files) and the issue does not re-occur. > > I still have no idea why the workaround didn't appear to work for > Simon. > It could have something to do with the order in which packages were > being rebuilt/upgraded on Simon's system. > > This same error message may appear in many other cases. The above > description pertains to the specific known issue with upgrading an Owl > system to our latest packages (built on March 23). > Hi, Interesting. Thanks for the info. In the end, I managed to fix the issue by simply downloading and running 'make install' with the official RPMS that are on the mirror, and then rebuilding my system once again from source. I've not had any further problems, and rebuilds work exactly as expected. Regards, Simon. -- Simon Baker PGP: BCE47881 https://k.kaizo.org/simonb/
This archive was generated by hypermail 2.2.0 : Mon Mar 29 2010 - 02:15:55 PDT