update to Mageia 7 went south

This forum is dedicated to basic help and support :

Ask here your questions about basic installation and usage of Mageia. For example you may post here all your questions about getting Mageia isos and installing it, configuring your printer, using your word processor etc.

Try to ask your questions in the right sub-forum with as much details as you can gather. the more precise the question will be, the more likely you are to get a useful answer

update to Mageia 7 went south

Postby jiml8 » Nov 24th, '19, 23:56

I finally cut loose enough time to upgrade from Mageia 6 to Mageia 7. It did not go well, and presently I am stuck. Rolling back was easy enough, but I need to get this to work.

Per the update instructions in the wiki, I manually removed udisks (which would have bitten me). I also removed a number of 32 bit devel libs from my system, as was specified.

I found it necessary to rebuild my rpm database.

My system was fully updated in Mageia 6 before I started.

Using urpmi, I switched repositories by first deleting the existing mageia 6 repos then adding in the mageia 7 repos, as called out in the Mageia 7 Release Notes in the wiki.

All of this was per the wiki, and I don't think I missed anything.

I started the update using this command:
Code: Select all
urpmi --auto-update --auto --force --download-all --test

and it appeared to complete successfully. It also had the side-effect of downloading 5015 packages required for my upgrade. I have been careful to preserve those files through my multiple attempts to upgrade; why download again?

I then did the upgrade with
Code: Select all
urpmi --auto-update --auto --force


This command installed the first 720-odd packages onto the disk (including glibc, the kernel, and some perl stuff, among other things), then began the scripting to install them into the system.

AT this point, installation fails.

When those first packages are being installed, I was seeing this warning several times:
Code: Select all
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US:en",
        LC_ALL = (unset),
        LC_PAPER = "en_US",
        LC_ADDRESS = "en_US",
        LC_MONETARY = "en_US",
        LC_SOURCED = "1",
        LC_NUMERIC = "en_US",
        LC_TELEPHONE = "en_US",
        LC_MESSAGES = "en_US",
        LC_COLLATE = "en_US",
        LC_IDENTIFICATION = "en_US",
        LC_MEASUREMENT = "en_US",
        LC_CTYPE = "en_US",
        LC_TIME = "en_US",
        LC_NAME = "en_US",
        LANG = "en_US"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").


The installation then segfaulted, informing me that there was a problem with the format of the new initrd (sorry, I did not copy the specific error message).

I then tried to re-run the urpmi upgrade command and got this message:
Code: Select all
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US:en",
        LC_ALL = (unset),
        LC_PAPER = "en_US",
        LC_ADDRESS = "en_US",
        LC_MONETARY = "en_US",
        LC_SOURCED = "1",
        LC_NUMERIC = "en_US",
        LC_TELEPHONE = "en_US",
        LC_MESSAGES = "en_US",
        LC_COLLATE = "en_US",
        LC_IDENTIFICATION = "en_US",
        LC_MEASUREMENT = "en_US",
        LC_CTYPE = "en_US",
        LC_TIME = "en_US",
        LC_NAME = "en_US",
        LANG = "en_US"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Int64.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xce00080)


The real issue is the last line, but I presume that the preceding warning is actually the source of the problem. Unfortunately, I don't know what is supposed to be there. I did manually set the LC_ALL key (export LC_ALL=en_US) but that did not solve the problem.. Instead, I now get the error message (I get it multiple times):
Code: Select all
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US)


I also get the same warning as above, except that LC_all is set to "en_US". And finally, I seem to have the error:
Code: Select all
error: rpmdb: DB_LOCK->lock_put: Lock is no longer valid
error: db5 error(22) from dbcursor->c_close: Invalid argument


And at this point urpmi hangs and I have to force-kill it.

So, what should I do about this?
jiml8
 
Posts: 1070
Joined: Jul 7th, '13, 18:09

Re: update to Mageia 7 went south

Postby wintpe » Nov 25th, '19, 23:50

hi jim.

