(1) After 'analysing ide' text box, in the case of multiple disks with a non-standard partitioning arrangement (as in isw_ raid members) a dialogue box is raised 'Partitioning is too complex for me. Do you want to lose all partitions?'. This is too big a choice for the user to make at this point. The message should read something like: "Partitioning on this disk must be resolved manually. It could be a pre-existing RAID member. If you want to use this disk, exit now and repartition manually. If you want to ignore this disk for the time being press No." Better still, resolution of bug 11105 should deal with this message, as it will be issued most likely on encountering a pre-existing isw_ raid array member which must be defined before installation of any OS at all. (2) The 'Auto Allocate' button is very dangerous. Having got past the warning (1) above, one clicks to an empty drive (if there is one) on the partitioner dialogue, and assumes that this option will allocate all necessary partitions on that drive. Not So! The option will find space on any drive (including the ones it was told not to touch, such as the 'partitioning is too complex' disks, and change their partitioning causing mayhem. The only warning is the dialogue box "Partition table of (eg) sdb will be written to disk" y/n. If there is more than one hard disk on the system, the Auto-allocate function should only act on the disk currently selected in the partitioner (eg sdd). Users may wish to have several os installed on separate drives with some unused space left over, and/or have a pre-existing isw_ (firmware fake raid) to move data between them. (3) The proposal for installing a proprietary display (NVIDIA in my case) driver is a very nice touch. I am sick of removing nouveau manually and then replacing it with the NVIDIA linux driver with some other distributions. Thank you! (4) In partitioning a new gpt disk, the proposal for the first partition to be the EFI partition is a nice touch. However, the proposed mount point is generally wrong, looking something like /media/win_c, where it should always be /boot/EFI. Indeed, if the proposal is accepted as is, one gets an error box saying that the mount-point should be that. (5) Once a partition is mounted, using the 'Mount' button from the expert mode, it is impossible to unmount, if one has made a mistake is specififying the mount point for example. There is also no 'cancel/abort' button anytime after entering the partitioner. Using the power switch each time is a bit brutal. (6) Each partition must be mounted with the 'mount' button (expert mode, not visible by default) before the user can move forward. It is reasonable for the partitioner to do this automatically, especially since the unmount button is ineffective. (7) Mageia produces the bootloader grub menu. It seems to do this correctly in the presence of other OSs, but the "Mageia" option results in a black screen (the grub line seems to point to the right partition). A work-around was to go back to the default Linux system (not Mageia) and regenerate grub. This menu automatically replaced the Mageia grub with (suse) grub, with the Mageia option working correctly. Note that resolution of bug 11105 may impact on how some of these point might be dealt with. Reproducible: Steps to Reproduce:
The behaviour of auto-allocate described in (2) above, after further testing, was seen to depend on the skill mode chosen (normal/expert). When 'expert' mode is chosen, together with auto-allocate, a menu is tripped asking the user to state the use of the machine (simple,server or +/usr). After email discussion with Remi Verschelde, it was felt that this menu served no real purpose, since auto-allocate would not generally be used in building a server and was dangerous in this context while /usr could be added by any user as a separate partition. The key request in this bug report is to remove the supplementary (simple/server/usr) menu, and to allow auto-allocate to be available in 'normal' (ie not expert) mode only. The logic of auto-allocate should be checked to ensure that 'auto-allocate' will never operate on any disc other than the one chosen by the user.. The other points are smaller annoyances whose removal would lead to a polished user experience.
After further testing, I think that the user level is not relevant. I selected custom partioning -> sde and pressed 'use entire disk'. Nothing much seemed to happen. I then looked at sdc, and found that it had been re-partitioned as per the auto-allocate formula, and the new partition table had been written to disk, causing major damage to other existing systems. I suspect this bug is not directly related to EFI changes, but has been lurking for a while. Hence, the following text summarises this bug report: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv In a multi disk hardware installation, the partitioner included with the MGA5B3.4 behaves unpredicatbly. Specifically, if the user selects a particular disk for partitioning, and invokes either the 'use entire disk' or 'auto-allocate', the partitioner can decide to use a disk other than the one selected by the user, without warning. The 'use entire disk' is particularly dangerous as it does the damage immediately and with no prior warning of any kind. The only safe way in multi-disk systems is to do everything manually, with the othe options locked out. I would be very uncomfortable releasing a new Mageia that lacks a resolution of this bug for general use. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Priority: Normal => release_blockerSeverity: enhancement => major
Your comments are very useful and may help to improve a lot interface. But we are very near from final release. The tool is not perfect and may be improved. This will be a perfect report for Mageia 6 specifications :)
Priority: release_blocker => HighCC: (none) => ennael1
As you say, the release date is too close to start changing a critical component where the problem affects only a small proportion of users. To prevent accidents, though, 'errata' for the release should make it very clear which partitioner options to avoid for those wanting to install Mageia 5 on machines that include multiple disks and pre-existing operating systems.
Summary: Suggested safety and useability improvements for installer (partitioner) in Mageia 5 Beta 3 Release 2(Classical iso) => Suggested safety and usability improvements for installer (partitioner) in Mga5 Beta 3 Release 2(Classical iso)
An advisory message for this issue has been placed in Wiki - Mageia5 - Errata. Please review and edit as necessary.
CC: (none) => eeeemail
CC: (none) => wilcal.int
Vladimir, could you create separate bugs for the issues you encountered, or at least for the _huge_ issue with the partitioner trying to use the wrong disk when you choose "auto-allocate" or "use entire disk"? As Anne said, the current bug report will be a nice basis for the mga6 specifications (and you did name it "Suggested ... improvements", but there are a couple real bugs in there that would deserve specific attention.
CC: (none) => remi
Item 3 in original description is not a bug. I will create separate bugs for items 4, 5, 6, 7 and advise bug numbers here and by email once done.
CC: (none) => doktor5000
Have you create those bugs?
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaudSummary: Suggested safety and usability improvements for installer (partitioner) in Mga5 Beta 3 Release 2(Classical iso) => Suggested safety and usability improvements for partitioner in Mga5 B3 (Classical installer)
I had, they were discussed and mostly closed. Now, clicking on 'My Bugs' only returns this one? Are closed bugs archived off line, or am I missing something? I haven't kept a separate list.
IIUC the "My bugs" link only searches for bugs with Status = one of UNCONFIRMED, NEW, ASSIGNED, REOPENED
(In reply to James Kerr from comment #10) > IIUC the "My bugs" link only searches for bugs with Status = one of > UNCONFIRMED, NEW, ASSIGNED, REOPENED Thank you for letting me know.
Closing this one then.
Status: NEW => RESOLVEDResolution: (none) => MOVED