Bug 4918 - The RPM DB cannot be opened
: The RPM DB cannot be opened
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: RPM Packages
: Cauldron
: All Linux
: Normal Severity: normal
: ---
Assigned To: Mageia Bug Squad
:
:
:
: NEEDINFO
:
:
  Show dependency treegraph
 
Reported: 2012-03-13 00:15 CET by Frédéric Buclin
Modified: 2013-05-11 12:49 CEST (History)
30 users (show)

See Also:
Source RPM: perl rpmdrake
CVE:


Attachments
Error message according to steps in comment 25 (30.70 KB, text/plain)
2012-03-14 09:12 CET, Chih Wei Yao
Details
Test (3.13 KB, text/plain)
2012-03-14 11:04 CET, Jacques Pronchery
Details
Second test (4.41 KB, text/plain)
2012-03-14 11:28 CET, Jacques Pronchery
Details
Test n° 3 (3.19 KB, text/plain)
2012-03-14 11:48 CET, Jacques Pronchery
Details
Test n°4 (4.20 KB, text/plain)
2012-03-14 12:01 CET, Jacques Pronchery
Details
temporary disable flushing every second (535 bytes, application/octet-stream)
2012-03-14 12:23 CET, Thierry Vignaud
Details
Test with the patch (6.49 KB, text/plain)
2012-03-14 14:14 CET, Jacques Pronchery
Details

Description Frédéric Buclin 2012-03-13 00:15:40 CET
Trying to execute rpmdrake throws: Couldn't open RPM DB () at Rpmdrake/open_db.pm line 74. In the shell, I see:

erreur: rpmdb: Thread/process 9744/3074553536 failed: Thread died in Berkeley DB library
erreur: erreur db4(-30974) de dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
erreur: ne peut ouvrir l'index Packages en utilisant db4 -  (-30974)
erreur: impossible d'ouvrir la base de données Package dans /var/lib/rpm


This is the first time I see this error. Maybe the new RPM broke it.
Comment 1 Chih Wei Yao 2012-03-13 05:20:11 CET
I got the same problem after today's update, the error is the same 

錯誤:rpmdb: Thread/process 15254/139841958962944 failed: Thread died in Berkeley DB library
錯誤:資料庫4 錯誤(-30974) 來自 dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
錯誤:無法使用資料庫 4- (-30974) 開啟 Packages 索引
錯誤:無法開啟套件資料庫 /var/lib/rpm
無法開啟 rpmdb


Which means rpmdb is broken and cannot be read. Any clue?
Comment 2 Rémi Verschelde 2012-03-13 09:31:00 CET
I get the same error too in Cauldron 32 bits, using urpmi.
When I try with mageiaupdate, I get:
« Une erreur fatale est survenue : Couldn't open RPM DB () at /usr/lib/perl5/vendor_perl/5.14.2/Rpmdrake/open_db.pm line 74. . »

The fact is, I don't find the Rpmdrake subdirectory in /usr/lib/perl5/vendor_perl/5.14.2/
Comment 3 Thierry Vignaud 2012-03-13 12:08:58 CET
I'll backport a fix from RH
Comment 4 Remco Rijnders 2012-03-13 12:56:06 CET
*** Bug 4924 has been marked as a duplicate of this bug. ***
Comment 5 Thierry Vignaud 2012-03-13 13:17:12 CET
I've backported RH fixes into rpm-4.9.1.2-21.mga2
You'll need to cleanup your rpmdb though:

rm -f /var/lib/rpm/_*
rpm --rebuilddb
Comment 6 Frédéric Buclin 2012-03-13 13:36:33 CET
(In reply to comment #5)
> I've backported RH fixes into rpm-4.9.1.2-21.mga2

rpmdrake complains that the new rpm packages aren't signed. Is it safe to install them anyway?

Les paquetages suivants ont des signatures non valides:
/var/cache/urpmi/rpms/librpm2-4.9.1.2-21.mga2.i586.rpm: Signature absente (OK ((none)))
/var/cache/urpmi/rpms/python-rpm-4.9.1.2-21.mga2.i586.rpm: Signature absente (OK ((none)))
/var/cache/urpmi/rpms/rpm-4.9.1.2-21.mga2.i586.rpm: Signature absente (OK ((none)))
Comment 7 Thierry Vignaud 2012-03-13 13:41:59 CET
@pascal: That's a build system (BS) issue.

@frédéric: yes
Comment 8 Chih Wei Yao 2012-03-13 13:48:49 CET
Confirm Fixed, Should I mark it as resolved?
Comment 9 Frédéric Buclin 2012-03-13 14:01:55 CET
Looks like something went wrong. I installed the packages mentioned in comment 6 despite they had no signature, as Thierry said this was safe, but now I get:

Afin de poursuivre la mise à jour, les paquetages suivants doivent être désinstallés :
python-rpm-4.9.1.2-21.mga2.i586
 (pour installer le paquetage python-rpm-4.9.1.2-21.mga2.i586)
rpm-4.9.1.2-21.mga2.i586
 (pour installer le paquetage rpm-4.9.1.2-21.mga2.i586) (o/N) o
...
L'installation a échoué :
    paquetage rpm-1:4.9.1.2-21.mga2.i586 déjà installé
    paquetage python-rpm-1:4.9.1.2-21.mga2.i586 déjà installé

Why does it ask to install already installed packages?? Because they have no signature?
Comment 10 Pascal Terjan 2012-03-13 14:11:41 CET
Hmm the script calls RPM4::Sign->new and then outside script checks with "rpmsign -Kv "$tmpfile" 2>&1 | grep BAD" as we got bad signatures in the past.

We should probably also grep Signature to be sure that a signature was actually added...

Or fix the code adding signature so that we don't need to try several times...

Only recent failure is gnucash-ofx-2.4.10-3.mga2.x86_64.rpm where it had to try at least 7 times (it only keeps one per second due to the file naming, I'll change that, there is no point in keeping them all anyway).
Comment 11 Thierry Vignaud 2012-03-13 14:36:11 CET
(In reply to comment #9)
> Looks like something went wrong. I installed the packages mentioned in comment
> 6 despite they had no signature, as Thierry said this was safe, but now I get:

Frédéric: can you send to me by email the ~/bug1.tar.xz tarball resulting from:
urpmi --auto-select --bug ~/bug1
tar cfa ~/bug1{.tar.xz,}
Comment 12 Pascal Terjan 2012-03-13 15:12:10 CET
Signing key had expired, packages have been signed and a bug to prevent upload has been open.
Comment 13 Frédéric Buclin 2012-03-13 18:53:43 CET
I found what was wrong in comment 9. The reason was that installing 4.9.1.2-21 didn't uninstall 4.9.1.2-20, and so when rpm restarted, it complained that I had to update the rpm and python-rpm packages, and suddenly realized that they were already installed. I uninstalled both 4.9.1.2-21 packages using urpme, and the still installed 4.9.1.2-20 packages were working again. Now the updates have been installed correctly.
Comment 14 Frédéric Buclin 2012-03-13 18:57:35 CET
(In reply to comment #13)
> Now the updates have been installed correctly.

Grr.... only on the first run. Running rpmdrake a 2nd time fails again, with the exact same original error as reported in comment 0. Maybe that's related to the fact that when rpmdrake is done with the installation of new updates, it quits immediately instead of staying open. Looks like it quits before it had the time to correctly update the RPM DB.
Comment 15 Thierry Vignaud 2012-03-13 18:59:04 CET
err it doesn't. It just rescan rpmdb and return to the default view.
are you sure anything hasn't segfaulted (look at dmesg, try starting it from console)
Comment 16 Thierry Vignaud 2012-03-13 18:59:43 CET
Also, do all reporters run i586 (aka 32 bit mode) and not in 64bit mode?
Comment 17 Chih Wei Yao 2012-03-13 19:02:40 CET
I am running 64-bit, but it seems fixed now from your patch?

I'll change the platform to all.
Comment 18 Frédéric Buclin 2012-03-13 19:10:00 CET
(In reply to comment #15)
> err it doesn't. It just rescan rpmdb and return to the default view.
> are you sure anything hasn't segfaulted (look at dmesg, try starting it from
> console)

Ah ok, didn't know about updating vs rescanning the RPM DB. :)

I see no error in dmesg (the file hasn't been touched for 2 hours). But I saw that I had both librpm2-4.9.1.2-20.mga2 and librpm2-4.9.1.2-21.mga2 installed. So I deleted the RPM DB and recreated it following the instructions from comment 5 (not sure if this step was helpful), and then I removed librpm2-4.9.1.2-20.mga2, and things seem better again now.
Comment 19 Manuel Hiebel 2012-03-13 19:29:47 CET
*** Bug 4929 has been marked as a duplicate of this bug. ***
Comment 20 Rémi Verschelde 2012-03-13 21:00:27 CET
(In reply to comment #5)
> I've backported RH fixes into rpm-4.9.1.2-21.mga2
> You'll need to cleanup your rpmdb though:
> 
> rm -f /var/lib/rpm/_*
> rpm --rebuilddb

Cleaning my rpmdb solved the bug for me, thanks. I had no issue with unsigned packages.
Comment 21 Frédéric Buclin 2012-03-14 00:15:53 CET
FWIW, the problem is back again. I wonder if the problem occurs every time rpm is updated. There are many KDE updates now, and rpmdrake fails when it tries to install them, with a segfault. Not sure where the core dump is located.
Comment 22 Manuel Hiebel 2012-03-14 01:32:57 CET
*** Bug 4938 has been marked as a duplicate of this bug. ***
Comment 23 Manuel Hiebel 2012-03-14 02:21:35 CET
*** Bug 4941 has been marked as a duplicate of this bug. ***
Comment 24 Chih Wei Yao 2012-03-14 06:21:44 CET
The problem is back again, confirmed. After updating to 4.9.1.2-22, the rpmdb is crashed again, error message the same.
Comment 25 Thierry Vignaud 2012-03-14 08:16:08 CET
could you:
1) enable Core Release Debug medium,
2) install gdb glibc-debug perl-debug rpm-debug perl-URPM-debug
3) run "rpm -q --args perl /usr/sbin/rpmdrake"
   or  "rpm -q --args perl /usr/sbin/urpmi" if you
   used tu run urpmi
4) type "run"
5) if it segfaults, type "bt" and report back the trace
   printed by GDB (copy it in a text file you'll attach
   rather than paste else it will get mangled by bugzilla)
Comment 26 Chih Wei Yao 2012-03-14 08:34:07 CET
Should I do as the comment 5 implies and do what's described in comment 25?

Because nothing can be installed/uninstalled if rpmdb broke.
Comment 27 Thierry Vignaud 2012-03-14 08:43:27 CET
Yes
Comment 28 Chih Wei Yao 2012-03-14 09:02:00 CET
For the 3rd step of comment 25, I got command not found....?
Comment 29 Thierry Vignaud 2012-03-14 09:03:30 CET
sorry, shoud have been:

3) run "gdb -q --args perl /usr/sbin/rpmdrake"
   or  "gdb -q --args perl /usr/sbin/urpmi" if you
   used tu run urpmi