sorry to hear this.

ive personaly updated my laptop by booting off the install cd and let it do the upgrade for me.

for my laptop it completed in less than half an hour and the a clean up of orphans and mga6 packages afterwards left it perfect.

its been great since.

but my selection of packages could be diferent to yours, and its usualy conflicts between package versions that causes these issues.

the iso upgrade can avoid this, unless you have installed rpms from non mageia sources. always recomend removing those first.

so my personal recomendation is clone your system first, then boot a full iso based upgrade.

others might disagree with me, so i speak from my own expiriece only.

regards peter
Redhat 6 Certified Engineer (RHCE)
Sometimes my posts will sound short, or snappy, however its realy not my intention to offend, so accept my apologies in advance.
wintpe
 
Posts: 1200
Joined: May 22nd, '11, 17:08
Location: Rayleigh,, Essex , UK

Re: update to Mageia 7 went south

Postby jiml8 » Nov 26th, '19, 09:21

Well, I do have the flatpak install system running because I wanted some things that were available that way, but not through the mageia repos.

I have no idea whether it could be a problem. My problem was a perl problem, and I do believe the flatpak things I have are python.

But, trying from an iso is a good idea; I would be running from the iso and not from my live system, so mismatched versions should not be a problem; when the install is finished that should be cleaned up.

Only question right now is whether I have a working DVD writer anyplace anymore...
jiml8
 
Posts: 1070
Joined: Jul 7th, '13, 18:09

Re: update to Mageia 7 went south

Postby doktor5000 » Nov 26th, '19, 18:36

jiml8 wrote:I then tried to re-run the urpmi upgrade command and got this message:
Code: Select all
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US:en",
        LC_ALL = (unset),
        LC_PAPER = "en_US",
        LC_ADDRESS = "en_US",
        LC_MONETARY = "en_US",
        LC_SOURCED = "1",
        LC_NUMERIC = "en_US",
        LC_TELEPHONE = "en_US",
        LC_MESSAGES = "en_US",
        LC_COLLATE = "en_US",
        LC_IDENTIFICATION = "en_US",
        LC_MEASUREMENT = "en_US",
        LC_CTYPE = "en_US",
        LC_TIME = "en_US",
        LC_NAME = "en_US",
        LANG = "en_US"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Int64.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xce00080)


Apart from that last line, you can read some context information about this in this older bug: https://bugs.mageia.org/show_bug.cgi?id=3723
It shows up that often because in /etc/bashrc there's a perl call to display pwd and if there's something wrong about locale setting then you see this perl locale warning pretty often.
By itself this should not be an issue. On a related note, what locales- packages do you have installed currently ?


The last line is a different issue, see e.g. https://bugs.mageia.org/show_bug.cgi?id=25072
Did you disable dnf-makecache as mentioned in release notes ?
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 15303
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: update to Mageia 7 went south

Postby jiml8 » Nov 27th, '19, 01:35

doktor5000 wrote:The last line is a different issue, see e.g. https://bugs.mageia.org/show_bug.cgi?id=25072
Did you disable dnf-makecache as mentioned in release notes ?

Yes I did.

However, there were multiple reboots and multiple recoveries, and multiple retries. I probably did not do that on every retry.

But, that error is the one that killed me the first time I tried the upgrade - and on that attempt I assure you that I did disable dnf-makecache as specified in the release notes.

And, that is the error that wound up killing me pretty much every time.

I think that using an iso is the safest way to go. It has the advantage that the system being upgraded is not running when it is upgraded, so these version problems can't be a problem unless the versions are not made consistent by the end of the upgrade.
jiml8
 
Posts: 1070
Joined: Jul 7th, '13, 18:09

Re: update to Mageia 7 went south

Postby jiml8 » Nov 27th, '19, 01:42

Actually, that bug looks very like what I was seeing, and I do have dnf on this system because I intended to play with it at one point and never got around to it.

So, maybe urpme dnf will solve my problem.
jiml8
 
