This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 499733 - Anaconda ignores disks with incomplete BIOS RAID metadata -- linux nodmraid is ineffective
Anaconda ignores disks with incomplete BIOS RAID metadata -- linux nodmraid i...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 501814 505488 506654 508554 515129 526453 528865 (view as bug list)
Depends On:
Blocks: 513462
  Show dependency treegraph
 
Reported: 2009-05-07 15:49 EDT by Daniel Duggan
Modified: 2013-01-13 08:19 EST (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-16 14:47:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/tmp/anaconda.log from the failed installation attempt (3.83 KB, text/plain)
2009-06-13 07:13 EDT, Tore Anderson
no flags Details
/tmp/storage.log from the failed installation attempt (6.61 KB, text/plain)
2009-06-13 07:13 EDT, Tore Anderson
no flags Details
dmesg output from the failed installation attempt (15.11 KB, text/plain)
2009-06-13 07:14 EDT, Tore Anderson
no flags Details
/proc/partitions from the failed installation attempt (327 bytes, text/plain)
2009-06-13 07:14 EDT, Tore Anderson
no flags Details

  None (edit)
Description Daniel Duggan 2009-05-07 15:49:40 EDT
Description of problem:

Unable to Install Fedora 11-Preview x86_64 DVD and or the Live CD version
Anaconda will not recognize individual SATA11 drives -- instead it sees/displays only 
Devicemapper (software raid)
Tried installing with option
linux nodmraid
This had no effect (worked with previous F10..F9 etc.)

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

Fedora 11-Preview x86_64

How reproducible:

100 %

Steps to Reproduce:

1.Boot from the Installation Media 
2.Hit the tab button and type and enter linux nodmraid
3.
  
Actual results:
No available individual SATA11 drives shown -- only Devicemapper
(software raid)

Expected results:
/dev/sda
/dev/sdb
/dev/sdc
/dev/sdd

should be available to anaconda and the installation process

Additional info:

Motherboard is an ASUS P5K-E with the latest BIOS
All drives are SATA11 Seagate drives
The onboard raid has been disabled.

F9 and F10 both installed on the same machine without issue, using the
linux nodmraid 
boot option
Comment 1 Bob Tyler 2009-05-21 12:39:45 EDT
can we adjust the priority? I have two systems on which the beta and preview iso's wont recognize my sata drives (actually anaconda thinks they are part of a dmraid configuration....sounds like we broke one to fix another!!) It really would have been nice to have participated in beta & preview test!!!!
Comment 2 Chris Lumens 2009-05-29 11:18:22 EDT
Can you attach /tmp/storage.log and /tmp/anaconda.log from when you attempt an install with nodmraid given?
Comment 3 Bob Tyler 2009-06-01 09:24:03 EDT
not sure how to attach same. ctl+alt+pf2 shows anaconda 11.5.0.47 complaining about dev/sdb pdc & isw formats found (using isw) followed by error on isw device for RAID00 raid set isw_eifaajeie_RAID00. this followed by dev sda (samemsg)....I just deleted all partitions on these drives usin gparted. you need to teach anaconda to stop assuming the devices are %^*&#@ raid!!
Comment 4 Bob Tyler 2009-06-01 09:27:07 EDT
There is a dump in 499321 from a preupgrade attempt on same system
Comment 5 Daniel Duggan 2009-06-01 16:35:32 EDT
(In reply to comment #2)
> Can you attach /tmp/storage.log and /tmp/anaconda.log from when you attempt an
> install with nodmraid given?  

(In reply to comment #2)
> Can you attach /tmp/storage.log and /tmp/anaconda.log from when you attempt an
> install with nodmraid given?  

If you can provide me with the instructions as to how I can get those two logs I will attach them as soon as possible.

Thanks
Comment 6 Bob Tyler 2009-06-02 18:39:58 EDT
one final attempt proved fruitfull thanks to Luckyy at FedoraForums. When anaconda posted msg about no valid devices found, did ctrl+alt+ pf1 and found same msgs about pdc isw formats on sda & sdb. think ctrl+alt+pf2 got me to prompt screen, where i entered dmraid -r -E several time to clean all errant formats on sda and sdb....reboot produced successfull install. i have no idea what pdc and isw formatts are, but it sure would have been nice if gparted had cleaned them up. would like some additional info if available.
Comment 7 Bug Zapper 2009-06-09 11:24:11 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Tore Anderson 2009-06-13 07:12:33 EDT
I've had the same problems when attempting to install F11 x86 on my single-drive system - when getting to the storage configuration step, the drive is nowhere to be seen.  The drive (and its partitions) is detected by the kernel, but the log messages seems to indicate that Anaconda erroneously detects it as part of a dmraid array.  It is not, and has never been either.  I'm not used to the "dmraid" command, but I think the drive does not detect the drive as being part of any array:

[root@wrath ~]# dmraid -r -D /dev/sda
ERROR: pdc: identifying /dev/sda, magic_0: 0x4d4705cb/0xa012623, magic_1: 0x42e3d4e/0x97741f00, total_disks: 255
no raid disks and with names: "/dev/sda"

I had no such problems when installing F10 on the same hardware.

I'll attach /tmp/anaconda.log, /tmp/storage.log, /proc/partitions, and the output from "dmesg" after having clicked my way (just next-next-next, not changing any defaults) to the storage configuration setup.

I will try booting with "nodmraid" and if that doesn't help, "dmraid -r -E /dev/sda", and report if it did the trick or not.
Comment 9 Tore Anderson 2009-06-13 07:13:14 EDT
Created attachment 347734 [details]
/tmp/anaconda.log from the failed installation attempt
Comment 10 Tore Anderson 2009-06-13 07:13:43 EDT
Created attachment 347735 [details]
/tmp/storage.log from the failed installation attempt
Comment 11 Tore Anderson 2009-06-13 07:14:14 EDT
Created attachment 347736 [details]
dmesg output from the failed installation attempt
Comment 12 Tore Anderson 2009-06-13 07:14:39 EDT
Created attachment 347737 [details]
/proc/partitions from the failed installation attempt
Comment 13 Tore Anderson 2009-06-13 07:38:20 EDT
Booting with "nodmraid" didn't help, and "dmraid -r -E /dev/sda" doesn't seem to help:

[root@wrath ~]# dmraid -r -E /dev/sda
ERROR: pdc: identifying /dev/sda, magic_0: 0x4d4705cb/0xa012623, magic_1: 0x42e3d4e/0x97741f00, total_disks: 255
no raid disks and with names: "/dev/sda"

There doesn't appear to be possible to install F11 on this machine, but I'll keep trying to figure something out.

Tore
Comment 14 Yasin Gedik 2009-06-14 08:30:50 EDT
Hi all,

I am having the same issue. I have two identical Sata disks and they are not configured to be raid. I checked bios and raid is disabled for sure.
When I choose custom layout, partitions in first disk are correctly displayed but second disk is read as raw. First disk contains a windows partiton.

My motherboard is Asus p4p800.

Has anyone found a workaround?

Thanks,

Yasin
Comment 15 Tore Anderson 2009-06-14 12:55:34 EDT
I made it work by writing zeroes on the last few MB of the problematic harddrive (using dd).  After that Anaconda/dmraid no longer believed it to be part of a dmraid array, and I could install normally.

Tore
Comment 16 Nils Hammar 2009-06-19 05:22:41 EDT
*** Bug 506654 has been marked as a duplicate of this bug. ***
Comment 17 Nils Hammar 2009-06-19 05:25:22 EDT
Wouldn't it be possible to actually ASK the installer if it's right that the disks found are part of a RAID system or not.

This would have saved a lot of pain.
Comment 18 Bob Gleitsmann 2009-07-03 22:49:16 EDT
Perhaps anaconda is not getting the nodmraid option from the kernel. I have disassembled the initrd.img file (it's gzipped cpio) but can't locate the source code for the init program used in it. That currently appears to be the key, as I think it starts anaconda. I located some source rpms that may have value, but I can't install them on my F9 system: rpmlib version too low. But since I can't install F11...
I don't understand how this bug was assigned low priority. No workaround has emerged and the problem prevents installation. Bravo to Tore Anderson for writing zeroes to the end of one of his file systems but I am not about to do that. Maybe somewhere it says that command line options for anaconda being passed through the kernel have to have a particular format... Some prefix to make sure it's routed to init and then to anaconda. 

Anyway peace to everyone.
Comment 19 Hans de Goede 2009-08-10 05:26:31 EDT
*** Bug 501814 has been marked as a duplicate of this bug. ***
Comment 20 Hans de Goede 2009-08-10 05:28:09 EDT
Hi,

Sorry for the long silence. Yes F-11 anaconda does not honor the nodmraid option I can confirm this is a bug. I'll be working on a fix.

I'll be using this bug to track all issues stemming from the problems caused by
the following:

There has been a behavioural change between F-10 and F-11 where in F-10 drives
which contain invalid / stale dmraid (BIOS RAID) metadata / which were part of an incomplete BIOS RAID set would be just seen as the raw disks, where as F-11 these drives are ignored.

In F-10 in cases where dmraid was detected unwantedly (in case of a complete set, but being disabled in the BIOS for example), the BIOS RAID detection could be avoided with nodmraid. In F-11 this option currently does not work, this is bug 499733. Once 499733 is fixed you can workaround your issue using the nodmraid installer cmdline option.

Note that a better solution would be to remove the unwanted BIOS RAID metadata from the disks, this can be done using "dmraid -x", be sure to make backups before doing this! "dmraid -x" should leave your data intact, but better safe then sorry.

Also only do this if you really want your disks to not be part of a BIOS RAID set, if for example windows is currently using the disks as a BIOS RAID set you do not want to do this!
Comment 21 Hans de Goede 2009-08-10 05:43:46 EDT
*** Bug 508554 has been marked as a duplicate of this bug. ***
Comment 22 Hans de Goede 2009-08-10 05:56:01 EDT
Ok,

To be clear the summary of this bug I'm setting now:
"Anaconda ignores disks with incomplete BIOS RAID metadata"

Is not accurate, this bug is for tracking the issue of anaconda failing
to honor the "nodmraid" cmdline option. The fact that "Anaconda ignores disks
with incomplete BIOS RAID metadata" with Fedora 11 and newer is not a bug, as
explained in Comment #20 the real fix for this is to remove the (often stale)
BIOS RAID metadata from your disks.

However for people who do not want to do that, or cannot for some reason, the
nodmraid cmdline option should make anaconda ignore the metadata and just use
the raw disks (like older versions did), that is what this bug is about, and
once that is resolved this bug will be closed.

I'm using the inaccurate (more like blatantly wrong) summary to make this bug
easier to find for people with the same issue.
Comment 23 Hans de Goede 2009-08-10 05:56:58 EDT
*** Bug 515129 has been marked as a duplicate of this bug. ***
Comment 24 Sam Varshavchik 2009-08-16 08:46:43 EDT
Re comment #20: dmraid -x is not a workaround for this bug.

I have two drives that were, ages ago, originally formatted by an Adaptec HBA in RAID mode, but when I discovered that, way back when, Fx did not support Adaptec hardware RAID, I turned it off, and switched to softraid.

Now, I can't install F11 because Anaconda does not see the hard drives, and dmraid -x does not work:

[root@commodore ~]# dmraid -r
ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on /dev/sdb
ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on /dev/sda
no raid disks
[root@commodore ~]# dmraid -x /dev/sdb
ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on /dev/sdb
ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on /dev/sda
no raid disks and with names: "/dev/sdb"
[root@commodore ~]# dmraid -r -E /dev/sdb
ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on /dev/sdb
no raid disks and with names: "/dev/sdb"
Comment 25 Hans de Goede 2009-08-16 14:46:26 EDT
(In reply to comment #24)
> Re comment #20: dmraid -x is not a workaround for this bug.
> 
> I have two drives that were, ages ago, originally formatted by an Adaptec HBA
> in RAID mode, but when I discovered that, way back when, Fx did not support
> Adaptec hardware RAID, I turned it off, and switched to softraid.
> 
> Now, I can't install F11 because Anaconda does not see the hard drives, and
> dmraid -x does not work:
> 
> [root@commodore ~]# dmraid -r
> ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on
> /dev/sdb
> ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on
> /dev/sda
> no raid disks
> [root@commodore ~]# dmraid -x /dev/sdb
> ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on
> /dev/sdb
> ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on
> /dev/sda
> no raid disks and with names: "/dev/sdb"
> [root@commodore ~]# dmraid -r -E /dev/sdb
> ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on
> /dev/sdb
> no raid disks and with names: "/dev/sdb"  

This is a dmraid bug, please file a bug against dmraid for this. Thanks!
Comment 26 Hans de Goede 2009-08-16 14:47:52 EDT
The nodmraid options has returned / has been fixed in anaconda-12.12-1, which
will be in Fedora 12 alpha.
Comment 27 W Agtail 2009-08-19 13:36:53 EDT
With reference to bug#: 515129.
In my case my disks did show up as a dmraid from the bios.
Adding -nodmraid did not work.
After clearing the raid config with dmraid -rE I was then able to install F11.
Thanks v much for your commehts.
Comment 28 Hans de Goede 2009-09-16 14:19:32 EDT
*** Bug 505488 has been marked as a duplicate of this bug. ***
Comment 29 Hans de Goede 2009-09-30 07:45:08 EDT
*** Bug 526453 has been marked as a duplicate of this bug. ***
Comment 30 Hans de Goede 2009-10-14 03:09:24 EDT
*** Bug 528865 has been marked as a duplicate of this bug. ***
Comment 31 James Laska 2009-10-14 07:58:41 EDT
Adding keyword 'CommonBugs'.  This will allow someone from the QA team (usually myself or awilliam) to help draft some documentation for this issue on https://fedoraproject.org/wiki/Common_F12_bugs (even though this is reported against F11, it seems to still occur on F12 too).
Comment 32 Sam Varshavchik 2009-10-14 18:18:21 EDT
According to comment #26, this should be fixed in F12.
Comment 33 Adam Williamson 2009-10-15 14:52:37 EDT
indeed, all the recently-filed dupes seem to be from F11. please only document on F11 common bugs page.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 34 Adam Williamson 2009-11-08 16:09:30 EST
update from hans: superseding his above suggestion, 'dmraid -rE' is a better method than 'dmraid -x' for removing stale metadata.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 35 Sam Varshavchik 2009-11-08 17:03:21 EST
dmraid -rE also fails to remove my stale metadata.

[root@commodore ~]# dmraid -rE
ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on /dev/sdb
ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on /dev/sda
no raid disks
Comment 36 Hans de Goede 2009-11-09 03:46:52 EST
(In reply to comment #35)
> dmraid -rE also fails to remove my stale metadata.
> 
> [root@commodore ~]# dmraid -rE
> ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on
> /dev/sdb
> ERROR: asr: Invalid magic number in RAID table; saw 0x0, expected 0x900765C4 on
> /dev/sda
> no raid disks  

Hmm, that is not good, note this specific issue is being tracked in bug 517761.
Comment 37 Surdu Dumitru Alexandru 2010-04-09 11:19:53 EDT
I use CentOS-5.2   i disabled from the BIOS the voice S.M.A.R.T.
On the boot option i wrote "linux nodmraid"
And that is all!!!!
Comment 38 Fred Wimberly 2010-10-08 11:10:03 EDT
Found this information on derkeiler.com (http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.ibm.pc.hardware.storage/2006-02/msg01143.html).

The commenter Arno Wagner suggest the following, which worked for me.

"I just had a look at the madam man-page. It seems deleting the metadata is as easy as a "mdadm --zero-superblock <disk/partition>".
Of course you have to stop the RAID array the disk/partition is part of first. "mdadm --stop /dev/md<device>" should do that." 

NOTE: I believe this will destroy all data.
Comment 39 Adam Williamson 2011-10-20 19:17:55 EDT
fwiw, I just had a disk where dmraid -rE doesn't work; it claims to be working, but a following dmraid -r still detects the 'array', and anaconda refuses to install to it. it's definitely a dmraid not an mdraid. now zeroing out the whole disk...
Comment 40 Pasi Karkkainen 2012-10-19 13:35:55 EDT
(In reply to comment #39)
> fwiw, I just had a disk where dmraid -rE doesn't work; it claims to be
> working, but a following dmraid -r still detects the 'array', and anaconda
> refuses to install to it. it's definitely a dmraid not an mdraid. now
> zeroing out the whole disk...

I just noticed the same. This was a disk from LSI megaraid array (actually Dell PERC, but it's LSI rebranded), and "dmraid -r -E" didn't work.

I had to do this to clear the last 512 kB of the disk:
dd if=/dev/zero of=$YOUR_DEV bs=512 seek=$(( $(blockdev --getsz $YOUR_DEV) - 1024 )) count=1024

After that Fedora 17 happily re-initialized the disk.

Btw anaconda gives python stacktrace and crashes when it refuses to use the disk, and thus there are no usable/installable disks in the system..

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