On Mon, Sep 04 2017, Michał Mirosław wrote: > On Mon, Sep 04, 2017 at 12:22:33PM +1000, NeilBrown wrote: >> On Fri, Sep 01 2017, Michał Mirosław wrote: >> >> > On Fri, Sep 01, 2017 at 10:07:29AM +1000, NeilBrown wrote: >> >> On Wed, Aug 30 2017, Michał Mirosław wrote: >> >> > Allow changing active array's set_name. This is the only way to >> >> > safely update superblock on an array which carries a mounted fs. >> >> >> >> Do you really need to change the set_name of an active array? >> >> >> >> The name is only used when the array is actived, so wait until the next >> >> time the array is stopped, and change the name then. >> >> >> >> You can boot with a rescue CD or similar and use "--assemble >> >> --update=name", or with a bit of effort you could get the normal boot >> >> sequence to change the name. >> >> >> >> I wouldn't object to adding something to mdadm so that it would read >> >> something from mdadm.conf, and update the set name at boot time. >> >> >> >> What is the underlying problem that you are trying to solve here? >> > >> > I had to fix /dev/md* naming on a system with no physical access. >> > >> > The problem was that despite matching mdadm.conf entries, arrays started >> > with random 127-i indexes (because superblocks' set_names didn't match >> > hostname, I guess). >> >> That's odd. If an array is listed in mdadm.conf, that is enough to tell >> mdadm that it is "local" so that it doesn't need the hostname to match. >> Can you show me exactly what was in your mdadm.conf? > > This is what was I had when it would reassign arrays on boot. System > hostname is 'rere' - it was renamed some time after creating arrays. > > ---8<--- > HOMEHOST <system> > MAILADDR root > ARRAY /dev/md/0 metadata=1.2 UUID=d5ea39a9:5ec27c36:c83296d4:70f879d4 name=rere2:0 > ARRAY /dev/md/1 metadata=1.2 UUID=9bf69b92:2e7ba905:5f959c09:c8fecb99 name=rere2:1 > ---8<--- > > I don't have old versions of mdadm.conf, so had to recreate this one. > IIRC I verified UUIDs back then, but don't remember whether I modified > names or not. Thinking of it, how would mdadm behave if it had matching > UUIDs and mismatching array names in mdadm.conf? That's what I was wondering and part of why I asked to see the mdadm.conf. If a name is given in mdadm.conf and it doesn't match the name in the metadata, that line will be ignored. If mdadm doesn't find a match in mdadm.conf and the hostname doesn't match, the the array will be treated as "foreign" and will be assembled as e.g. /dev/md127 with a symlink from /dev/md/0_1. If the name and uuid in mdadm.conf do match the metadata, it will be treat as "local" and will be given the name that you would expect (/dev/md0, /dev/md/0). So my guess is that the mdadm.conf you had at the time doesn't match what you have provided above. It would be nice to add an option to "mdadm --incremental" to tell it to update various details like you can with "mdadm --assemble".... NeilBrown
Attachment:
signature.asc
Description: PGP signature