Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Okay, this is starting to get pretty frustrating. I've read most of the other answers on this site that have anything to do with this issue but I'm still not getting anywhere. I have a RAID 6 array with 10 devices and 1 spare. The OS is on a completely separate device. At boot only three of the 10 devices in the raid are available, the others become available later in the boot process. Currently, unless I go through initramfs I can't get the system to boot - it just hangs with a blank screen. When I do boot through recovery (initramfs), I get a message asking if I want to assemble the degraded array. If I say no and then exit initramfs the system boots fine and my array is mounted exactly where I intend it to. Here are the pertinent files as near as I can tell. Ask me if you want to see anything else.

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.

#DEVICE partitions containers

# auto-create devices with Debian standard permissions
# CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays

# This file was auto-generated on Tue, 13 Nov 2012 13:50:41 -0700
# by mkconf $Id$
ARRAY /dev/md0 level=raid6 num-devices=10 metadata=1.2 spares=1 name=Craggenmore:data UUID=37eea980:24df7b7a:f11a1226:afaf53ae

Here is fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).

#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdc2 during installation
UUID=3fa1e73f-3d83-4afe-9415-6285d432c133 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sdc3 during installation
UUID=c4988662-67f3-4069-a16e-db740e054727 none            swap    sw              0       0
# mount large raid device on /data
/dev/md0    /data   ext4    defaults,nofail,noatime,nobootwait  0   0

output of cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid6 sda[0] sdd[10](S) sdl[9] sdk[8] sdj[7] sdi[6] sdh[5] sdg[4] sdf[3] sde[2] sdb[1]
      23441080320 blocks super 1.2 level 6, 512k chunk, algorithm 2 [10/10] [UUUUUUUUUU]

unused devices: <none>

Here is the output of mdadm --detail --scan --verbose

ARRAY /dev/md0 level=raid6 num-devices=10 metadata=1.2 spares=1 name=Craggenmore:data UUID=37eea980:24df7b7a:f11a1226:afaf53ae
   devices=/dev/sda,/dev/sdb,/dev/sde,/dev/sdf,/dev/sdg,/dev/sdh,/dev/sdi,/dev/sdj,/dev/sdk,/dev/sdl,/dev/sdd

Please let me know if there is anything else you think might be useful in troubleshooting this... I just can't seem to figure out how to change the boot process so that mdadm waits until the drives are ready to build the array. Everything works just fine if the drives are given enough time to come online.

edit: changed title to properly reflect situation

share|improve this question
add comment

1 Answer

up vote 0 down vote accepted

Okay I've finally figured out this intensely frustrating problem. Turns out there are several bugs filed in the area. Unfortunately, finding the work-around was very difficult.

First a little bit more info:

  1. The hang is nothing of the sort. What is actually occurring is that the system is dropping to a initramfs shell. Unfortunately, this is hidden by the graphical boot so all I see is a slightly purple blank screen. If I type exit it will allow the system to boot up.

  2. The system is dropping into the initramfs shell because it asks if we want to boot degraded and since it can't receive any input the way boot is setup this times out.

  3. The last bit of info is that no matter what parameters you pass to kernel you can't get past this prompt. So we're stuck hanging if our drives for our array don't come up fast enough to suit upstart/udev.

Bugs are filed on launchpad (not by me) on all of the above issues and it looks like they are being worked through (this issue is apparently pretty difficult to deal with due to touching on a lot of things).

Fortunately for me, I was able to find a solution which will follow at the end. First I have to give a disclaimer with a strong warning. What I describe could cause you to mount a degraded array without being aware of it. This could lead to a total failure and loss of your data. You have been warned - DO NOT DO THIS UNLESS YOU ARE COMPLETELY CERTAIN YOU ARE WILLING TO TAKE THESE RISKS!

What I did to get Ubuntu to allow the system past this race condition was actually very simple:

sudo dpkg-reconfigure mdadm

Then reconfigure mdadm to allow the system to start the array degraded. As I mentioned before, this can be risky so make sure that you have your mdadm set up to notify you if the array is running degraded and monitoring your array. I'd also recommend you set up e-mail notifications. I also have the system sending me a summary on my raid every time I reboot. I hope this was useful to someone; I sure wish I could have found this answer!

Cheers!

share|improve this answer
    
Can you please link to the relevant bugs? –  Guy Nov 15 '13 at 22:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.