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: 1041
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: 1192
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: 1041
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: 15240
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: 1041
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: 1041
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: 531
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: 1041
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


Return to Basic support

Who is online

Users browsing this forum: MSN [Bot] and 1 guest

cron