Posts: 1070
Joined: Jul 7th, '13, 18:09

Re: update to Mageia 7 went south

Postby martinw » Nov 27th, '19, 21:42

You can indeed ignore the perl locale warnings. I've seen those on all the upgrade tests I've done.

Do you have enough free disk space in the relevant partition(s)? Downloading ~5000 packages before installing them is going to use a lot of space.

The error messages you report don't look like the dnf-makecache problem. But if you don't use dnf, removing it will eliminate that possibility.

If you do try a live system upgrade again, capture the output from urpmi by e.g.
Code: Select all
urpmi --auto-update --auto --force |& tee upgrade.log

and if it fails, extract the relevant part of the system log by e.g.
Code: Select all
journalctl --since=<time> > journal.log

replacing <time> with the time you started the upgrade. The full logs might give more clues about what is going wrong.
martinw
 
Posts: 547
Joined: May 14th, '11, 10:59

Re: update to Mageia 7 went south

Postby jiml8 » Dec 1st, '19, 10:31

So, I just attempted an update with an iso and it failed.

My system is VERY large. I have a 28G system partition which is 78% full at the present time, and this does not include /var or /tmp.

/var is symlinked off to a different volume which is encrypted. Similarly, /tmp is symlinked off to still a different volume, and encrypted. Also, /home resides on an encrypted volume, and I have always symlinked it rather than mounting /home somewhere else.

Well, the iso installer didn't like any of that.

