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

Re: FOLLOW-UP: RAID-1 (mirroring) disk failed; now what? [failed]

Paul Howarth <paul city-fan org> writes, quoting me:

>> * A _big mistake_ that I made! --
>>   At some point, with my new disk (/dev/sda) in and booted off the
>>   rescue CD, I did something like...
>>   dd if=/dev/sdb2 of=/dev/sda2
>>   ... i.e. brute-force copy all of a raid-1 partition onto its
>>   presently-empty cousin.  Theory: "/dev/sda is empty and not in play;
>>   what harm can it do?"
>>   Answer (I think): Lots.  The RAID software snoops around on these
>>   (type 'fd') partitions and silently decides what to make of the
>>   situation.  This is really not what you want in this delicate
>>   state.  Information is OK ("I've spotted a degraded array on
>>   /dev/sdb2, which seems odd"), and doing nothing is OK, but "being
>>   helpful" isn't.  (Is there a kernel boot parameter to turn off RAID
>>   cleverness?)
> Doing this copies the UUIDs that the RAID software uses to identify
> each partition of the RAID. It's the RAID equivalent of having
> identical filesystem labels on two partitions so that mount doesn't
> know which one to use ...

Yes, I'm painfully aware :-(, and was shortly after I did it.  I
hadn't counted on the RAID software being clever behind my back...

I'm not sure that's what sunk me, though.  I _seem_ to have somehow
managed to end up without a /boot/vmlinuz<something> (previously
mis-wrote: /boot/grub/vm...), or so it seemed.  When you're typing
grub commands into a pre-book grub> prompt, you're one step away from
a soldering iron, with which I certainly cannot be trusted.

Once more: all this is something well worth robustifying.


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