On Oct 22, 2012, at 2:57 PM, Elan Ruusamäe wrote:
> On 10/22/2012 05:58 PM, Jeffrey Johnson wrote:
>> For a suspected database error in the Conflictname index,
>> then comparing the outputs with
>>
>> /usr/lib/rpm/macros:%_dbi_config_3_Conflictname %{_dbi_btconfig}
>> %{?_bt_dupsort} debug
>>
>> may be informative. The access patterns SHOULD be similar.
> first one that loops, second one that finishes fine
>
> $ rpm -D '_dbi_config_3_Conflictname %{_dbi_btconfig} %{?_bt_dupsort}
> debug' -ihv ntpd-4.2.6p5-5.i686.rpm --test
> 2>ntpd-conflictdb-debug-morpheus.txt
> ^C
>
> -> 6.3M
> http://carme.pld-linux.org/~glen/ntpd-conflictdb-debug-morpheus.txt
>
> $ rpm -D '_dbi_config_3_Conflictname %{_dbi_btconfig} %{?_bt_dupsort}
> debug' -ihv ntpd-4.2.6p5-5.i686.rpm --test 2>ntpd-conflictdb-debug-carme.txt
> Preparing... ########################################### [100%]
> $
>
> -> 19K
> http://carme.pld-linux.org/~glen/ntpd-conflictdb-debug-carme.txt
>
Thank you for details, I will study carefully.
What I see in 2minutes of looking is that RPM is _NOT_ proceeding to
file path resolutions in the looping/erroneous sewage (but I've just scanned
through
the top of the 6.3M file: I will study in a moment).
> anyway, assuming local db problem, what are my next steps?
The next practical steps are:
1) run
dbXY_recover -v
(which destroys __db* files as well as replaying logs). Then do
dbXY_recover -ev
(XY == 53 for PLD iirc)
2) rebuild just the Conflictname index. This SHOULD work (but untested).
cd /var/lib/rpm
mv Conflictname Conflictname-SAVE
rpm -qa --qf '%{CONFLICTS}\n"
ls -al Con*
3) rebuild all the indices. Easiest is likely to remove the LSN log sequence
numbers) and copy
Packages DB_CONFIG to new /var/lib/rpm (you will also need ./log and ./tmp
subdirs if mentioned in DB_CONFIG)
You remove the log indices using (yes, obscurely, talk to Sunacle, not me)
cd /var/lib/rpm
dbXY_ load -r lsn Packages
before copying Packages to another directory.
*THEN* you run rpm -vv --rebuilddb to regenerate the indices.
Note the above process is quite useful if/when preparing livecd's. Go find
mdawkins
on IRC who has produced one of the better/smaller lived images for Unity Linux
(starting
with Mandriva bloaty packages). Its the same procecss to produce a small livecd
image
as it is to re-create an rpmdb.
The next level is bisection of the packages in the rpmdb, removing (with
--justdb)
entries until the upgrade "works", and then re-adding (with --justdb) packages
until
the problem re-occurs (which probably won't happen: lots of heisenbugs
associated
with local rpmdb issues whose root cause is data/state dependent).
The next level after that is point me at a tar ball of the _ENTIRE_ (including
logs etc),
which will be moderately large, and I'll try to do forensics (on a RHEL machine
which is
rather hard to explain and may not lead to any valid diagnosis/repair). But I
haven't
seen an rpmdb that I couldn't "fix" though the results often involve
catastrophic data loss.
> i heard rpm --rebuilddb is big no in rpm5, so what do i do to recover?
>
Not a big no, just everyone is used to --rebuildb as a cure-all for any/every
possible
issue rather than actually trying to understand the root causes.
The --rebuilddb option has _ALWAYS_ rebuilt indices. And @rpm5.org with ACID
logs can actually repair damage that --rebuilddb (and rebuilding indices) never
could
touch.
Short answer (if you are not hearing what I am saying):
Yes --rebuilddb is a "… big no in rpm5."
Seldom helps and there are a few pathological cases where --rebuilddb actually
hurts (and this has _ALWAYS_ been true, this isn't anything new @rpm5.org).
Mail privately if you want, its silly to fix an rpmdb issue on a public mailing
list,
always has been tedious and boring, and archives aren't much help to others
because one really needs to look at the details carefully.
> --
> glen
>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