Comment 30 Thierry Vignaud 2012-03-14 09:04:29 CET
argh, should have been:

3) run "gdb -q --args perl /usr/sbin/rpmdrake"
   or  "gdb -q --args perl /usr/sbin/urpmi --auto-select"
   if you used to run urpmi
Comment 31 Chih Wei Yao 2012-03-14 09:12:10 CET
Created attachment 1759 [details]
Error message according to steps in comment 25
Comment 32 Chih Wei Yao 2012-03-14 09:12:56 CET
The attachment is the output from urpmi.
Comment 33 Thierry Vignaud 2012-03-14 09:34:04 CET
SIGPIPE is OK, you need to continue by typing "CONT"
Comment 34 Chih Wei Yao 2012-03-14 09:38:22 CET
I got no more message than this:

(gdb) c
Continuing.

Program received signal SIGPIPE, Broken pipe.
0x00007ffff6d64f80 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
82      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)


Then I run it again, got some message like this:


(gdb) run
Starting program: /usr/bin/perl /usr/sbin/urpmi --auto-select
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: the debug information found in "/usr/lib/debug//usr/lib/../lib64/librpm.so.2.0.2.debug" does not match "/usr/lib/../lib64/librpm.so.2" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/usr/lib64/librpm.so.2.0.2.debug" does not match "/usr/lib/../lib64/librpm.so.2" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug//usr/lib/../lib64/librpmbuild.so.2.0.1.debug" does not match "/usr/lib/../lib64/librpmbuild.so.2" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/usr/lib64/librpmbuild.so.2.0.1.debug" does not match "/usr/lib/../lib64/librpmbuild.so.2" (CRC mismatch).

套件都已經更新了(All packages are up to date)
[Inferior 1 (process 23230) exited normally]
Comment 35 Chih Wei Yao 2012-03-14 09:59:43 CET
[root@Kira kira]# gdb -q --args perl /usr/sbin/urpmi --auto-select
Reading symbols from /usr/bin/perl...Reading symbols from /usr/lib/debug/usr/bin/perl5.14.2.debug...done.
done.
(gdb) run
Starting program: /usr/bin/perl /usr/sbin/urpmi --auto-select
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: the debug information found in "/usr/lib/debug//usr/lib/../lib64/librpm.so.2.0.2.debug" does not match "/usr/lib/../lib64/librpm.so.2" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/usr/lib64/librpm.so.2.0.2.debug" does not match "/usr/lib/../lib64/librpm.so.2" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug//usr/lib/../lib64/librpmbuild.so.2.0.1.debug" does not match "/usr/lib/../lib64/librpmbuild.so.2" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/usr/lib64/librpmbuild.so.2.0.1.debug" does not match "/usr/lib/../lib64/librpmbuild.so.2" (CRC mismatch).

錯誤:rpmdb: Thread/process 24151/140383566608128 failed: Thread died in Berkeley DB library
錯誤:資料庫4 錯誤(-30974) 來自 dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
錯誤:無法使用資料庫 4- (-30974) 開啟 Packages 索引
錯誤:無法開啟套件資料庫 /var/lib/rpm
無法開啟 rpmdb
[Inferior 1 (process 24211) exited with code 011]
(gdb) bt
No stack.
(gdb) 

Back trace got no result...?
Comment 36 Thierry Vignaud 2012-03-14 10:02:44 CET
This means this time you got no issue.
Do people having issues got them after running rpmdrake or urpmi?

BTW, here's updated instructions, ignoring SIGPIPE automatically
could you:
1) enable Core Release Debug medium,
2) install gdb glibc-debug perl-debug rpm-debug perl-URPM-debug
3) run "gdb -q --args perl /usr/sbin/rpmdrake"
   or  "gdb -q --args perl /usr/sbin/urpmi --auto-select"
   if you used to run urpmi
4) type "handle SIGPIPE nostop noprint pass"
5) type "run"
6) if it segfaults, type "bt" and report back the trace
   printed by GDB (copy it in a text file you'll attach
   rather than paste else it will get mangled by bugzilla)
Comment 37 Jacques Pronchery 2012-03-14 11:04:03 CET
Created attachment 1760 [details]
Test

Here is the test.
Comment 38 Jacques Pronchery 2012-03-14 11:28:00 CET
Created attachment 1761 [details]
Second test

The prévious test was made without the *-debug packages and a rpmdrake out of work.
The second test is made with *_debug packages installed and a rpmdrake working.
It seems rpmdrake install the first package and crashes at ther end.
urpmi works OK.
Comment 39 Thierry Vignaud 2012-03-14 11:32:19 CET
Thanks :-) !!!

But of course the crash doesn't occurred where I thinked it would :-(

Please redo it after installing glib2.0-debug, perl-Glib-debug, perl-Gtk2-debug and gtk+2.0-debug

