I had just made a full disk image of my work laptop Thinkpad T400, so now was a good occasion to attempt a full online update mga6 (64 bit, fully updated, plasma) to cauldron. So i changed changed repos and let urpmi chew on it, went for lunch and when i got back i saw that error just after it said it was restoring /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-1.b14.1.mga7.x86_64/jre/lib/security/java.security.rpmnew: floating point error, memory dump created. If it is of any significance urpmi first installed about 200 packages, and said i should restart my computer. I dit not dare that as it then was a mga6/7 hybrid... so i just let it restart and continue and it did 650 of 1954 packages when it hit this error. (on the way there some thing could not be installed, some thing not upgraded, but that is normal in this situation) Looking in journal i see: kernel: traps: urpmi[32547] trap divide error ip:7f9df4ab4876 sp:7fff9dc15520 error:0 in libdb-5.3.so (deleted)[7f9df49e0000+1b000] Now i issued rpm --rebuilddb and it replied it could not delete old database /var/lib/rpmold.28213 so i renamed it and rebuilddb could then run. Now i have started another urpmi -up round and it is chewing along
I don't understand what the kernel traps message means. If that matters: both /usr/lib64/libdb-5.3.so and /usr/lib/libdb-5.3.so are present here, in a cauldron that is almost up-to-date. Can you attach the _full_ journal logs of the upgrade attempt?
CC: (none) => kernel, mageiatools, marja11, thierry.vignaudSource RPM: urpmi 8.111-2.mga7.src.rpm => db53-5.3.28-14.mga7 ??Keywords: (none) => NEEDINFO
Created attachment 9935 [details] journalctl log of trap divide error, since boot The log since start. Machine was booted late in the night, work performed, suspended and then resumed, upgrade mga6 -> 7 started Interesting lines at 13:11:54: jan 29 13:11:49 localhost [RPM][32547]: install lib64champlain0.12_0-0.12.16-1.mga7.x86_64: success jan 29 13:11:54 localhost audit[32547]: ANOM_ABEND auid=10702 uid=0 gid=0 ses=10 pid=32547 comm="urpmi" exe="/usr/bin/perl5.26.1" sig=8 res=1 jan 29 13:11:54 localhost kernel: traps: urpmi[32547] trap divide error ip:7f9df4ab4876 sp:7fff9dc15520 error:0 in libdb-5.3.so (deleted)[7f9df49e0000+1b1000] jan 29 13:11:54 localhost kernel: audit: type=1701 audit(1517227914.765:344): auid=10702 uid=0 gid=0 ses=10 pid=32547 comm="urpmi" exe="/usr/bin/perl5.26.1" sig=8 res=1
BTW upgrade seem mostly have went OK
Keywords: NEEDINFO => (none)
So that was a live upgrade? I guess we should add libdb to priority upgrade, especially given that libdb has patches for rpm in mga7
Source RPM: db53-5.3.28-14.mga7 ?? => db53-5.3.28-14.mga7 urpmi
Assignee: bugsquad => mageiatools
(In reply to Thierry Vignaud from comment #4) > So that was a live upgrade? yes, urpmi running on booted system, in a terminal in some DE - I forgot if it was in Plasma, MATE, xfce, or LXDE...
(In reply to Thierry Vignaud from comment #4) > So that was a live upgrade? > I guess we should add libdb to priority upgrade, especially given that libdb > has patches for rpm in mga7 what about this ?
CC: (none) => mageia
Same problem with an upgrade mageia 6 --> mageia 7b3. First computer : mageia 6 x86_64 (fully up-to-date) with task-lamp, lxqt and development environments (C, android-studio, lazarus...) Second computer : mageia 6 x86_64 (fully up-to-date too) with plasma and office softwares (nothing else) Using upgrade like https://wiki.mageia.org/en/Mageia_7_Notes_de_version-fr#Mise_.C3.A0_niveau_en_ligne.2C_en_utilisant_urpmi_.28ligne_de_commande.2FCLI.29 give an error : floating point error, memory core dumped on openjdk installation after message about java.property and java.security file replacement Can't rerun the command "urpmi" (each try "memory core dumped" ). After a reboot, "urpmi --auto-select" continue the upgrade despite error messages on bash login. A final reboot is necessary to find a completely working station.
CC: (none) => vincent
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=25072
I think this bug report can be closed as 25072 one.
CC: (none) => yves.brungard_mageia
This bug was fileed against Mageia 6 which is EOL since Sep 2019. Based on comment 8... Closing as OLD.
Resolution: (none) => OLDStatus: NEW => RESOLVED