Doing --rebuilddb during boot doesn't even begin to touch the problem
of a versioned dbenv. What could _EASILY_ be done is add
rm -f /var/lib/rpm/__db*
(or equivalently, will "work" with "RPM ACID")
cd /var/lib/rpm
/usr/lib/rpm/bin/db_recover -ev
to the boot sequence.
The time needed is nothing close to +30 seconds claimed in the bug report:
root@rhel6 rpm]# /usr/bin/time /usr/lib/rpm/bin/db_recover -ev
Finding last valid log LSN: file: 57 offset 5054704
Recovery starting from [57][5052350]
Recovery complete at Thu Oct 7 17:02:43 2010
Maximum transaction ID 800008ef Recovery checkpoint [57][5056958]
0.00user 0.25system 0:00.80elapsed 33%CPU (0avgtext+0avgdata 33296maxresident)k
8472inputs+19576outputs (24major+2135minor)pagefaults 0swaps
[root@rhel6 rpm]# uname -a
Linux rhel6 2.6.32-19.el6.i686 #1 SMP Tue Mar 9 18:10:40 EST 2010 i686 i686 i386 GNU/Linux
And because the command is being run while booting, the behavior is
_NOT_ racy in any fashion whatsoever.
Doing --rebuilddb during boot doesn't even begin to touch the problem lib/rpm/ bin/db_ recover -ev
of a versioned dbenv. What could _EASILY_ be done is add
rm -f /var/lib/rpm/__db*
(or equivalently, will "work" with "RPM ACID")
cd /var/lib/rpm
/usr/
to the boot sequence.
The time needed is nothing close to +30 seconds claimed in the bug report:
root@rhel6 rpm]# /usr/bin/time /usr/lib/ rpm/bin/ db_recover -ev 19576outputs (24major+ 2135minor) pagefaults 0swaps
Finding last valid log LSN: file: 57 offset 5054704
Recovery starting from [57][5052350]
Recovery complete at Thu Oct 7 17:02:43 2010
Maximum transaction ID 800008ef Recovery checkpoint [57][5056958]
0.00user 0.25system 0:00.80elapsed 33%CPU (0avgtext+0avgdata 33296maxresident)k
8472inputs+
[root@rhel6 rpm]# uname -a
Linux rhel6 2.6.32-19.el6.i686 #1 SMP Tue Mar 9 18:10:40 EST 2010 i686 i686 i386 GNU/Linux
And because the command is being run while booting, the behavior is
_NOT_ racy in any fashion whatsoever.