Bug 603297 - Anaconda reverses MD0/1 allocations
Anaconda reverses MD0/1 allocations
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-12 04:41 EDT by Wayne Carruthers
Modified: 2010-06-24 21:43 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-24 06:48:40 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 Wayne Carruthers 2010-06-12 04:41:00 EDT
Description of problem:

When setting up RAID (mirroring) devices anaconda reverses the allocations made

eg at set up screen

MD0 sda1 sdb1 (Operating System) 35gb 
MD1 sda2 sdb2 (data file system) 200gb

becomes

MD0 sda2 sdb2 (data file system) 200gb 
MD1 sda1 sdb1 (Operating System) 35gb

After anaconda commits changes to disk


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


How reproducible:

always

Steps to Reproduce:
1. Setup raid
2. commit actions
3.
  
Actual results:


Expected results:


Additional info:

Old versions of anaconda used to similarly re arrange hard disk partition allocations, sda1,2,3 etc. This was annoying and I found confusing

The partitions now allocate logically sda1 beginning of disk through to sd? at end of disk

Seems the script to do the md devices has not been updated
Comment 1 Hans de Goede 2010-06-24 06:48:40 EDT
Hi,

Thanks for the bug report.

I've tried to reproduce this, and during the installation the different
md-raid sets got the same md# as indicated in the UI, and the written /etc/mdadm.conf also had the proper UUID's there to make the numbering stick
after reboot.

But as documented as a known issue having a / on a mdraid mirror without a separate /boot does not work in F-13:
https://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_without_a_separate_.2Fboot_fails

I then boot into rescue mode, and look and behold md0 and md1 got swapped. This is a known issue, where we give pre-existing mdraid's a random md# number instead of taking the number they had before from their superblock

This is fixed by this commit which will be in F-14.
http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=b213dceca01acfedf97afdc917c8cc7a871417c3

So summarizing:
1) Doing an mdraid mirror install without a separate /boot does not work in F-13, this is a known issue which is fixed for F-14. To work around this do an install with a separate /boot
2) When starting anaconda with pre-existing mdraid sets (such as when booting rescue mode after the failure caused by 1.) The mdraid sets do not always get the correct minor number. this also is a known issue which is fixed for F-14.
Comment 2 Wayne Carruthers 2010-06-24 21:43:10 EDT
Thank you for your efforts, they are appreciated

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