On 31 December 2016 at 09:48, Matthew Gabeler-Lee <[email protected]> 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.
