9

On Ubuntu 18.04 I create a RAID 1 array like this:

mdadm --create /dev/md/myarray --level=1 --run --raid-devices=2 /dev/sdc /dev/sdd

I then add the output of mdadm --detail --scan /dev/md/myarray to /etc/mdadm/mdadm.conf. It looks like this:

ARRAY /dev/md/myarray metadata=1.2 name=MYHOSTNAME:myarray UUID=...

The device name has been prefix with "MYHOSTNAME:". At this point the symlink /dev/md/myarray still exists, but after the first time I reboot it becomes /dev/md/MYHOSTNAME:myarray, breaking things. To make it worse, this happens only on some machines - on others the symlink remains /dev/md/myarray. All are running Ubuntu 18.04, so I have no idea why.

How do I get a consistent device path for my MD device, ideally the exact one I specified ("/dev/md/myarray")? I tried editing mdadm.conf to remove the hostname, but even if the line says

ARRAY /dev/md/myarray metadata=1.2 name=myarray UUID=...

the symlink still changes on reboot - on machines that "want" the hostname. I also tried going the other way and adding the hostname in both place:

ARRAY /dev/md/HOSTNAME:myarray metadata=1.2 name=HOSTNAME:myarray UUID=...

but again on machines that "don't want" the hostname the symlink becomes /dev/md/myarray after a reboot!

I can't use the numeric device (/dev/md127) either because when there are multiple MD devices created like this they tend to alternate between md126 and md127 as well! This is crazy!

1
  • Related silliness: if you run mdadm --create /dev/md/ONENAME --name ANOTHERNAME then the symlink is initially /dev/md/ONENAME, but after a reboot or --stop/--assemble it becomes /dev/md/ANOTHERNAME.
    – EM0
    Aug 5, 2019 at 8:08

2 Answers 2

8

How do I get a consistent device path for my MD device, ideally the exact one I specified ("/dev/md/myarray")?

After mdadm --create /dev/md/foobar ..., both hostname and name are stored in the mdadm metadata, as you should verify with mdadm --examine or mdadm --detail:

# mdadm --detail /dev/md/foobar
           Name : ALU:foobar  (local to host ALU)

ALU happens to be the hostname of my ArchLinux machine:

# hostname
ALU

You can specify the host that should be stored at create time:

# mdadm --create /dev/md/foobar --homehost=barfoo
# mdadm --detail /dev/md/foobar
               Name : barfoo:foobar

...but usually nobody remembers to do that.


And that's already where the problems start... you might have created your RAID array from some LiveCD or other, and the hostname in that environment didn't match your main install at all. And then the metadata stores some completely unrelated hostname.

Similarly if you set everything up correctly, but then encounter problems with your RAID and boot a rescue system to check things out, yet again there's a mismatch with the hostnames.

Or the other way around, the hostname may match even if it's the wrong machine - if you used the same hostname for two independent systems and then migrate drives. Then the alien arrays take over the names of the original ones...


Now, the metadata can also be changed later using mdadm --assemble --update=homehost or --update=name, that is one way to deal with problem. It should be set correctly but it's difficult to change as (for some reason) short of hexediting metadata directly, it can only be done at assembly time.

Another way is to ignore the systems hostname and instead specify --homehost on assembly or set HOMEHOST in mdadm.conf. This is described in some detail in the mdadm.conf manpage.

HOMEHOST
The homehost line gives a default value for the --homehost= option to mdadm. There should normally be only one other word on the line. It should either be a host name, or one of the special words <system>, <none> and <ignore>. If <system> is given, then the gethostname(2) systemcall is used to get the host name. This is the default.
[...]
When arrays are created, this host name will be stored in the metadata. When arrays are assembled using auto-assembly, arrays which do not record the correct homehost name in their metadata will be assembled using a "foreign" name. A "foreign" name alway ends with a digit string preceded by an underscore to differentiate it from any possible local name. e.g. /dev/md/1_1 or /dev/md/home_0.

So you can try to set HOMEHOST ALU (in my case), or the more generic HOMEHOST <ignore> (or HOMEHOST <none>) in the mdadm.conf. But it will only work when that mdadm.conf is present. And again if you set ignore and then hook up an array from another machine, you might run into name conflicts.

So it'd be best to set the hostname correctly in metadata and mdadm.conf and not ignore it, and better yet set the actual hostname in initramfs before assembly but it can be hard to put into practice.

My personal preference is to just stick to the classic numeric style. Identify by UUID and nothing else:

ARRAY /dev/md1 UUID=8fe790ca:f3fa3388:4ae125b6:2c3a5d44
ARRAY /dev/md2 UUID=f14bef5b:a5356e51:25fde128:09983091
ARRAY /dev/md3 UUID=0639c68d:4c844bb1:5c02b33e:00ab4a93

This is also consistent (but also depends on it to have been created this way and/or set accordingly in the metadata, otherwise you also might have to --update it). And alien arrays that don't match the given UUIDs should end up as /dev/md127+.


At the end of the day no matter what you do, you should not blindly rely on /dev/mdX or /dev/md/names the same way you don't blindly rely on /dev/sdX letters. Always use filesystem UUIDs to identify whatever is on those arrays.

There's too many corner cases where names might unexpectedly change, so at best, this can be an orientation help or hint to the sysadmin, it's not the answer to all problems.

3
  • 2
    Thank you, yes, it turns out out that the host on which the MD device got the hostname prefix had been renamed, while the host that didn't get the prefix still had its original hostname. What threw me off was that the prefix was the new hostname of the machine - so it seems like when creating an array the new hostname was used, but when assembling it it was still somehow treated as "foreign". Anyway, I ended up disabling this rubbish completely with HOMEHOST=<ignore> in mdadm.conf. I also removed all ARRAY lines from there - the device still exist after reboot. What a mess!
    – EM0
    Aug 5, 2019 at 13:35
  • 1
    Another thing to note is that the hostname:arrayname string may only be 32 bytes long in total (with mdadm 1.x metadata). Trying to use longer names first ditches the hostname, then silently truncates the array name. No error is reported in either case. Aug 5, 2019 at 14:18
  • I have no words...
    – EM0
    Aug 6, 2019 at 9:26
1

I use Arch Linux and experienced the same behavior. I created the RAID5 array with the same homehost as my host machine. mdadm --detail /dev/md/data shows the following line

              Name : MY-NAS:data  (local to host MY-NAS)
              UUID : 3f3b2cba:5c184b08:183f0bc1:4bb971a1
            Events : 14720

My hostname is MY-NAS. With the command mdadm --detail --scan >> /etc/mdadm.conf, I got the additional line for RAID assembling

ARRAY /dev/md/data metadata=1.2 spares=1 name=MY-NAS:data UUID=3f3b2cba:5c184b08:183f0bc1:4bb971a1

However, when I reboot the machine, the array appears at /dev/md/MY-NAS:data instead of /dev/md/data. If I mdadm --stop /dev/md/MY-NAS:data and then mdadm --assemble --scan, it appears at /dev/md/data.

After digging into how udev rules work https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/udev-md-raid-arrays.rules, I believe you need to

  1. place the mdadm_udev hook in front of lvm
  2. run mkinitcpio -P every time when you make changes to /etc/mdadm.conf since the file is directly added to initramfs

After doing this, the name of the device gets corrected.

BTW: I'm a user of Arch Linux. For Ubuntu/Debian, the equivalent of mkinitcpio is update-initramfs according to https://askubuntu.com/questions/1210480/ubuntu-equivalent-of-mkinitcpio-conf. But I don't know how do modify the order of hooks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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