BTW what theme are you using?
Comment 40 Jacques Pronchery 2012-03-14 11:48:31 CET
Created attachment 1763 [details]
Test n° 3
Comment 41 Jacques Pronchery 2012-03-14 11:50:13 CET
I use Oxygen-gtk
Comment 42 Thierry Vignaud 2012-03-14 11:52:21 CET
You forgot to actually run "bt" :-(
You might want to install oxygen-gtk-debug too btw
Comment 43 Jacques Pronchery 2012-03-14 12:01:21 CET
Created attachment 1765 [details]
Test n°4
Comment 44 Thierry Vignaud 2012-03-14 12:09:06 CET
Looks like perl is segfaulting upon receiving SIGALARM
Can you generate a core file and send it back to me (by email)
just type "gcore" after the segfault.
It'll write a file named like core.XXXX (eg: core.156455).
Compress it with xz (eg: xz core.1564) and send it to me by email.
Thx
Comment 45 Thierry Vignaud 2012-03-14 12:17:04 CET
Or put it somewhere on the net (might be 30mb compressed) so that I can download it.
Comment 46 Thierry Vignaud 2012-03-14 12:23:38 CET
Created attachment 1766 [details]
temporary disable flushing every second

Once you've answered the previous comments, can you check if that patch (which is not a real solution) makes this bug disappear?
As root, just type in a terminal:
patch -p0 < /where/it/was/downloaded/4918.diff
Comment 47 Thierry Vignaud 2012-03-14 12:25:06 CET
Could you also try "print PL_signals" in GDB once rpmdrake as segfaulted?
Comment 48 Jacques Pronchery 2012-03-14 12:53:16 CET
The file is too big, you can foud it at :
http://jjpcy/core.6219
Comment 49 Jacques Pronchery 2012-03-14 12:54:28 CET
ERROR :
http://jjpcy.fr/core.6219
Comment 50 Jacques Pronchery 2012-03-14 14:05:28 CET
(In reply to comment #47)
> Could you also try "print PL_signals" in GDB once rpmdrake as segfaulted?

(gdb) print PL_signals
No symbol "PL_signals" in current context.
(gdb)
Comment 51 Jacques Pronchery 2012-03-14 14:14:36 CET
Created attachment 1767 [details]
Test with the patch

Yes it works with the patch.
Comment 52 Thierry Vignaud 2012-03-14 17:28:11 CET
(In reply to comment #48)
> The file is too big, you can foud it at :

argh, you should have compressed it.


(In reply to comment #50)
> (In reply to comment #47)
> > Could you also try "print PL_signals" in GDB once rpmdrake as segfaulted?
> 
> (gdb) print PL_signals
> No symbol "PL_signals" in current context.
> (gdb)

You need to do it once it segfaulted
Comment 53 Jacques Pronchery 2012-03-14 18:05:14 CET
I do it when it segfaulted.
Comment 54 diego w 2012-03-14 22:07:41 CET
I just updated RPM a few minutes ago, now having the same problems :(

I tried a rpmdb --rebuilddb which failed with the following messages:

Fehler: rpmdb: Thread/process 5285/3073455808 failed: Thread died in Berkeley DB library
Fehler: db4-Fehler (-30974) von dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
Fehler: Kann den Packages-Index nicht öffnen, benutze db4 -  (-30974)

is there a way to install a corrected RPM RPM after it is fixed?
Comment 55 diego w 2012-03-14 22:15:35 CET
ok after rereading comment 5 it worked...

seems to be fixed for me
Comment 56 Doug Laidlaw 2012-03-15 00:16:01 CET
This seemed to be fixed for me yesterday, but it has come back.

I got the first command to delete the db from another forum; that was ineffective alone.  I applied both, and yesterday's updates seemed to go to completion.  But some are still there to be done, and rpmdrake is still crashing.
Comment 57 Doug Laidlaw 2012-03-15 00:21:57 CET
Just applied both commands again and was able to install 4 updates from the command line.  rpmdrake shows nothing outstanding.
Comment 58 AL13N 2012-03-15 00:56:06 CET
i had this only with rpm-4.9.1.2-22.mga2 & rpmdrake
Comment 59 Wolfgang Bornath 2012-03-15 01:15:09 CET
On several different installations of mageia2 (all with latest updates) I have no problems with this any more. rpmdrake is working fine now.
rpm-4.9.1.2-22.mga2
rpmdrake-5.30-mga2
Comment 60 Doug Laidlaw 2012-03-15 01:28:00 CET
AL13N explains why I had no problems from the command line.  I didn't notice it at all in Release 1.My current version in Cauldron is 5.30-1.mga2, downloaded today.  If you don't hear from me, everything is O.K.
Comment 61 Jacques Pronchery 2012-03-15 14:37:35 CET
I have just updated Mageia
The new    rpmdrake-5.30-2.mga2   works fine.

But there is a missing dependence, when lauching rpmdrake we have :
Gtk-Message **: Failed to load module "canberra-gtk-module" at /usr/lib/libDrakX/mygtk2.pm line 20.
We have to install  "libcanberra-gtk0".
Comment 62 Thierry Vignaud 2012-03-15 14:43:01 CET
Thas has nothing to do with rpmdrake which works fine without that.
Any gtk+ application would show this
Comment 63 Doug Laidlaw 2012-03-15 14:49:13 CET
I was about to say that I regard it as a nuisance message.  I thought that perhaps libcanberra had a strange location, or something.  It seemed to live in its own subdirectory.
Comment 64 diego w 2012-03-16 00:23:39 CET
I just updated RPMdrake and got the problem again:

[root@localhost diego]# rpm -qif /usr/sbin/NetworkManager 
Fehler: rpmdb: Thread/process 6257/3074139840 failed: Thread died in Berkeley DB library
Fehler: db4-Fehler (-30974) von dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
Fehler: Kann den Packages-Index nicht öffnen, benutze db4 -  (-30974)
Fehler: Kann Paket-Datenbank in /var/lib/rpm nicht öffnen
Fehler: rpmdb: Thread/process 6257/3074139840 failed: Thread died in Berkeley DB library
Fehler: db4-Fehler (-30974) von dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
Fehler: Kann Paket-Datenbank in /var/lib/rpm nicht öffnen
Fehler: rpmdb: Thread/process 6257/3074139840 failed: Thread died in Berkeley DB library
Fehler: db4-Fehler (-30974) von dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
Fehler: Kann Paket-Datenbank in /var/lib/rpm nicht öffnen
Die Datei /usr/sbin/NetworkManager gehört zu keinem Paket
Comment 65 diego w 2012-03-16 00:37:41 CET
after a fresh run of comment 5 its working again.

version rpmdrake-5.30-2.mga2.src.rpm

after this urpmi --auto-update worked
Comment 66 Doug Laidlaw 2012-03-16 03:13:42 CET
Same thing here.

It seems to be related to the graphical rpmdrake: see Comment 58. urpmi --auto-update will always work.
Comment 67 Doug Laidlaw 2012-03-16 03:26:05 CET
Of course I should have said that you have to clean up first by running comment 5.  At an earlier stage, after cleaning up, I ran rpmdrake a second time, and it crashed again.  The last few times, I have su'ed to root, so it was convenient to use the command line.
Comment 68 Thierry Vignaud 2012-03-16 10:14:24 CET
*** Bug 4977 has been marked as a duplicate of this bug. ***
Comment 69 Manuel Hiebel 2012-03-16 18:16:04 CET
*** Bug 4981 has been marked as a duplicate of this bug. ***
Comment 70 diego w 2012-03-16 18:56:46 CET
mgaupdate signals new updates

when rpmdrake is opened it wants me to deinstall itself, whereas urpmi installed the updated packages.

hmmmmm strange... just now urpmi finished and rpmdrake showed no updates, once I closed it mgaupdate rescanned and i reopened rpmdrake and again the following "suggestion" came up:

Das folgende Paket muss entfernt werden, um die Aktualisierungen 
durchführen zu können:
rpmdrake-5.30-2.mga2.noarch
 (um rpmdrake-5.30-2.mga2.noarch zu installieren)
Comment 71 Manuel Hiebel 2012-03-17 00:04:49 CET
*** Bug 4989 has been marked as a duplicate of this bug. ***
Comment 72 Thierry Vignaud 2012-03-17 02:13:44 CET
(In reply to comment #70)
Because it is installed twice.
If you "rpm -q rpmdrake", or if you check in rpmdrake, you should see that there're two versions of rpmdrake installed.
You must remove the older one
Comment 73 Thierry Vignaud 2012-03-17 15:04:53 CET
*** Bug 4994 has been marked as a duplicate of this bug. ***
Comment 74 diego w 2012-03-17 22:31:14 CET
@thierry: yes and no...

it is in fact installed twice, but it wants to deinstall the newer version to reinstall the same version...
Comment 75 Doug Laidlaw 2012-03-17 23:31:04 CET
I just let it do what it wanted.  Go ahead and say yes.  Everything will be O.K.
Comment 76 Randy Wilson 2012-03-18 02:20:29 CET
I had this problem with two successive installs of Beta 2. After the initial setup, including enabling nonfree and tainted, the first run of Rpmdrake would crash and render the database unusable. I read these bug reports during the third install. After configuring the repositories as before, I ran "urpmi --auto-update" from the command line. Rpmdrake now works without crashing. Two things were different. The new URPM package was installed, and the potential conflict between Rpmdrake and the update checking task (???)
Comment 77 diego w 2012-03-18 15:28:41 CET
i manually deinstalled the older version and now all is fine again, 
I just got the updates for mplayer and lxde via the GUI and it worked as expected.
Comment 78 Doug Laidlaw 2012-03-18 16:12:23 CET
Mine said that the new version would have to be removed to install the new version!  I couldn't see a way of doing that.  I recall uninstalling one version of rpmdrake manually, although I thought that it would be flagged as an essential package.  I suppose that it is only a GUI for the command-line tools, which were still there.  When I got the message to remove it to install the same thing, I simply told it to go ahead.  Mine is now O.K. as well.  The bug can probably be changed to Fixed, unless more reports are needed.
Comment 79 Manuel Hiebel 2012-03-18 18:20:29 CET
*** Bug 5011 has been marked as a duplicate of this bug. ***
Comment 80 mnaud mnaud 2012-03-22 16:40:22 CET
am trying to use 2_b2 and

rpm's db are still dammage
drakerpm still doesnt work properly (after a fresh install try to add qemu or gramps and wait for the crash)

i have try differents manipulations like do command line update / rebuild rpm db's files, ... but nothing work properly for me.

maybe i have misunderstand what i have read on this bug,

some one can synthesis the correct manipulation to have both command line and drakrpm to work properly on 2_b2 ?
Comment 81 Wolfgang Bornath 2012-03-22 16:57:42 CET
(In reply to comment #80)
> am trying to use 2_b2 and
> rpm's db are still dammage

Yes, because the new rpmdrake package was uploaded after the ISOs were built.

Do this (as described and confirmed in the related forum thread a while ago):

As root remove the following files from /var/lib/rpm:
# rm -f /var/lib/rpm/__db* 
# rm -f /var/lib/rpm/.rpm.lock
# rm -f /var/lib/rpm/.RPMLOCK

(maybe you only have one of the lock files)

Then recreate the database:

# rpm -f rebuilddb

Now DO NOT TOUCH rpmdrake before you did an update with urpmi:
# urpmi --auto-update

This will update rpmdrake and now you can safely use rpmdrake.
Comment 82 mnaud mnaud 2012-03-22 21:32:27 CET
does not work on my current VM ?! 
destroy VM and create a new one with fresh installation : OK it's working.
Comment 83 Remco Rijnders 2012-03-23 09:26:52 CET
*** Bug 5068 has been marked as a duplicate of this bug. ***
Comment 84 Thierry Vignaud 2012-03-24 14:46:04 CET
Why raise priority of a bug fixed for quite some time...
Comment 85 Marja van Waes 2012-03-24 14:48:08 CET
(In reply to comment #84)
> Why raise priority of a bug fixed for quite some time...

Because I understood the fix wasn't committed and I didn't know the reason
Comment 86 John Bowden 2012-03-25 13:34:06 CEST
I have just replicated this update bug on 86-64 on a test install.

I removed the db and rebuilt it plus used control centre to remove old version of rpmdrake. Its now doing 180mb of updates
Comment 87 Manuel Hiebel 2012-03-25 14:17:01 CEST
*** Bug 5081 has been marked as a duplicate of this bug. ***
Comment 88 Andy Axnot 2012-03-25 14:42:33 CEST
(In reply to comment #81)
> (In reply to comment #80)
> > am trying to use 2_b2 and
> > rpm's db are still dammage
> 
> Yes, because the new rpmdrake package was uploaded after the ISOs were built.
> 
> Do this (as described and confirmed in the related forum thread a while ago):
> 
> As root remove the following files from /var/lib/rpm:
> # rm -f /var/lib/rpm/__db* 
> # rm -f /var/lib/rpm/.rpm.lock
> # rm -f /var/lib/rpm/.RPMLOCK
> 
> (maybe you only have one of the lock files)
> 
> Then recreate the database:
> 
> # rpm -f rebuilddb
> 
> Now DO NOT TOUCH rpmdrake before you did an update with urpmi:
> # urpmi --auto-update
> 
> This will update rpmdrake and now you can safely use rpmdrake.

Is this command correct?
# rpm -f rebuilddb

The preceding three commands such as rm -f /var/lib/rpm/__db* seem to execute without error, but rpm -f rebuilddb runs rpm with a listing of options, which does NOT include 'rebuilddb'. I am using M2 Beta2 i586.

# rpm --rebuilddb    # does work

but then I encounter some errors later. There are several requests for "core media" and finally:

Please insert the medium named "core media"
Use of uninitialized value in subroutine entry at /usr/lib/perl5/vendor_perl/5.14.1/i386-linux-thread-multi/Net/DBus/Binding/Connection.pm line 257.

So it doesn't work for me. I am coming from another distro, PCLinuxOS, that uses synaptic and I'm not familiar with rpm or urpmi, perhaps I'm doing something wrong.
Comment 89 Wolfgang Bornath 2012-03-25 15:13:07 CEST
(In reply to comment #88)
> 
> # rpm --rebuilddb    # does work

Yes.
 
> but then I encounter some errors later. There are several requests for "core
> media" and finally:
> 
> Please insert the medium named "core media"
> Use of uninitialized value in subroutine entry at
> /usr/lib/perl5/vendor_perl/5.14.1/i386-linux-thread-multi/Net/DBus/Binding/Connection.pm
> line 257.

This is a known problem. You have to remove the entry for the local installation media ("core media") and set up the online media.
Comment 90 AL13N 2012-03-25 16:30:44 CEST
ok, i'm adding a comment here, because it seems not to be clear for everyone:

IIUC,

This bug in rpmdrake is resolved, it was committed and pushed onto buildsystem and is in cauldron.

now, some of you have broken rpm databases, but there will NOT be a fix for that. people having this issue WILL have to do the manual fix.

the reason for this is very simple. we have mga1 => mga2 upgrade path (and these upgrades (from RC on) will not have this problem. because the bug appeared in cauldron only (and beta2). there is no supported upgrade path from beta2 to mga2.

the second reason is quite simple too, that's because rpmdrake was affected and the rpm database is corrupted. since it's corrupted, you can't upgrade the fixed version.

tl;dr : it's already fixed, if you still have the problem you'll need to do the manual procedure.

(correct me if i'm wrong)
Comment 91 Doug Laidlaw 2012-03-25 16:43:57 CEST
Naturally, if the rpm database is broken, that is not a problem related to rpmdrake or urpmi.

I thought that the issue with "core media" had already been fixed. I did as wobo says, and substituted the online sources.  I have printed out an earlier version of http://www.mageia.org/en/1/migrate/, but I think that there is a better version somewhere, which uses $MIRRORLIST.
Comment 92 Sander Lepik 2012-03-27 14:20:44 CEST
*** Bug 5129 has been marked as a duplicate of this bug. ***
Comment 93 Manuel Hiebel 2012-04-02 17:51:24 CEST
*** Bug 5193 has been marked as a duplicate of this bug. ***
Comment 94 Manuel Hiebel 2012-04-09 13:45:48 CEST
*** Bug 5303 has been marked as a duplicate of this bug. ***
Comment 95 AL13N 2012-04-09 13:51:49 CEST
we need a soonish next beta release...
Comment 96 Doug Laidlaw 2012-04-09 14:16:55 CEST
Beta 3 is due on the 14th, replacing RC on the 10th.
Comment 97 Remco Rijnders 2012-04-10 08:28:25 CEST
*** Bug 5324 has been marked as a duplicate of this bug. ***
Comment 98 Sander Lepik 2012-04-11 09:47:24 CEST
*** Bug 5341 has been marked as a duplicate of this bug. ***
Comment 99 alain deraedt 2013-04-18 14:41:19 CEST
After running the commands as in comment 81, the command
# rpm --rebuilddb
doesn't work; when running, nothing happens, and it doesn't come back to the prompt.
To stop it, need to do Ctrl+C
The problem is not resolved for me
Comment 100 Doug Laidlaw 2013-04-18 14:55:13 CEST
What version of Mageia are you running?  Seems to be fixed in Beta4.
Comment 101 alain deraedt 2013-04-19 00:32:38 CEST
(In reply to Doug Laidlaw from comment #100)
> What version of Mageia are you running?  Seems to be fixed in Beta4.

I run a mageia2 i586 (32 bits) definitive version; everything worked well with my ancient stuff (mobo asus p5q pro, 8 GB DDR2, chipset Intel P45, socket LGA775)
But I recently renewed my stuff (mobo gigabyte x58a-ud7, chipset Intel x58, socket LGA1366, 24 GB DDR3, CPU Intel core i7 960) and now mageia2 i586 doesn't work at all: impossibility for updating RPM's (the symptoms are those described above by Frederic Buclin) everything very slow running even with nepomuk cancelled. 
Regards
Comment 102 alain deraedt 2013-04-19 00:34:58 CEST
Sorry, I just forget to say that my mageia's 1 i586, 1 x86_64 and 2 x86_64 fine work.
Comment 103 Doug Laidlaw 2013-04-19 00:44:45 CEST
The bug isn't a Mga2 bug.  It didn't start until Cauldron.  It was the result of a change in rpmdrake or one of the suite.  If a change in hardware caused it, then it isn't a bug.  Even so, I would have expected the commands you ran to fix it.

Sorry, I will have to hand this back to the Bugsquad.
Comment 104 Doug Laidlaw 2013-04-19 01:12:26 CEST
Just a couple of thoughts:

I can't see how a change in hardware can affect rpmdrake etc.  Only your drivers should have needed changing.

I notice that you have tried the 64-bit version.  I did the same, and afterwards, I couldn't start mysql.  The system goes by UIDs, not user names.  What was the mysql user under 32-bit became rtkit under 64-bit.  I had a similar problem going back to 32-bit.  I rather suspect that it is the cause of your problem as well.

The installer doesn't format your /var partition by default. If you have a separate /var partition, I would recommend that you do a fresh install of mga2 and format /var.  Otherwise, the only suggestion I can make is to see who owns the files in /var/cache/urpmi and /var/lib/urpmi.
Comment 105 alain deraedt 2013-04-19 12:07:59 CEST
(In reply to Doug Laidlaw from comment #103)
> The bug isn't a Mga2 bug.  It didn't start until Cauldron.  It was the
> result of a change in rpmdrake or one of the suite.  If a change in hardware
> caused it, then it isn't a bug.  Even so, I would have expected the commands
> you ran to fix it.
> 
> Sorry, I will have to hand this back to the Bugsquad.

I ran the commands as shown in comment 81, say:
# rm -vf /var/lib/rpm/__db*
# rm -vf /var/lib/rpm/.rpm.lock
# rm -vf /var/lib/rpm/.RPMLOCK
# rpm --rebuilddb

the latter one never led to any result: it didn't give back hand, I let it run during one whole night, and the day after morning, as nothing happened, I stopped it by Ctrl+C
Comment 106 Doug Laidlaw 2013-04-19 13:02:54 CEST
If your permissions are wrong, that is quite possible.  Please check who owns the directories /var/cache/urpmi and /var/lib/urpmi and all their contents.  As superuser run the following command in a terminal

"chown -r root.root /var/cache/urpmi /var/lib/urpmi"

without the quotes then the commands in Comment 81 again.  Then reboot, just for good measure.

Your problem can't be this bug; it wasn't in Mga 2.
Comment 107 alain deraedt 2013-04-19 13:03:14 CEST
(In reply to Doug Laidlaw from comment #104)
> Just a couple of thoughts:
> 
> I can't see how a change in hardware can affect rpmdrake etc.  Only your
> drivers should have needed changing.
> 
> I notice that you have tried the 64-bit version.  I did the same, and
> afterwards, I couldn't start mysql.  The system goes by UIDs, not user
> names.  What was the mysql user under 32-bit became rtkit under 64-bit.  I
> had a similar problem going back to 32-bit.  I rather suspect that it is the
> cause of your problem as well.
> 
> The installer doesn't format your /var partition by default. If you have a
> separate /var partition, I would recommend that you do a fresh install of
> mga2 and format /var.  Otherwise, the only suggestion I can make is to see
> who owns the files in /var/cache/urpmi and /var/lib/urpmi.

I have on my pc four systems, all mageia (1-32, 1-64, 2-32, 2-64); all but M2-32 fine work; I have remark that the owner and group of subdirectories of /var/lib differ wether it is a 32bits or a 64 bits system.
For example: /var/lib/rpm: o=rpm g=rpm  mag2-64
                           o=avahi g=lock  mga1-32
                           o=avahi g=lock  mga2-32
                           o=usbmux  g=avahi-autoipd  mga1-64
Regards
Comment 108 Doug Laidlaw 2013-04-19 13:12:18 CEST
OK, well, you know what the trouble is.  Run the commands I just gave you.  I can't do it by remote control.  Until you take 5the steps people ask you to, nobody can help you.
Comment 109 alain deraedt 2013-04-19 14:10:24 CEST
(In reply to Doug Laidlaw from comment #108)
> OK, well, you know what the trouble is.  Run the commands I just gave you. 
> I can't do it by remote control.  Until you take 5the steps people ask you
> to, nobody can help you.

unfortunately, /var/cache/urpmi and /var/cache/lib were already root:root on mageia2-32 (see comment 106) when issues occured!
regards
Comment 110 Doug Laidlaw 2013-04-19 16:28:18 CEST
That wasn't what you said before:

/var/lib/rpm: o=rpm g=rpm  mag2-64
                           o=avahi g=lock  mga1-32
                           o=avahi g=lock  mga2-32
                           o=usbmux  g=avahi-autoipd  mga1-64
Comment 111 Doug Laidlaw 2013-04-19 17:24:03 CEST
My mistake.  The error is in /var/lib/rpm, not in /var/lib/urpmi

Change that to root:root.

Better still, reinstall, and make sure that /var is cleaned up.
Comment 112 alain deraedt 2013-04-25 12:53:50 CEST
(In reply to Doug Laidlaw from comment #111)
> My mistake.  The error is in /var/lib/rpm, not in /var/lib/urpmi
> 
> Change that to root:root.
> 
> Better still, reinstall, and make sure that /var is cleaned up.

It doesn't work; it's clearly not a problem of rights, but surely a file which is corrupted; but in a linux system, there are thousands and thousands of instruction lines, and searching what line is wrong is quitely impossible.
Regards
Comment 113 Doug Laidlaw 2013-04-25 14:22:27 CEST
It is working for everybody except you.  And a bug from a later version can't be affecting your Release 2.  Believe what you like.
Comment 114 Doug Laidlaw 2013-04-25 14:52:49 CEST
Gee this bug report thread has got long!

Put it this way.  If it is a file, you don't know which one it is.  If I am right, it is permissions somewhere.  Either way, as you say, it would be worse than finding a needle in a haystack.  If it is a file, it needs to be replaced.  If it is permissions, they need to be set afresh.  The only way to fix it is to do a complete reinstall, making sure that your entire /var directory is replaced, as well as /usr.  If there is anything in /var that you want to keep, make a backup then let it go.  That will fix it, believe me.

But Release 3 is due in about a fortnight.  You might as well install that, but as a fresh install, not an upgrade.  Version upgrades are supposed to work, but they never seem to, and you need to get rid of your /var directory completely.  With an upgrade, that wouldn't happen.  The bug will heave a sigh of relief, and go on causing trouble.

BTW, this is Bugzilla, not a help forum.
Comment 115 alain deraedt 2013-05-10 14:30:51 CEST
summary:
mageia2-32 doesn't correctly work on platform Intel LGA 1366 (24GB DDR3 memory) under kernels 3.4... but works on this platform under older kernels 2.6.38...
Bye
Comment 116 Doug Laidlaw 2013-05-10 14:42:01 CEST
No further comments from me.  This sounds like a completely fresh bug.  As stated before, this Bugzuilla entry relates to Cauldron, not Mga2.
Comment 117 Marja van Waes 2013-05-10 16:49:18 CEST
(In reply to Doug Laidlaw from comment #116)
> No further comments from me.  This sounds like a completely fresh bug.  As
> stated before, this Bugzilla entry relates to Cauldron, not Mga2.

This bug has indeed never been present in a stable release and was already fixed before Mageia 2 was released. After 2012-04-11, for a whole year no one reported this issue, until 2013-04-18.
So I agree this sounds like a new bug. 
Besides, even if there would be a regression, it would be better to have a new report for it, since this one is already 117 comments long.

@ Alain

please do a /fresh/ Mageia 2 or 3 install, as suggested by Doug, and please do it with either the traditional installer DVD, or the dual iso, or with a network install.

If you have this problem again immediately after install, then please file a new bug report and attach 
/root/drakx/report.bug.gz 
to it.

However, if the bug only returns after rebooting and then updating your system, then please attach a different file:
(for Mageia 2) /var/log/messages   
(for Mageia 3) the journalctl.txt that results from (as root) running the following command in a konsole/terminal:
journalctl 2>&1 | tee journalctl.txt

Thanks :)

Closing this report again.
Comment 118 alain deraedt 2013-05-11 12:49:15 CEST
yesterday (comment 115) mag2-32 well worked under kernel 2.6.38.8-server-10.mga, but today the same symptom (fatal error: Couldn't open RPM DB () at /usr/lib/perl5/vendor_perl/5.14.2/Rpmdrake/open_db.pm line 74..) appears again.
It's a long time I attempted to reinstall mag2-32 with DVD (under platform Intel LGA 1366), but the same symptoms occured

Note You need to log in before you can comment on or make changes to this bug.