Page 1 of 1

[SOLVED] unable to convert filesystem prior to upgrade

PostPosted: Jun 17th, '13, 13:09
by magfan
I tried to upgrade from Mageia 2 to Mageia 3 with a DVD following the instructions in "Using the Mageia 3 DVD to Upgrade" https://wiki.mageia.org/en/Mageia_3_Release_Notes#Using_the_Mageia_3_DVD_to_Upgrade. But when the installation routine checks for packages to upgrade the whole procedure stops with the error message "unable to convert filesystem prior to upgrade". What can I do? The harddisk is a hardware RAID with several partitions on it. All partitions are ext4 except for swap.

Re: unable to convert filesystem prior to upgrade

PostPosted: Jun 17th, '13, 15:25
by oj
I haven't done this (yet) but my understanding is the /usr and /var folders are converted into symlinks. You normally have to be root to make file system changes outside of your /home. Have you run the prepare app as root?

Re: unable to convert filesystem prior to upgrade

PostPosted: Jun 17th, '13, 15:44
by magfan
oj wrote:I haven't done this (yet) but my understanding is the /usr and /var folders are converted into symlinks. You normally have to be root to make file system changes outside of your /home. Have you run the prepare app as root?


No, I did not run it at all because it belongs to "Upgrading via the Internet" which does not work if you are behind a password protected firewall. You can define proxy settings during the installation or upgrade process - but no proxy user / password. That is the reason why I have to use a DVD.

Re: unable to convert filesystem prior to upgrade

PostPosted: Jun 17th, '13, 20:23
by doktor5000
Can you please show a
Code: Select all
ls -al /
from the current system state?
Also, during installation when you got that error, have you switched to the other 3 tty's and had a look for the verbose messages? That will maybe give a hint what the cause of this problem is.

Anyways, I'd say report that as a bug, after searching if it hasn't been reported yet already: https://wiki.mageia.org/en/How_to_report_a_bug_properly
You can assign it to Colin Guthrie, who implemented the major part of the under-the-hood stuff for the UsrMove.

Re: unable to convert filesystem prior to upgrade

PostPosted: Jun 18th, '13, 08:06
by magfan
doktor5000 wrote:Can you please show a
Code: Select all
ls -al /
from the current system state?

See attachment ls_al.txt.

doktor5000 wrote:Also, during installation when you got that error, have you switched to the other 3 tty's and had a look for the verbose messages? That will maybe give a hint what the cause of this problem is.

Yes, I could switch to other ttys but I do not know how to catch messages from there to show them in this posting. I have to save these messages somehow because during the installation process there is no network connection available.

Re: unable to convert filesystem prior to upgrade

PostPosted: Jun 18th, '13, 20:08
by doktor5000
So conversion has not taken place.

It should look like this afterwards:

Code: Select all
[doktor5000@Mageia3 ~]$ find / -maxdepth 1 -type l -exec ls -al {} \;
lrwxrwxrwx 1 root root 9 Mai 19 12:56 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 7 Mai 19 12:56 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 Mai 19 12:56 /lib -> usr/lib
lrwxrwxrwx 1 root root 8 Mai 19 12:56 /sbin -> usr/sbin


For the messages on the tty's, that was just if you want to take a look for yourself, to get a glimpse
at the possible cause or related stuff. You should probably open a bugreport.

There are some logs for the installation under /root/drakx, but seems not for the installer stage where the problem occurs.

Re: unable to convert filesystem prior to upgrade

PostPosted: Jun 26th, '13, 10:39
by magfan
The problem could be solved. One of several external packages was partly installed in /bin. This caused some conflicts which could not be resolved during "usrmove" (see also the errata page: https://forums.mageia.org/en/viewtopic.php?f=7&t=5334, bug 10581). When I first read this errata issue I did not get the meaning because it was not mentioned that only external programs which are (partly) intalled in /bin, /lib, /lib64 and /sbin could cause this failure. Not external programs in general. Anyway, after removing that external program from /bin the upgrade went very smoothly. It turned out to be the easiest and cleanest upgrade after a long history of upgrades (mdv10 -> mdv10.1 -> mdv10.2 -> mga1 -> mga2 -> mga3) with numerous hardware and network issues except for the last upgrade.