So, fine. In runlevel 1, I removed the symlink to /tmp and to /home and replaced them with empty directories. I went into my /var directory and removed a couple of subdirectories that were huge (notably the /var/lib/flatpak directory which is huge and /var/cache/urpmi/rpms which currently contains over 5000 Mageia 7 packages.

I then rsync'ed that var into the new /var that I had created on / .

This leave / about 96% full.

So you know what happened. I ran out of space.

There is a reason I prefer to use the live update. But, it isn't working for me.

This is freakin' ugly.

So, when I get around to it, I'll repartition the SSD that has / on it to give myself another 20G or so, then I'll try again.
jiml8
 
Posts: 1070
Joined: Jul 7th, '13, 18:09

Re: update to Mageia 7 went south

Postby johnpenguin » Dec 5th, '19, 02:12

When those first packages are being installed, I was seeing this warning several times:

I follow the procedure outlined at https://forums.mageia.org/en/viewtopic.php?f=8&t=12920 and there was a certain instance I faced this situation with those perl messages. I would let the installation run for a while and then when it would look like it was halted behind the screen I would reset and restart the procedure. The procedure seemed to continue from the last point it had stopped, for example if it had stopped while installing XY then it would resume from this point onwards.

After doing this a few times, I ended up with a working system. It looked like when those messages start then everything goes on blindly till it halts, so I guess it's some kind of bug.

The system where I encountered this error was pretty vanilla, just an encrypted LVM and there were no extra libraries or 32-bit repositories. I didn't delve deeper into this, as it just worked in the end.
johnpenguin
 
Posts: 18
Joined: Feb 28th, '19, 02:15

Re: update to Mageia 7 went south

Postby tis » Dec 5th, '19, 20:07

Hi,

I started to upgrade from 6.1 to 7.1 as mgaapplet shows that new version is available. It seemed to work well, but some minutes later it finished and wanted to reboot, but after reboot I realize that not too much happened, only some packages were updated.

If I started a terminal bash has LCTIME set error or LC_ALL or Language. no rpm or urpmi worked, because the setting locale failed as jiml8 mentioned above.
(1 week earlier I updated my other 6.1 on SDD, and there wasn't any problem, that time I used: urpmi --auto-update --update --force method:https://wiki.mageia.org/en/Mageia_7_Release_Notes#Upgrading_online.2C_using_urpmi_.28CLI.29)

It was hard work, but now it works on my HDD too.
1,first I had to copy some locale files (/usr/share/local) from working install. that time urpmi and urpmi.addmedia worked with segmenation fault
2, had to repair perl5 update state (it was halfly updated)
3, rpmdb --rebuilddb, i think that was the time when I can add mga7 media and start to repair

4, urpmi --auto-update --update --force, lots of times
5, I had to manual update rpms lib64qt5gui,... you can use /var/cache/urpmi/rpms and then back to step 4 until all the problem were solved
It was lots of time, near 3000 packages had to update, with 40-50 stop. But now works and up to date.

What is the difference with updating with urpmi or mgaapplet? ( or it was because my HDD test mageia has much more packages installed?)
tis
 
Posts: 7
Joined: Sep 30th, '19, 20:19

Re: update to Mageia 7 went south

Postby jiml8 » Dec 15th, '19, 20:29

Well, I am now up in Mageia 7, after the most painful update I have had in at least the last 16 or 17 years.

I repartitioned my SSD, and moved /var onto it temporarily, then tried again with the .iso file. Didn't work. Dependency hell, and it kept insisting that there were a lot of packages that could not be installed. So I rolled back.

Well, I say, let's try dnf. So I did. Looked very promising. Downloaded everything quickly, resolved things, and told me only one conflict - which I resolved by removing the offending package (python-urllib3 ... gotta put that back in...). It then started the update, got a bit over 2000 packages into it, and crashed. The reason? Well...look at the log:
Code: Select all
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: warning: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232-1.b09.2.mga7.x86_64/jre/lib/security/java.policy
 created as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232-1.b09.2.mga7.x86_64/jre/lib/security/java.policy.rpmnew
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: warning: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232-1.b09.2.mga7.x86_64/jre/lib/security/java.securi
ty created as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232-1.b09.2.mga7.x86_64/jre/lib/security/java.security.rpmnew
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: /etc/host.conf: line 3: bad command `nospoof on'
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: /etc/host.conf: line 4: bad command `spoofalert on'
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: /etc/host.conf: line 3: bad command `nospoof on'
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: /etc/host.conf: line 4: bad command `spoofalert on'
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: restored /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232-1.b09.2.mga7.x86_64/jre/lib/security/java.policy
.rpmnew to /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232-1.b09.2.mga7.x86_64/jre/lib/security/java.policy
Dec 14 18:18:01 dadsbox.homegroup [RPM][997]: install java-1.8.0-openjdk-headless-1:1.8.0.232-1.b09.2.mga7.x86_64: failure
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: error: rpmdb: BDB0101 Transaction that opened the DB handle is still active
Dec 14 18:18:01 dadsbox.homegroup dnf[997]: error: db5 error(22) from db->cursor: Invalid argument
Dec 14 18:18:01 dadsbox.homegroup kernel: traps: dnf[997] general protection ip:7f42f52fffe0 sp:7ffdc4941d60 error:0 in libdb-5.3.so (deleted)[7f42f51e0000+1b1000]

The host.conf thing was because there was a host.conf.rpmnew sitting in my /etc directory that removed those directives awhile back, and I never updated it. So I rolled back, updated it, and tried again...crash at the same spot (I didn't collect the log for that one).

So I had removed the one package that dnf pointed out, and lacking any other plan at this point, I said "let's try an online update using urpmi again".

So I did. But, I remembered that there was a comment in the wiki about having to stop a dnf timer, so I just uninstalled dnf as I said I might do do a few posts back.

This time, urpmi did not crash with any funky perl errors. It ran to what it said was completion. And installed 728 packages, and removed 510 packages. Out of 5069 packages that were queued to be installed.

I re-ran it a couple of times, and it insisted it was done.

So, some progress had been made. I booted back into the .iso file and told it to upgrade.

Well, now this worked. Sort of. I set external repositories, told it to upgrade. It installed some packages, and removed some packages, then told me that "X installs failed" (where X varied from 59 down to 3, depending). I then would re-run it, this time not setting up external repositories, and it would get further. Then run it again, setting up external repositories from a different mirror, then again without setting up external repositories.

Over, and over, and over. It took hours. And gradually, I got more than 4000 packages installed. Then it stuck. I still had almost 900 packages to go, and they wouldn't go in.

So, there is a command line console available in the installer on the F2 console. I switched to that, did a chroot into my system, and started running "urpmi --auto-update --allow-force" over and over. (If I just used the --force flag, it didn't work, but allow-force did...and over and over I would tell it yes when it asked me if I wanted to use force).

Finally, all the packages were in. And I rebooted into mageia 7. It promptly hung on the "up-down networking" thing (waiting for the network to come up) and it remained hung there for a timeout period that was more than 5 minutes (and, for the record, my networking in this box is static; I really want to stop ifplugd from running at all...it is very much in my way when I am developing).

Eventually, the box came up. Sort of. No video. Well, that was a driver conflict which I sorted out. Seems Mageia 7 wanted to use nouveau - and was kind of insistent about it even though I have it blacklisted. Now, I have never used the nvidia driver from the repository; I have always gotten my driver from nvidia and installed it. I did that this time, but I had to change my X config scripts because the installation had changed them to use nouveau. In any event, now I do have my GUI and it looks good.

So, then the box gives me a login screen for some other display manager than plasma - icewm I think it is. I then have to start a console as root and restart sddm to get KDE/plasma. I don't have that figured out yet.

And the networking is hosed. The install wrote a linux-default value for the interface name on my WAN ethernet connection (enp...something) and started using it. However, when linux made the switch to this scheme a few years ago, I immediately set some udev rules to give me eth0, eth1, eth2 because I have a lot of scripting that got broken by the change, and I don't agree with the logic behind the change anyway. So, part of the networking was using that enp... value and the rest wanted to find eth0.

Well, I sorted that out.

And the static routes are messed up. The system is writing a route on startup that keeps a vlan I have defined here from working. I have removed that defective route, but at this point I don't know where it came from.

Vmware Workstation started right away, which is good. But presently the networking on vmware workstation (at least, the bridged networking...at this point I have not looked further) is completely broken. At least Vmware Workstation started up; that is the only bright spot in this whole nightmare.

The database behind Amarok won't start...I don't have that figured out yet either.

I repartitioned the SSD on friday, and yesterday I started working on this mess at about 10 AM. I had it finished (with 2 hours off to get some food and drink a couple of much-needed beers) at 3AM this morning.

This upgrade goes down as the ugliest I have experienced in an eternity. And it isn't quite finished yet.
jiml8
 
Posts: 1070
Joined: Jul 7th, '13, 18:09

[solved] Re: update to Mageia 7 went south - nvidia fatal er

Postby rooman » Dec 19th, '19, 17:37

I had the same sort of wild dependency problem in trying to update and finished by doing a clean install of M7 on my new ssd.
Since an update two weeks ago I'm stuck with nouveau driver as the nvidia proprietary driver causes fatal errors, where did you get the file and the .run script please from Nvidia?

I ran the nvidia script from their website 3 times; 1st time I did a silly thing after in drakconf, the 2nd the script complained about resizing the screen and the 3rd all went well. Everything is installed correctly and I've accelerated 3d graphics with a nice little parameter utility included "nvidia-settings".
The basix need was to delete xorg.conf and .Xsession files before.
Last edited by rooman on Dec 22nd, '19, 17:24, edited 1 time in total.
Mageia 6, Asus Z-87-Pro, i5 4670k @4.2, DDR3 16gb, nVidia 760 GTX
rooman
 
Posts: 52
Joined: Apr 20th, '11, 16:43
Location: Lausanne, Switzerland

Re: update to Mageia 7 went south

Postby doktor5000 » Dec 20th, '19, 05:47

I'd suggest you start a separate thread for your issue. And please mention what "fatal errors" you're getting.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 15303
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany


Return to Basic support

Who is online

Users browsing this forum: No registered users and 1 guest

cron