I tried upgrading a Mandriva 2010.2 x86 installation to Mageia 2 alpha2 via the DVD and was unsuccessful. The problem was that the installer was not able to mount the Mandriva /var partition (due to an issue reported here separately), but continued attempting to install anyway. Needless to say, the lack of /var meant that the Mandriva RPM database was not available and the upgrade was dramatically unsuccessful. It ended up upgrading 100-200 packages (out of ~2000) before declaring completion, and leaving the system in a bootable (surprisingly), but completely unusable state. If any of the required mount points (e.g. /usr, /var, /boot, etc.) could not be mounted, then the installer should immediately error out.
The missing RPM database should really be treated as a separate issue. Even if /var could be mounted, if the RPM database still isn't available (e.g. is corrupted, missing, etc.) when the user specified an upgrade, then the installer should give an error and not continue (or perhaps offer to change the upgrade to a regular install).
CC: (none) => thierry.vignaudSource RPM: (none) => drakx-installer-stage2
assigning to maintainer @ thierry do you need a report.bug of such an install-attempt?
CC: (none) => marja11Assignee: bugsquad => thierry.vignaudSummary: Installer doesn't report an error on upgrade when partitions can't be mounted => Let installer report an error on upgrade when needed partitions can't be mountedSeverity: normal => enhancement
yes. also a link on the other bug report for the failure on mounting /var
Keywords: (none) => NEEDINFO
(In reply to comment #3) > yes. > also a link on the other bug report for the failure on mounting /var @ Dan Can you please reproduce this problem, plug in a usb stick when you start installing, go to tty2 with ctrl+alt+F2 and type: bug and hit enter that'll put report.bug on your usb key (ctrl+alt+F7 will of course take you back to where you came from) please attach report.bug to this report. I just searched for bugs that were reported by you before this one, but didn't find a report that I understand to be about the other issue, so please give the correct link to that report, too Thanks :)
@ Dan, could you please reply to the previous questions? If you won't reply within two weeks from now, I will have to close this bug as OLD. Thank you.
Sorry, my computer is inaccessible for another month and I won't be able to try this until after that. The issue with not being able to mount /var was bug #3807.
== no needinfo ping before march 17th ==
Over a month later :) Please reproduce this problem with the Mga2b2a DVD, plug in a usb stick when you observe /var can't be mounted, go to tty2 with ctrl+alt+F2 and type: bug and hit enter. That'll put report.bug on your usb key (ctrl+alt+F7 will of course take you back to where you came from) please attach report.bug to this report. Instead of doing this, it is also possible to attach /root/drakx/report.bug.gz after install
@ Dan Can you please reply to comment 8 ? You can also wait a few days till the Mga2b3 DVD becomes available, and reply then.
My test computer should be in service again shortly, so I'll try to test the beta 3 DVD and report back.
(In reply to comment #10) > My test computer should be in service again shortly, so I'll try to test the > beta 3 DVD and report back. ping?
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
So someone should try to install with a btrfs or a nilfs2 partition then remove the module from stage1...
Source RPM: drakx-installer-stage2 => mageia-gfxboot-theme
I cannot reproduce that bug in Cauldron. I installed a system with /usr as btrfs, then restarted the install without the btrfs module. The installer will then keep trying mounting /usr, displaying an error dialog each time. It's thus impossible to go further... Logs show "missing module btrfs" and the dialog say "An error occured. Mounting partition foobar in directory /mnt/usr failed". As there was no answer from reporter for monthes, I close this bug
Status: NEW => RESOLVEDResolution: (none) => OLD
Sorry, I only got that machine up and running again two weeks ago, and bug #6180 is preventing me from trying this out again. But, it looks like Thierry's test case indicates this is no longer an issue (unless /var is treated differently from /usr).