Bug 508554
| Summary: | Anaconda fails to see the existing F10 install | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sam Varshavchik <mrsam> | ||||||||
| Component: | anaconda | Assignee: | Hans de Goede <hdegoede> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 11 | CC: | rmaximo, vanmeeuwen+fedora | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-08-10 09:43:46 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Sam Varshavchik
2009-06-28 14:47:45 UTC
Can you attach /tmp/anaconda.log and /tmp/storage.log, please? Created attachment 349884 [details]
storage.log
Thanks for the tip where to look. Here's storage.log
The culprit is the "ignoring /dev/sdb[123]" and "ignoring /dev/sdc[123]" messages. They weren't ignored in F10's anaconda :-)
P.S. These, and the following attachments were obtained by:
1. Flipping to ALT-F2
2. Running mdadm --assemble --scan
3. Mounting the resulting /dev/mdXXX device node
4. Copying /tmp/*.log to my existing F10 partition
5. Rebooting into F10, and posting these files
So, everything's there, but Anaconda refuses to look. One possibility is that these partitions are on a hard drive that's attached to an Adaptec HBA that has an optional RAID personality. That's some funky Adaptec proprietary RAID, however the HBA is configured as a standard SCSI HBA. It's hardware RAID functionality is turned off -- I never used it -- and I am using Linux software raid only. Anaconda might be making a wrong decision there to leave them alone, to dmraid or some other proprietary driver to deal with, but it should not be doing that. It should be cranking up mdadm and assembling these arrays...
Created attachment 349885 [details]
anaconda.log
Created attachment 349886 [details]
/dev/sdb and /dev/sdc, as seen by fdisk
Also, here's what fdisk says about sdb and sdc.
As you can see, these are ordinary Linux softraid partitions.
Hi Sam, Sorry for taking so long to get back to you, the issue is that your sdb and sdc drives contain BIOS RAID metadata (they probably have been used in such a setup once upon a time). Below the standard answer / explanation for issues with stale BIOS RAID metadata: 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! *** This bug has been marked as a duplicate of bug 499733 *** |