Bug 459030 - RAID units (md), possibly (dmraid) not properly identified by anaconda, fdisk, cfet. al. Possible data loss encouragement when it might be easily avoided by better information presentation.
RAID units (md), possibly (dmraid) not properly identified by anaconda, fdisk...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: AnacondaStorage
  Show dependency treegraph
 
Reported: 2008-08-13 16:13 EDT by c.h.
Modified: 2009-09-03 07:03 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-03 07:03:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description c.h. 2008-08-13 16:13:41 EDT
Description of problem:
RAID volumes not properly identified by anaconda, fdisk, et. al.
I have had disks which were members of a (md) [Fedora software RAID package]
RAID set not identified as such during Fedora's installation program at the points where existing drives / partitions are displayed.
I do not recall that Fedora's fdisk utility identified them as being parts of a (md) RAID set either.

In the case experienced, the entire disk devices were devoted as such, e.g.
mdadm assemble /dev/sda /sdb /sdc .... /dev/md0  or similar.

the mdadm and related utilities were able to determine the RAID UUID and member status of these drives and inform the user that they were members of a particular RAID set via their UUIDs and so on.

It is especially important that a user be made aware of the existing data stored on these drives during installation or at the time a program such as fdisk is run so that the user will not inadvertently delete valuable data.
It is also necessary / useful so that the user will be able to identify the
logical device names corresponding to the members so that they may be properly assembled / maintained / et. al. under the Fedora RAID tools.

I may only assume that (dmraid) [other Fedora sofrware RAID system] discs may also not be clearly identified by these utilities.

It is clearly the intent of these utilities to present identifying information about the data on partitions / discs, thus partition IDs for everything from OS/2 partitions and BSD / Solaris slices are expected to be displayed.
It is inconsistent with that design goal for Fedora disc utilities to not even present such easily determined information relating to commonly used Fedora specific 'formatting' such as (dmraid) / (md) generates.


Version-Release number of selected component (if applicable):

I don't recall what the packages tools like fdisk, cfdisk, disklabel, et. al. belong to.  Please add this bug to the appropriate other packages' lists as appropriate.  If there are Fedora graphical disk management programs other than anaconda, I'd say they should have similar functionality and also be included in the bug context.

How reproducible:

To the best of my recollection it happens all the time with (md) members, and it may well do so with (dmraid) members.

Steps to Reproduce:
1. Make a (md) raid including various drives such as /dev/sda /dev/sdb /dev/sdc
2. Boot into Fedora's installer and see if it tells you they're RAID units.
3. Use fdisk, disklabel, et. al. to see if they identify the usage of them.
  
Actual results:

No information presented as I recall.

Expected results:

"Disk /dev/sda is member #3 of 5 of a (md) RAID assembly UUID xxxxxxx"
"Disk /dev/sdb is member #2 of 4 of a (dmraid) RAID assembly UUID xxxxxx"

Additional info:
Comment 1 Dominic-Olivier Beaudoin 2008-11-16 00:04:33 EST
This may be related to this bug but I tried the DVD Install for Fedora Core 10 Preview and my fakeraid 5 is not detected by anaconda and warns me about all single drives.

I then downloaded the Fedora Core 9 Live CD and I tried to mount my raid array using dmraid and here is the error I got : 

[root@localhost liveuser]# dmraid -ay
ERROR: isw: Could not find disk /dev/sdd in the metadata
ERROR: isw: Could not find disk /dev/sdc in the metadata
ERROR: isw: Could not find disk /dev/sdb in the metadata
ERROR: isw: Could not find disk /dev/sda in the metadata
no raid disks

The array works under Kubuntu 8.10 and I wanted to replace it with FC10 so I expected it would also work.

I am using 4x250GB (/dev/sda to /dev/sdd) in fakeraid 5 and they are mapped as /dev/mapper/isw_dghdhicif_Domoli in Kubuntu 8.10.

If you need further information I will be able to provide more on request.
Comment 2 Bill Nottingham 2008-11-19 00:31:33 EST
Dominic - your bug should be fixed by dmraid-1.0.0.rc15-2. It's unrelated to the prior bug.
Comment 3 Frantisek Hanzlik 2009-03-24 20:16:40 EDT
Same experience - when upgrade Fedora 8 i386 system (root fs, /home and swap on one partitioned disk, and other SW RAID5 md device created from entire disks as above) to Fedora 10 i386,  F10 anaconda not recognize RAID5 disks, says about unreadable partition table and offers their initialization!
mdadm detect RAID and its members correctly:

# mdadm --examine --scan --verbose
ARRAY /dev/md0 level=raid5 num-devices=4 UUID=0db8c483:f6a763d4:097affac:10a28c8c
   devices=/dev/sde,/dev/sdd,/dev/sdc,/dev/sdb
Comment 4 Bug Zapper 2009-06-09 22:27:41 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 Andy Lindeberg 2009-07-13 10:41:45 EDT
For the original complaint: The partitioning code has been almost entirely rewritten for F11. Can you please retest and let us know if the problems you saw are still present?



(In reply to comment #3)
> Same experience - when upgrade Fedora 8 i386 system (root fs, /home and swap on
> one partitioned disk, and other SW RAID5 md device created from entire disks as
> above) to Fedora 10 i386,  F10 anaconda not recognize RAID5 disks, says about
> unreadable partition table and offers their initialization!
> mdadm detect RAID and its members correctly:
> 
> # mdadm --examine --scan --verbose
> ARRAY /dev/md0 level=raid5 num-devices=4
> UUID=0db8c483:f6a763d4:097affac:10a28c8c
>    devices=/dev/sde,/dev/sdd,/dev/sdc,/dev/sdb  

This is also unrelated to the original problem. Please also retest with F11 and file a new bug if your problem is still present.
Comment 6 Bug Zapper 2009-07-14 10:00:55 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.
Comment 7 Bug Zapper 2009-07-15 04:13:03 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.
Comment 8 Joel Andres Granados 2009-09-03 07:02:43 EDT
Lots of work has gone into fedora and fake RAID.  To my knowledge the usual case works as expected.  Feel free to reopen this issue if you find further misbehavior with f12 alpha and later.

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