I tried upgrading a i586 system from Mageia 2 to Mageia 3 alpha 1 and encountered a failure in the usrmove operation. I followed the instructions on the wiki, and /bin, /sbin, etc. were successfully moved to /usr/... However, /var/lock and /var/run were not. At least, when continuing the upgrade and installing the "filesystem" package, the installation failed with: error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory (and later a similar error for /var/run). Sure enough, /var/lock was a directory containing three subdirectories,lockdev/ lvm/ & subsys/. I had to manually rm -r /var/lock to continue, then move everything from /var/run into /run and then rm -r /var/run. Then I was able to manually install the filesystem package successfully. This /var directory moving is something that looks like it should have been performed by by the usrmove script, but although /bin et. al. were moved and replaced by symlinks, those dirs in /var were still there. Could it be because my /var is on a separate filesystem? Is /var mounted in the ramdisk where the convertfs script runs?
As a side note, the Wiki page at https://wiki.mageia.org/en/Feature:UsrMove doesn't say anything about the current directory when running dracut -f -a convertfs. Presumably, this must be /boot.
how have you upgrade ? with the dvd or online ? was rpm4.9.1.3-2.1 from testing installed in mageia 2 ? btw, upgrade is not currently supported as said in the errata or alpha1 page
CC: (none) => mageiaSource RPM: (none) => systemd
I upgraded from the running Mageia 2 system, but using the DVD as the source. The first thing I did before starting the upgrade was to upgrade urpmi & its dependencies, which installed rpm 4.10.0-11 (I had to force an install of libdb5.3 manually to do this, BTW). I know this upgrade isn't really supported, but someone has to try it to flush stuff like out!
The basic plan for upgrades will be backporting dracut to mga2, then generating a specific upgrade initrd that will do the conversion. This initrd will be told to mount /, /usr and /var, and as such it should work fine. I've just not had time to polish this stuff. So it will be handled, but just not quite yet! Also as far as I'm aware, it should only be the /var/run + /var/lock bits that fail in the conversion, not the rest of the usrmove... but there may have been reasons why this isn't the case!
CC: (none) => thierry.vignaudAssignee: bugsquad => mageia
So, the latest version of the mageia-prepare-update package I've pushed into mga2/core/updates_testing should take care of mounting /var when doing the conversion. It's not entirely tolerant to filesystem changes post-package install (i.e. if you fiddle around which which partition has your /var after installation, you're on your own!), but it should work generally OK. (NB: if you do happen to move stuff, then you have to run /usr/sbin/mageia-prepare-update-dracut-detect-var again and then regenerate your initrds) So this should now work nicely, but it would be nice if people could confirm this (personally, I tried with an ext4 / + swap, and LVM based /usr and /var (separate, but same volume group) with an encrypted /home - it all seemed to work fine for me).
Status: NEW => ASSIGNEDSource RPM: systemd => mageia-prepare-update
Blocks: (none) => 8016
OK, so no confirmation but like I say above this should be fixed now.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
(I only added the tracker bug to not forget pushing the rpm in updates in mga2 :) )
Ahh OK, maybe a good call then :) Will keep it open until we're happy with it and it's pushed :)
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Assigning
Status: REOPENED => ASSIGNED
Summary: /usrmove silently fails if /var is on a separate partition => /usrmove silently fails if /var is on a separate partition (mageia-prepare-update for mga2)
Summary: /usrmove silently fails if /var is on a separate partition (mageia-prepare-update for mga2) => /usrmove silently fails if /var is on a separate partition (mageia-prepare-upgrade for mga2)Source RPM: mageia-prepare-update => mageia-prepare-upgrade
Priority: Normal => release_blocker
Hi Colin, what is the status of this bug? Was it pushed to mga2?
CC: (none) => pierre-malo.denielou
Not pushed yet. It will be when we release, but until that point it remains in testing and thus this bug stays open. It's all ready to go, but this bug stays open to ensure we don't forget. In terms of triaging, it can be ignored :) However, in order to increase clarity, I've created bug #9744 to act as a reminder. Therefore I close this bug (FWIW I did a test over the weekend with this disk layout (actually far more complex than this) and it this part of it all worked fine).