Red Hat Bugzilla – Bug 447729
Drive identification / management / initialization is just unusable in many cases; data loss can easily result.
Last modified: 2009-07-14 10:59:27 EDT
Description of problem:
During the install the following dialog occurs on a couple of occasions:
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):
Steps to Reproduce:
Don't ever do this lacking context to indicate what devices / partitions are
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
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.
Created attachment 306247 [details]
Created attachment 306248 [details]
Created attachment 306251 [details]
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:
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.