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.
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?
CC: (none) => elegant.pegasus
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/
CC: (none) => remi
CC: (none) => dmorganec, thierry.vignaud, tmbSource RPM: (none) => rpm
I'll backport a fix from RH
*** Bug 4924 has been marked as a duplicate of this bug. ***
CC: (none) => jacques.pronchery
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
(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)))
@pascal: That's a build system (BS) issue. @frédéric: yes
CC: (none) => pterjan
Confirm Fixed, Should I mark it as resolved?
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?
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).
(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,}
Signing key had expired, packages have been signed and a bug to prevent upload has been open.
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.
(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.
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)
Also, do all reporters run i586 (aka 32 bit mode) and not in 64bit mode?
Status: NEW => ASSIGNED
I am running 64-bit, but it seems fixed now from your patch? I'll change the platform to all.
Hardware: i586 => All
(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.
*** Bug 4929 has been marked as a duplicate of this bug. ***
CC: (none) => bigdavesr
(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.
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.
*** Bug 4938 has been marked as a duplicate of this bug. ***
CC: (none) => leumar27
*** Bug 4941 has been marked as a duplicate of this bug. ***
CC: (none) => acarbura
The problem is back again, confirmed. After updating to 4.9.1.2-22, the rpmdb is crashed again, error message the same.
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)
Keywords: (none) => NEEDINFO
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.
Yes
For the 3rd step of comment 25, I got command not found....?
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
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
Created attachment 1759 [details] Error message according to steps in comment 25
The attachment is the output from urpmi.
SIGPIPE is OK, you need to continue by typing "CONT"
Attachment 1759 is obsolete: 0 => 1
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]
[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...?
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)
Created attachment 1760 [details] Test Here is the test.
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.
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?
Created attachment 1763 [details] Test n° 3
I use Oxygen-gtk
You forgot to actually run "bt" :-( You might want to install oxygen-gtk-debug too btw
Source RPM: rpm => glib2.0
Attachment 1763 is obsolete: 0 => 1
Created attachment 1765 [details] Test n°4
Attachment 1761 is obsolete: 0 => 1
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
CC: (none) => jquelinSource RPM: glib2.0 => perl rpmdrake
Attachment 1760 is obsolete: 0 => 1
Or put it somewhere on the net (might be 30mb compressed) so that I can download it.
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
Could you also try "print PL_signals" in GDB once rpmdrake as segfaulted?
The file is too big, you can foud it at : http://jjpcy/core.6219
ERROR : http://jjpcy.fr/core.6219
(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)
Created attachment 1767 [details] Test with the patch Yes it works with the patch.
CC: (none) => wilcal.int
(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
I do it when it segfaulted.
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?
CC: (none) => smiling.diego
ok after rereading comment 5 it worked... seems to be fixed for me
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.
CC: (none) => laidlaws
Just applied both commands again and was able to install 4 updates from the command line. rpmdrake shows nothing outstanding.
i had this only with rpm-4.9.1.2-22.mga2 & rpmdrake
CC: (none) => alien
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
CC: (none) => molch.b
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.
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".
Thas has nothing to do with rpmdrake which works fine without that. Any gtk+ application would show this
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.
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
after a fresh run of comment 5 its working again. version rpmdrake-5.30-2.mga2.src.rpm after this urpmi --auto-update worked
Same thing here. It seems to be related to the graphical rpmdrake: see Comment 58. urpmi --auto-update will always work.
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.
*** Bug 4977 has been marked as a duplicate of this bug. ***
CC: (none) => fredbezies
*** Bug 4981 has been marked as a duplicate of this bug. ***
CC: (none) => epistemepromeneur
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)
*** Bug 4989 has been marked as a duplicate of this bug. ***
CC: (none) => thespooks
(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
*** Bug 4994 has been marked as a duplicate of this bug. ***
CC: (none) => jaanus.ojangu
@thierry: yes and no... it is in fact installed twice, but it wants to deinstall the newer version to reinstall the same version...
I just let it do what it wanted. Go ahead and say yes. Everything will be O.K.
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 (???)
CC: (none) => randy
CC: (none) => AndyVetRep
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.
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.
*** Bug 5011 has been marked as a duplicate of this bug. ***
CC: (none) => gilbert.maillot
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 ?
CC: (none) => mnaud.free
(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.
does not work on my current VM ?! destroy VM and create a new one with fresh installation : OK it's working.
*** Bug 5068 has been marked as a duplicate of this bug. ***
CC: (none) => bartabbas
Priority: High => release_blockerCC: (none) => marja11
Why raise priority of a bug fixed for quite some time...
Priority: release_blocker => NormalStatus: ASSIGNED => RESOLVEDResolution: (none) => FIXEDSeverity: critical => normal
(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
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
CC: (none) => led43john
*** Bug 5081 has been marked as a duplicate of this bug. ***
CC: (none) => marcello.anni
(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.
(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.
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)
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.
*** Bug 5129 has been marked as a duplicate of this bug. ***
CC: (none) => fsandelin
*** Bug 5193 has been marked as a duplicate of this bug. ***
CC: (none) => rochiare
CC: smiling.diego => (none)
*** Bug 5303 has been marked as a duplicate of this bug. ***
CC: (none) => theamazingchiepoo
we need a soonish next beta release...
Beta 3 is due on the 14th, replacing RC on the 10th.
*** Bug 5324 has been marked as a duplicate of this bug. ***
*** Bug 5341 has been marked as a duplicate of this bug. ***
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
Status: RESOLVED => REOPENEDCC: (none) => alainderaedtResolution: FIXED => (none)
What version of Mageia are you running? Seems to be fixed in Beta4.
(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
Sorry, I just forget to say that my mageia's 1 i586, 1 x86_64 and 2 x86_64 fine work.
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.
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.
(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
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.
(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
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.
(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
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
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.
CC: fredbezies => (none)
(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
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.
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.
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
No further comments from me. This sounds like a completely fresh bug. As stated before, this Bugzuilla entry relates to Cauldron, not Mga2.
(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.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
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
*** Bug 21731 has been marked as a duplicate of this bug. ***
CC: (none) => alphonix
Unsubscribing. Anybody who expects Mageia2 to work in a present-day environment is bound to have problems. Because Mga2 is no longer supported, it won't be updated, and fixes won't be applied. If, as Dave says in reply to Bug 21731, most problems are caused by a corrupted update, that isn't a bug. Just refresh the rpm database.
CC: laidlaws => (none)