Bug#784070: mdadm Software RAID1 with GPT on Debian 8.0.0 amd64 - Does not mount/boot on disk removal

[Robert.K.]

The RAID1 was a RAID1 and worked normally when both disks were present. But
with only one RAID1 disk connected then mdadm gave up waiting for root
device and was dropped to an initramfs shell. THEN mdadm --detail showed
RAID1 devices as RAID0 inside the initramfs-shell.

Please look at Message #17 in this (#784070) bug report, this guy gets the
same result:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784070#17

I cite message 17:

"Description: What happens is the array becomes inactive on any disk

removal(degraded?), marked as RAID0(for some reason) and all attached
disks are marked as [S] (for spare) upon reboot.
However, it is possible to boot from it by starting it in the
"(initramfs)" shell (which it drops to because it "cannot mount root
device") by using:

(initramfs):  mdadm --run /dev/md0
(initramfs):  mdadm --run /dev/md1
(initramfs):  exit"

rootdelay alone does not solve the problem. rootdelay=15 (not
rootwait) works TOGETHER with the local-top script from serverfault,
which you can find here - this link is in message #54:
http://serverfault.com/questions/688207/how-to-auto-start-degraded-software-raid1-under-debian-8-0-0-on-boot

There is also a suggestion to what the problem is on serverfault, I
cite from serverfault, see link above:

"With the version of mdadm shipping with Debian Jessie, the --run
parameter seems to be ignored when used in conjunction with --scan.
According to the man page it is supposed to activate all arrays even
if they are degraded. But instead, any arrays that are degraded are
marked as 'inactive'. If the root filesystem is on one of those
inactive arrays, the boot process is halted."

The reason I mentioned rootdelay was because you were talking about
the need of timeouts for slow devices in message #49. I remembered
that adding rootdelay solved my timing problem for slow devices and
allowed my USB disk to become available.

I think we should leave out the issue that is fixed by rootdelay from
this as it belongs to another bug/problem.

r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20150611/22b06114/attachment.html>