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

Robert.K. dotpointer at gmail.com
Thu Jun 11 17:13:29 UTC 2015


I clarify:

If rootdelay was confusing then forget all about rootdelay. It has nothing
todo with the problem this bug (#784070) is about, just another problem
that you may encounter before or after hitting this bug when the system
waits for slow devices.

The bug in this report (#784070) is about being dropped to a shell when
there are missing disks in a software RAID1 configuration upon boot.

r


2015-06-11 19:03 GMT+02:00 Robert.K. <dotpointer at gmail.com>:

> 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/40d37cb3/attachment.html>


More information about the pkg-mdadm-devel mailing list