Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Drive identification / management / initialization is just unusable in many cases; data loss can easily result.|
|Product:||[Fedora] Fedora||Reporter:||c.h. <fc6_req>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-07-14 10:59:27 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description c.h. 2008-05-21 09:35:36 EDT
Description of problem: During the install the following dialog occurs on a couple of occasions: WARNING The partition table on device mapper/mpath0 was unreadable. To create new partitions it must by initialized, causing the loss of ALL DATA on this drive. This operation will override any previous installation choices about which drives to ignore. Would you like to initialize this drive, erasing ALL DATA? Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Don't ever do this lacking context to indicate what devices / partitions are actually relevant. Additional info: I believe this is *very* inappropriate UI / process design which at best is confusing, uselessly devoid of information, and frustrating to the user, and at worst unnecessarily risks tragic and unexpected data loss. These dialogs are presented as the FIRST thing the user sees concerning storage management during the install process. There is NO possibility to get any explanation as to WHICH actual drives / devices / partitions are unreadable. Even when it sometimes tells you a logical device name like "sde", still, the information is USELESS to the end user since they cannot POSSIBLY find out based on the options / information available WHICH of their physical drives is mapped as "sde" or whatever. When the dialog says something like "mapper/mpath0" it is even worse because that is even more completely dissociated from any correlation to particular partitions / devices / drives the user can identify and correlate with the question. In many situations it is quite possible / probable that the user could have multiple drives and/or multiple partitions, some may be blank or suitable for reinitialization, whereas others may have data on them that is simply in a format that Fedora does not recognize and hence presents such anaconda dialogs. In my present case I had 5 drives installed, one of which wasn't blank (had ext3 + LVM etc), but was intended to be reformatted for F9. Another drive had an ext3 partition with valuable data that must not be altered. Another two drives were part of a RAID set which shouldn't be touched by Fedora. And another drive was in fact blank, but still wasn't intended to be used by Fedora. On seeing the dialog about mapper/mpath0 initialization there was simply NO possible way to know which drives / partitions would have been at risk of being reformatted if I had permitted the initialization in question. If I did not permit it, I would not be able to see those drives / devices / partitions AT ALL in the subsequent installation partitioning screens, thus potentially depriving me of the ability to manage / identify / utilize those resources if I wanted to during the install. Furthermore, even at the subsequent installation partitioning / device selection screen, the actual devices / drives are not precisely identified. At best they're called "sde", "sdc", et. al. but still the user has little information as to WHICH physical drive / device that refers to except possibly a generic drive model number which is not sufficiently useful if only for the reason that one may have several identical model (e.g WD1200JB) drives (sda, sdb, sdc, sdd), and only SOME of those should be initialized while others may contain data that is valuable even if Fedora doesn't recognize the partitioning/formatting (e.g. RAID member, encrypted partion / drive, raw database drive, etc.). The only fully useful remedy to these problems would be to NEVER present a dialog / menu / screen / process concerning a drive / partition if the partition / drive is not precisely identified in full detail -- which drive model, which serial number, which logical device name, what partitioning / labeling / formatting is detected on it. Especially one must not be asked to initialize and lose all data on a device when that particular device can't even be identified by the user based on the given information! Even going to the extent of letting the user look at the actual contents (hex+ascii dump / search) of a drive having no recognized partitions would not be unreasonable in that it would help someone verify that their selected drive is blank as expected or whatever. Allowing the user to start an access test of a particular drive (seek the head for a minute, turn on the I/O LED, etc.) would also help them positively identify which physical drive(s) corresponds to a logical device. But at the very least, I'd certainly hope for Model Number + Serial Number since at least the user has a chance to see those on the drive labels and thus know which drives are which during an install or recovery or whatever.
Comment 4 Bug Zapper 2009-06-09 21:03:44 EDT
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Bug Zapper 2009-07-14 10:59:27 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.