Bug 10581 - searching for packages to upgrade fails during DVD upgrade (mga2 -> mga3)
Summary: searching for packages to upgrade fails during DVD upgrade (mga2 -> mga3)
Status: RESOLVED WORKSFORME
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: 3
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-21 09:36 CEST by Markus Mertens
Modified: 2013-06-26 11:07 CEST (History)
1 user (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
ddebug.log from failed DVD upgrade mga2 -> mga3 (950.21 KB, text/plain)
2013-06-24 08:43 CEST, Markus Mertens
Details

Description Markus Mertens 2013-06-21 09:36:07 CEST
Description of problem:

I tried to upgrade from Mageia 2 to Mageia 3 with a DVD following the instructions in "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". From one console (F2) I copied the following messages:

* step "choosePackages" took: 0:02:29
* step `choosePackges' finished
* starting step `installPackages'
* perImageAppend is now nokmsboot resume=UUID=...
* merging modules::modprobe_conf
* converting filesystem for usrmove
* running: /usr/lib/dracut/modules.d/30convertfs/convertfs.sh /mnt
* step "installPackages" took: 0:00:01
* error: Unable to convert filesystem prior to upgrade. Check ddebug.log for details at /usr/lib/libDrakX/install/steps.pm line 344.

The harddisk is a hardware LSI RAID 10 with several partitions on it (/boot, /, swap, /tmp, /home, /data1, /data2). All partitions are ext4 except for swap. The partitions /data1 and /data2 are shared via NFS.

The upgrade worked on two laptops without any problems. That is why I assume it has to do with the RAID.


How reproducible:

Always.


Steps to Reproduce:

1. Boot from installation DVD
2. Choose "upgrade" when prompted
3. Continue with the upgrade process
4. After searching for installed packages the installation process stops

It is not a critical bug, because the existing system will not be changed. But it is a major bug, because an installation DVD is the only possibility to upgrade a system behind a password protected firewall.


Reproducible: 

Steps to Reproduce:
Remco Rijnders 2013-06-21 10:31:59 CEST

CC: (none) => mageia

Comment 1 Remco Rijnders 2013-06-21 10:33:05 CEST
@coling: Colin, do you have any ideas on this? (I assume it might have to do with the /usr /run conversion).
Comment 2 Colin Guthrie 2013-06-21 16:22:30 CEST
Well it could be related to the usr move script but it could also be that the partitions are simply not mounted properly on /mnt when it's run, in which case the upgrade would fail anyway.


Quite what went wrong it's hard to tell. As /, /usr and /var are on the same partition, it should have been quite smooth, but it's really hard to say without more log.

I presume the "old" setup is still working fine  i.e. nothing broke specifically?

Did you manage to save the ddebug.log file mentioned? It would likely explain things in more depth.

If you like, you can run the script it mentioned manually from F2. If the filesystem is already converted then the script should detect that and (hopefully) succeed.

All that's needed is for the raid's / to be mounted on /mnt (which the installer should setup for you but this is perhaps where things are failing) and run the script as per the debug output.

So check 1 would be "is the raid stuff active and mounted on /mnt" if that's the case, then try running the script manually and see what kind of output you get which migh give some clues.
Comment 3 Markus Mertens 2013-06-24 08:43:11 CEST
Created attachment 4162 [details]
ddebug.log from failed DVD upgrade mga2 -> mga3
Comment 4 Colin Guthrie 2013-06-24 09:49:44 CEST
Comment on attachment 4162 [details]
ddebug.log from failed DVD upgrade mga2 -> mga3

OK, so the error is:

> cp: cannot overwrite non-directory â/mnt/usr/bin.usrmove-new/javaâ with directory â/mnt/bin/javaâ

Seems you have a folder called /bin/java on your machine.

Looking via urpmf output this folder does not exist in any packages:

> [colin@mga2 ~]$ urpmf ^/bin/java
> [colin@mga2 ~]$ 

So I can only presume that this folder was created by yourself or some other third party RPM.

I suggest you resolve this problem first and then re-attempt the upgrade.
Comment 5 Markus Mertens 2013-06-24 12:29:27 CEST
Great! Removing / uninstalling that java directory solved the problem. Thanks a lot!
Comment 6 Colin Guthrie 2013-06-24 15:57:02 CEST
Nice :)

You you know where that folder came from? If it's a third party RPM or other packaging format, we can probably close this bug, otherwise we may have to do something about it.

Of course the error could have been much more descriptive, but as it's in the installer there is not much we can do now to make it better (and I suspect there are not toooooo many people affected otherwise I would have heard more people shouting at me :D).
Comment 7 Markus Mertens 2013-06-24 16:21:37 CEST
It was an external package from sun (java 1.6.0_19) which is not used any more on this system. So, I could easily remove it.

Maybe this rare problem is worth just a short remark in the "upgrade tutorials"?
Comment 8 Colin Guthrie 2013-06-24 16:25:16 CEST
Actually, looking now, it appears it was already mentioned:

https://wiki.mageia.org/en/Mageia_3_Errata#Upgrade_Issues

I've now also added a reference to this bug.

Thanks for your help and understanding here. All the best.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME

Comment 9 Markus Mertens 2013-06-25 08:18:54 CEST
Yes, now I understand that errata issue and I confess I read it before. But there are several external software packages installed on my system. Mainly in /opt. For a better understanding it could be explicitely mentioned that external software packages which are installed /bin will break the upgrade.
Comment 10 Colin Guthrie 2013-06-25 09:57:17 CEST
Well, it's not all external software packages in /bin, just those that conflict with files/folders that exist in /usr/bin. (same is true for /sbin, /lib and /lib64 and their /usr equivalents)

But if you have time please do feel free to update the notes and wiki. Any help to make them better is much appreciated! :)
Comment 11 Markus Mertens 2013-06-26 11:07:03 CEST
Thanks again for your help. I have just edited the errata page.

Note You need to log in before you can comment on or make changes to this bug.