rpm-5.4.10-22.i686 loops forever when installing ntpd-4.2.6p5-5.i686.rpm

[Jeffrey Johnson]

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 at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en