Re: changing uuid of mdadm array
Tim Woodall wrote:
> On Fri, 21 Oct 2022, Dan Ritter wrote:
>
> > Tim Woodall wrote:
> > > On Wed, 19 Oct 2022, Lucas Castro wrote:
> > >
> > > > The array must be identified somehow, in mdadm, array is by uuid!
> > > >
> > >
> > > And I have two disks, which have the same uuid but are not part of the
> > > same array.
> > >
> > > How do I tell mdadm that they aren't part of the same array?
> > >
> > > I can't believe I'm the only person who has cloned a machine by breaking
> > > a raid1 array.
> > >
> > > Or someone who has used dd to clone a disk that they then want to mount
> > > in parallel with the original
> >
> > mdadm --zero-superblock --force
> > can be used, carefully.
> >
> > You will need to re-add the disk to the new array and let it
> > sync.
> >
> > -dsr-
> >
> >
>
> But why would I want to do that? If I wanted it to be part of the array
> I'd have added it to the array, not cloned it with dd.
Sorry, I thought you wanted to move a disk from one array to
another on the same machine.
> I have an array. I use dd to copy it onto a new disk. I now want to
> start the original array (which is unchanged) and I also want to start
> the cloned disk as a new array.
You can't do that, to the best of my knowledge. You can take the
cloned disk to a new machine and use it to create a new array.
> Or actually, what caused me grief:
>
> I had a machine with two disks as part of a raid 1 pair.
>
> I wanted to clone the machine, so sdb was taken out and put in a new
> machine and two new disks were added as sdb in each machine. Arrays were
> rebuilt, tweaks were made to fix up things like ip addresses and then
> the two machines slowly diverged.
Right, that's normal.
> On one of the machines, one of the disks started reporting issues. The
> other machine was getting tight for space, so I bought two new larger
> disks, swapped one on the ok machine, rebuilt the array, swapped the
> other, rebuilt, resized.
>
> And then... Swapped the going faulty disk with one of the disks taken
> out of the other machine - except that mdadm thought they were part of
> the same array and things ended up in a terrible mess (partly because I
> didn't realize what was going on so made some mistakes with hindsight)
You have correctly deduced the problem.
> Yes, I should have failed the disk I was going to remove and then zeroed
> the superblock before removing it - but I'd completely forgotten that
> the two machines had the same uuid for their raids.
>
> So recently, when I ended up with a disk that had been a raid member, I
> thought I'd take the opportunity to see how to change the uuid, which is
> what I should have done on splitting the array originally.
>
> It surprises me that there isn't an easy safe way to change the uuid,
> but, as per my OP, there are 'risky' ways to achieve this if necessary.
The unspoken assumption is that one of three things will happen
when you remove a disk from a RAID:
- the disk went bad and you will discard it / replace it under
warranty
- you are keeping it as a kind of long term archive, properly
labelled, and it takes some kind of disaster for you to bring
it up (on another machine) to look at the contents
- you are splitting the mirror so that you can clone to another
machine, and it will never come back here.
Most of these assumptions hold across RAID-like systems. It
might be of interest to you that ZFS has the "export" and
"import" commands, which are used to prep whole pools to be sent
to another machine. It still won't be very happy with the
precise actions you took here.
-dsr-
Reply to: