Mageia forum

This is how I upgrade to next version of Mageia using the command line. I believe that in this way possible problems are minimized, and I have tried it on various installations to upgrade from 5 to 6 and from 6 to 7.

There have been various hints on the existing Mageia wiki and forum that I have followed, but I found that they needed to be adapted to systemd.

Anyway, this may prove useful to someone, so here it is. Corrections and additions are welcome!

All commands are entered as root. Backup prior to anything is always recommended.

1. To start with, to enter text mode type:

Code: Select all

systemctl set-default multi-user.target

and reboot

Code: Select all

shutdown -r

or

Code: Select all

shutdown -r now

if you want to reboot instantly.

Remember that after reboot you have to login as root on the command prompt!

2. To enter back into graphics mode, type

Code: Select all

systemctl set-default graphical.target

and reboot

Code: Select all

shutdown -r

If for some reason this doesn't work (which may happen), don't panic! Type

Code: Select all

ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

and reboot.

3. Continuing from step 1, remove existing update media

Code: Select all

urpmi.removemedia -a

and add the correct update media of the new Mageia version as explained in https://wiki.mageia.org/en/URPMI#Adding ... stribution

For a local mirror, you can use something like

Code: Select all

urpmi.addmedia --distrib HD file://mnt/hd/Local_Mirror/7/x86_64

where 7 is the Mageia version and x86_64 the chosen architecture.

Check if everything is OK with

Code: Select all

urpmq --list-media active

4. This step is optional, and I know there are differing views on its safety, but you can take the opportunity to remove previous orphaned packages.

First a test run to check what will get removed

Code: Select all

urpme --auto-orphans --test

and then the actual run

Code: Select all

urpme --auto-orphans

5. Now for the actual upgrade process. First a test run to check for possible problems

Code: Select all

urpmi --replacefiles --auto-update --auto --test

and then the actual run

Code: Select all

urpmi --replacefiles --auto-update --auto

6. After waiting for the upgrade to finish (which may take some time depending on the speed of the media), follow step 2 so that you can reboot into graphics mode and then reboot with

Code: Select all

shutdown -r

Hopefully, now you are greeted with with upgraded version.

Maybe, instead of rebooting into graphics mode, you want to repeat the process so that

Code: Select all

urpmi --replacefiles --auto-update --auto

fills in any packaged omitted in the first run.

Also, in case the upgrade process hangs and you have to reboot, you can try to start it again. I had this happen and restarting the upgrade completed without any problems.

The advantage of this process is that you have less interference from various running processes as it often the case in a running graphical environment.

just an addendum (or 2):

be sure to have sufficient spare space in root (/) partition for all your downloaded .rpms.
generally, /swap will not be used to store downloaded and yet to be installed .rpms.
(otherwise things will come to a grinding halt!)

also, check how many kernels and associated files you have.
you can safely remove all but your current one(s) before your upgrade.

FWIW, instead of messing around with systemctl set-default, why not simply change to runlevel 3 without rebooting?

Code: Select all

systemctl isolate multi-user.target

benmc wrote:just an addendum (or 2):

be sure to have sufficient spare space in root (/) partition for all your downloaded .rpms.
generally, /swap will not be used to store downloaded and yet to be installed .rpms.
(otherwise things will come to a grinding halt!)

also, check how many kernels and associated files you have.
you can safely remove all but your current one(s) before your upgrade.

I am not 100% sure, but I think that running with the --test switch first can notify you of insufficient space (and other possible problems).

Removing orphaned packages removes old kernel versions and associated packages like those related to virtualbox. Of course, you have to trust the automatic process, which I understand might occasionally cause problems on its own.

doktor5000 wrote:FWIW, instead of messing around with systemctl set-default, why not simply change to runlevel 3 without rebooting?

Code: Select all

systemctl isolate multi-user.target

I wasn't aware of that option, so next time I will give it a try!

johnpenguin wrote:I wasn't aware of that option, so next time I will give it a try!

FWIW, it should also still be possible to simply run init 3 or telinit 3, which does the same thing.