Bug 53665 - Can't preserve RAID partitions
Summary: Can't preserve RAID partitions
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 9
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-09-14 11:17 UTC by Alexandre Oliva
Modified: 2008-01-17 17:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:48:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Alexandre Oliva 2001-09-14 11:17:42 UTC
Description of Problem:
I've just experienced data loss attempting to do an installation while
preserving pre-existing RAID partitions.  The problem seems to be that Disk
Druid doesn't assign raid device numbers in a way that matches the kernel's
notion of existing raid devices.  In fact, it appears to assign raid
devices at random.  It's not the order in which RAID devices are created,
for example, which makes it even harder to make sure it's going to do The
Right Thing (TM).  In my case, the installer ended up formatting my 160GB
RAID 5 ext3 filesystem as a RAID5 swap device, just because the installer
decided to assign to the swap partition the md number that the kernel had
already assigned to the ext3 filesystem.  Oops :-)

Steps to Reproduce:
1. Create a few RAID devices in one installation
2. Do another installation, but create the raid devices in a different
order, but mark some partitions to not be formatted

Actual Results:
The preserved partitions aren't the same, and the raid devices aren't
assigned as Disk Druid said they would.

Expected Results:
The partitions I asked to have preserved shouldn't have been touched. 
Ideally, Disk Druid should read the md device numbers from the kernel to
assign them.

Additional Information:
For reference, here's how I partitioned the disks:
for f in hda hdc hde hdg; do
{ echo rm 1; echo rm 2; echo rm 3; echo rm 4;
  echo mkpart primary ext3 0 32
  echo mkpart extended 32 58644
  echo mkpart logical ext3 32 4887
  echo mkpart logical linux-swap 4887 5146
  echo mkpart logical ext3 5146 58644
  echo p; echo q;
} | parted /tmp/$f
for d in 1 5 6 7; do echo t; echo $d; echo fd; done; echo w; } |
fdisk /tmp/$f

In disk druid, I'd create the devices in the order below.  Nevertheless,
the md numbers were assigned as shown after `->'.
hd[aceg]1: RAID 1 /boot -> md3
hd[aceg]6: RAID 5 swap -> md2
hd[aceg]7: RAID 5 /l -> md0
hd[ae]5: RAID 1 / -> md1
hd[cg]5: RAID 1 /l/root -> md4

Comment 1 Brent Fox 2001-09-14 14:50:11 UTC
What tree was this with?

Comment 2 Jeremy Katz 2001-09-14 16:22:53 UTC
This is because we don't properly handle using previous RAID setups on a fresh

Comment 3 Michael Fulbright 2001-09-26 19:16:37 UTC
Dupe of (several?) other bugs.

Will be addressed in a future release.

Comment 4 Michael Fulbright 2002-03-26 17:43:53 UTC
Deferring to future release.

Comment 5 Red Hat Bugzilla 2006-02-21 18:48:09 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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