On Sat, Mar 25, 2017 at 06:09:34PM -0300, Renaud OLGIATI wrote:
...
...
>
> 3 Removing The Failed Disk
>
> To remove /dev/sdb, we will mark /dev/sdb1 and /dev/sdb2 as failed and remove them from their respective RAID arrays (/dev/md0 and /dev/md1).

Possibly too late. My defective RAID partitions are on a drive that
is already not physically connected to the machine. That's the
problem I'm trying to solve *safely*.

>

> First we mark /dev/sdb1 as failed:
>     mdadm --manage /dev/md0 --fail /dev/sdb1

mdadm is already aware that its other disk has failed. It's
physically absent.

...
...

>

> Then power down the system:
>     shutdown -h now
> and replace the old /dev/sdb hard drive with a new one

I deeply believe it's the connection -- the interface and the cabling
-- that is defective and not the hard drive. I have alredy provided a
new drive in this slot only to have problems recur with the new drive.
So I figure that it's probably not the drive, so the new drive will
*be* the old one.

I plan to conect it by rearranging the cablng so the drive is
connected with a different cable to a different interface and a
different power connector.

Once I get it connected again, the worry will be that
the file systems on the now-disconected drive will fool the boot
process into booting from it instead of the up-to-date drive.

Maybe I have to wipe the disk clean before reinstalling it. Which
I'll probably have to do on a different machine.

Or is it enough tto scramble the UUIDs of the file systems and to
erase the RAI signatures? Or use DD to empty the partitions? Will dd
to a partition erase the UUID of its file system? And the RAID
signature?

> (it must have at least the same size as the old one
> if it's only a few MB smaller than the old one then rebuilding the
> arrays will fail).
>
>
>
> 4 Adding The New Hard Disk
>
> After you have changed the hard disk /dev/sdb, boot the system.

Once I's at this stage, with a clean second drive, I know how to
proceed from here.

-- hendrik