Bug 7451

Summary:	/usrmove silently fails if /var is on a separate partition (mageia-prepare-upgrade for mga2)
Product:	Mageia	Reporter:	Dan Fandrich <dan>
Component:	Installer	Assignee:	Colin Guthrie <mageia>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	release_blocker	CC:	mageia, pmdenielou, thierry.vignaud
Version:	Cauldron
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	mageia-prepare-upgrade	CVE:
Status comment:
Bug Depends on:
Bug Blocks:	8016

Description Dan Fandrich 2012-09-11 20:57:50 CEST

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?

Comment 1 Dan Fandrich 2012-09-11 21:01:12 CEST

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.

Comment 2 Manuel Hiebel 2012-09-11 21:40:16 CEST

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) => mageia
Source RPM: (none) => systemd

Comment 3 Dan Fandrich 2012-09-11 22:20:48 CEST

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!

Comment 4 Colin Guthrie 2012-09-12 09:57:20 CEST

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!

Thierry Vignaud 2012-12-11 16:21:33 CET

CC: (none) => thierry.vignaud
Assignee: bugsquad => mageia

Comment 5 Colin Guthrie 2012-12-11 16:27:06 CET

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 => ASSIGNED
Source RPM: systemd => mageia-prepare-update

Manuel Hiebel 2013-01-27 00:18:43 CET

Blocks: (none) => 8016

Comment 6 Colin Guthrie 2013-01-27 10:19:02 CET

OK, so no confirmation but like I say above this should be fixed now.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Comment 7 Manuel Hiebel 2013-01-27 10:34:43 CET

(I only added the tracker bug to not forget pushing the rpm in updates in mga2 :) )

Comment 8 Colin Guthrie 2013-01-27 10:43:06 CET

Ahh OK, maybe a good call then :) Will keep it open until we're happy with it and it's pushed :)

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Comment 9 Colin Guthrie 2013-01-27 10:43:30 CET

Assigning

Status: REOPENED => ASSIGNED

Manuel Hiebel 2013-01-28 16:07:20 CET

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)

Manuel Hiebel 2013-02-15 22:21:34 CET

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

Manuel Hiebel 2013-04-13 19:35:05 CEST

Priority: Normal => release_blocker

Comment 10 Malo Deniélou 2013-04-15 18:03:24 CEST

Hi Colin, what is the status of this bug? Was it pushed to mga2?

CC: (none) => pierre-malo.denielou

Comment 11 Colin Guthrie 2013-04-15 18:53:59 CEST

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).

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED