1

I have a SuperMicro unit here, running Ubuntu 16.04.2. I've set up a RAID-10 array of 24 drives in f3 layout, and after tuning it to my liking, I've run into a problem.

This isn't a unit I can leave running every day; instead, I boot it when I come in, and turn it off on my way out the door each day.

When I first turn the unit on each day, it fails to boot, and systemd is hanging on mounting the larger md raid (there's a RAID 1 for the boot drives). 

# 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
ARRAY /dev/md/0  metadata=1.2 UUID=6581959a:3276c5d0:b401a3df:da599629 name=farnsworth:0

# This file was auto-generated on Tue, 11 Apr 2017 09:47:26 -0500
# by mkconf $Id$
ARRAY /dev/md/1 metadata=1.2 name=farnsworth:1 UUID=ea97974f:a3e840cd:d4bbcf9e:438957fe

According to my mdadm.conf, this should work, but even weirder is that, upon reboot, it works just fine.

mdadm --detail --scan

Shows up as active for both arrays, even when the unit is failing to boot.

Where should I be looking for the error?

Edit: The drives are all 1TB Seagate ES.2 drives, connected using SATA. Using Ubuntu 16.04.

At the advice of the first commenter, I shut it down (not reboot) and it came right back up. Root is not on this array.

When it comes up the first time of the day, it comes up as /dev/md/1, but after that, it comes up as /dev/md/farnsworth:1.

Why is this?

Improve this question
7
  • Edited question with more information. Commented Apr 19, 2017 at 16:33
  • Farnsworth is the hostname, yes. And I've mentioned twice that it's Ubuntu 16.04(.2) Commented Apr 19, 2017 at 17:41
  • Sorry about that, you did indeed mention Ubuntu 16.04 twice. The hostname:number naming looks suspiciously like the system is considering them "foreign" arrays. I wonder if it somehow got assembled as a foreign array... Have you tried updating your initramfs since setting up theses arrays? The difference might be whether the array is getting assembled that early, and the initramfs probably has its own copy of mdadm.conf. Other than that, I'd try setting HOMEHOST farnsworth (and again updating initramfs). Commented Apr 19, 2017 at 18:22
  • So simply run mkinitramfs after backing up the old one? Edit: Updating initramfs, seems to work! :) Thanks! Commented Apr 19, 2017 at 18:46
  • update-initramfs -u is probably easier, but yeah... (BTW: Seems to work as in updated the initramfs, or as in fixed the problem?) Commented Apr 19, 2017 at 18:49

1 Answer 1

Reset to default
1

There is typically a second copy of mdadm.conf on the initramfs. After editing mdadm.conf you must therefor run update-initramfs -u or similar to update its copy.

Having the two copies out of sync can lead to a race condition where the results of assembling the array depend on if array assembly finished before or after the initramfs. It can also just lead to plain confusion where changes appear to be ignored.

Improve this answer
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.