Bug 447729 - Drive identification / management / initialization is just unusable in many cases; data loss can easily result.
Summary: Drive identification / management / initialization is just unusable in many c...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: AnacondaStorage
TreeView+ depends on / blocked
Reported: 2008-05-21 13:35 UTC by c.h.
Modified: 2009-07-14 14:59 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-14 14:59:27 UTC

Attachments (Terms of Use)
screen shot (1.80 MB, image/jpeg)
2008-05-21 13:37 UTC, c.h.
no flags Details
screen shot (2.53 MB, image/jpeg)
2008-05-21 13:39 UTC, c.h.
no flags Details
screen shot (2.44 MB, image/jpeg)
2008-05-21 13:42 UTC, c.h.
no flags Details

Description c.h. 2008-05-21 13:35:36 UTC
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):

How reproducible:


Steps to Reproduce:
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 1 c.h. 2008-05-21 13:37:27 UTC
Created attachment 306247 [details]
screen shot

Comment 2 c.h. 2008-05-21 13:39:38 UTC
Created attachment 306248 [details]
screen shot

Comment 3 c.h. 2008-05-21 13:42:09 UTC
Created attachment 306251 [details]
screen shot

Comment 4 Bug Zapper 2009-06-10 01:03:44 UTC
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: 

Comment 5 Bug Zapper 2009-07-14 14:59:27 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.