Paul Howarth <paul@xxxxxxxxxxxx> 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.
Will
