Re: call for testing, dmraid in rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2005-12-22 at 20:24 +0000, Andy Burns wrote: 
> Peter Jones wrote:
> 
> [Strange your reply made it to the mailman archive, but I don't seem to 
> have received it via the list, so this "hand pasted" reply will probably 
> lose it's position in the reply chain]
> 
> > Hrm.  That looks like an error I thought was fixed -- do you have more
> > than one set of raid metadata on the disks, with one set pointing to
> > drives that don't exist?
> 
> Do you mean metadata from Intel matrix raid setup, or some remnants of 
> metadata from software raid?

>From a software raid setup.

> > (or even just one set, if it's pointing to some non-existing drive)
> 
> I had a working software raid on the disks, didn't wipe them, changed 
> bios from SATA=AHCI to SATA=RAID, went into the bios raid config and 
> created a split config 100GiB mirror plus 300GiB stripe

I assume you mean you changed it to AHCI from RAID...

> That seemed to be enough to blow away the old contents of the drives, 
> grub didn't even load, machine tried to PXE boot, so I proceeded to 
> install ...

It's not.  It could change several things that cause grub not to start,
but from our perspective when examining the disks, they're exactly the
same.  We currently have no way to tell if the BIOS is in "raid" mode or
not.

(Perhaps there is a way, and it seems desirable that software could even
modify this setting, but I've seen no evidence that this is the case.
Of course, I haven't been looking, since there's still much else that's
more important to do in supporting dmraid fully.)

It's really best if you actually go and "delete" the raid volume before
turning raid off in the BIOS, or else we'll still see the raid when we
probe the disks.  without removing the metadata, it's also possible
(though unlikely if you're keeping the disks on one controller/bios)
that making another raid on the same drive will result in multiple sets
of metadata on the disk.  This is very difficult to handle in any way
one might call "correct".  That being said, a traceback certainly isn't
the best answer.

-- 
  Peter

-- 
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: 
https://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]