Bug#849806: mdadm: Administrator should be warned about the dangers of HOMEHOST <system>

[Dimitri John Ledkov]

On 31 December 2016 at 09:48, Matthew Gabeler-Lee <cheetah at fastcat.org> wrote:
> Package: mdadm
> Version: 3.4-4
> Severity: normal
>
> I've found, the hard way, that having "HOMEHOST <system>" in mdadm.conf is
> ... not really safe, unless you list ALL arrays in mdadm.conf.  That of
> course means that the arrays are all always present.
>
> In my case, I have arrays that are present in external (read:
> semi-removable) storage, so listing them explicitly in mdadm.conf would
> cause frequent spurious boot failures -- these arrays are in no way needed
> to boot the system.  I rely on udev incremental assembly to bring up these
> arrays when they come online, and this works fine for me.
>
> In this scenario, though, HOMEHOST <system> is a bad setting, because if
> these arrays ARE present at boot, then they are assembled as foreign arrays
> ... beacuse the system hostname isn't set yet!  Which means they have the
> "wrong" name in /dev/md/ and things go badly.
>
> It seems to me that the administrator should be warned about this in some
> way.  Fancy would be to warn if this config setting is in use and there are
> arrays present which are not defined in mdadm.conf (NB: the existing logic
> for detecting this is ... weak, it is trivially confused by comments for
> example).  Less fancy but still useful would be to document this limitation
> in mdadm.conf(5).
>
> Snazzy would be to bake the system hostname into the initramfs (Ubuntu seems
> to do this as part of the baseline initramfs-tools, but Debian not so much)
> so that this problem largely went away.
>

Ouch. Imho hostname should be copied into initramfs. But I do not know
the history of where this change was done in Ubuntu and/or why not
done in Debian.
I am not sure if it is appropriate for mdadm package initramfs hooks
to copy /etc/hostname into initramfs. Maybe it should be done
somewhere more universal, e.g. initramfs-tools itself.

-- 
Regards,

Dimitri.