Bug 1172426
Summary: | F22 Live: RAID device not created for imsm when volume has a GPT | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Aram Agajanian <agajan> |
Component: | mdadm | Assignee: | Jes Sorensen <Jes.Sorensen> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | agajania, agajan, agk, dledford, Jes.Sorensen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-07-19 12:30:11 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Aram Agajanian
2014-12-10 03:43:01 UTC
Intel Matrix Storage Manager option ROM v8.5.2.1002 ICH 10R/DO I'm also not finding a RAID 1 volume on a newer computer: Intel Rapid Storage Technology - Option ROM - 12.7.0.1936 I previously installed F21 Beta onto this volume but now I can't seem to find it when booting with the final Live image. On the newer computer, I deleted the RAID 1 volume and then re-created it. After that, when I booted from the Fedora 21 Live image, the RAID 1 device (/dev/md126) was created as expected. I have noticed that the default kernel command line for Fedora Live Workstation 21 includes the following: rd.md=0 Is it OK to edit the kernel command line at boot time and remove that parameter? (In reply to Aram Agajanian from comment #4) > I have noticed that the default kernel command line for Fedora Live > Workstation 21 includes the following: > > rd.md=0 > > Is it OK to edit the kernel command line at boot time and remove that > parameter? You should be fine removing that line for the live image. Does this still happen with F22? Jes (In reply to Jes Sorensen from comment #5) > (In reply to Aram Agajanian from comment #4) > > I have noticed that the default kernel command line for Fedora Live > > Workstation 21 includes the following: > > > > rd.md=0 > > > > Is it OK to edit the kernel command line at boot time and remove that > > parameter? > > You should be fine removing that line for the live image. > > Does this still happen with F22? > Using Intel Rapid Storage Technology (12.7.0.1936). There is an existing Fedora 21 installation on a RAID1 volume that has been created from Physical Device IDs 0 and 1. Looking at /proc/mdstat, I would expect to see a device named md126 for the RAID1 device. In Fedora 21 Live: no device is created whether or not rd.md=0 is present In Fedora 22 Live: no device is created whether or not rd.md=0 is present I then deleted the RAID1 volume (which contained the existing Fedora 21 installation) and created a new RAID 1 volume. In Fedora 21 Live: raid1 md126 device is created whether or not rd.md=0 is present In Fedora 22 Live: raid1 md126 device is created whether or not rd.md=0 is present It seems that F22 Live doesn't create an md126 device if there is a GPT on the RAID1 volume. F22 Live will create an md126 device if there is an MBR (i.e. disklabel type: dos) on the RAID1 volume. It took a little effort to get Anaconda to install onto a raid1 device with an MBR since the disk size is 2.73 TB. I created the partitions with fdisk before running Anaconda. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |