Re: Cannot update homehost of an existing array: mdadm: /dev/sda3 has wrong name.

[Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>]

On Mon, 21 Oct 2024 22:33:22 +0200
Marc Haber <mh+linux-raid@zugschlus.de> wrote:

> Hi Mariusz,
> 
> thanks for your answer.
> 
> On Mon, Oct 21, 2024 at 08:51:32AM +0200, Mariusz Tkaczyk wrote:
> > I'm looking into Incremental right now and there is a comment:
> > 
> > 	 * 3/ Check if there is a match in mdadm.conf
> > 	 * 3a/ if not, check for homehost match.  If no match, assemble as
> > 	 *    a 'foreign' array.
> > 
> > I believe that this is kind of "foreign" naming for native raid.  
> 
> But the array is not intended to be considered as foreign, it is running
> on its native host.
> 
> Good call, I indeed forgot updating mdadm.conf. And I also forgot that
> we are on Debian stable with a current kernel now, that means Kernel
> 6.11.3 and mdadm 4.2
> 
> > You can probably correct it by updating your mdadm.conf or you can update
> > your homehost to production system hostname.  
> 
> It now says:
> HOMEHOST <system>
> ARRAY /dev/md/myrealhostname:md_root metadata=1.2 name=myrealhostname:md_root
> UUID=9d455b1e:35a52a2b:59b2bc1a:db22369f The ARRAY line is what mdadm
> --detail --scan prints, and hostname(1) returns "myrealhostname". And still,
> /dev/md/myrealhostname:md_root exists after rebuilding initramfs and
> rebooting..
> 
> Changing the ARRAY line to
> ARRAY /dev/md/md_root metadata=1.2 name=myrealhostname:md_root
> UUID=9d455b1e:35a52a2b:59b2bc1a:db22369f and rebuilding initramfs yielded the
> expected behavior, having /dev/md/md_root.
> 
> Thanks for pointing me so effienctly to the correct solution.
> 
> > So yes, it looks like expected, we are highlighting that it is not our MD
> > array.  
> 
> But it IS "our" MD array. Or, at least it is supposed to be.
> 
> Greetings
> Marc
> 


Got you. Well, looks like this array name "ARRAY
/dev/md/myrealhostname:md_root" forced bad naming. Generally, I recommend
#mdadm --examine --scan for conf generation. You can try and see if the output
is different comparing to --detail --scan.

Probably, we should consider fixing that for --detail --scan.

Thanks,
Mariusz