All of lore.kernel.org
 help / color / mirror / Atom feed
From: antlists <antlists@youngman.org.uk>
To: linux-raid@vger.kernel.org
Subject: Re: Assemble RAID on new machine but with missing devices
Date: Sat, 28 Nov 2020 17:47:58 +0000	[thread overview]
Message-ID: <b5d9ee39-3be6-381b-78ac-93b500255945@youngman.org.uk> (raw)
In-Reply-To: <4CjVhl4nSbz6tm9@submission01.posteo.de>

On 27/11/2020 23:10, c.buhtz@posteo.jp wrote:
> Hello,
> 
> I red some stuff about assembling mode for mdadm. But two points are
> unclear for me.
> 
> 1. Missing devices
> I have two HDDs in a RAID1 - only data, no OS, on them. I want to
> physical remove one HDD and plug it into a new server machine. Then I
> want to bring the RAID1 online again on the new machine but with one
> existing and one missing drive.
> Background: When finished I will plug in a new fresh HDD as the second
> one to the new server.

It's fairly certain that the array will - initially - refuse to run. 
That's a safety feature - if an array is damaged while shut down, it 
won't come back without intervention.

Put the single disk in your new system. As I say, it's unlikely it'll 
start straight away. "cat /proc/mdstat" and if the array is there in a 
failed state, stop it. Then you can re-assemble it and it should come up 
degraded. All you have to do after that is replace the non-existent 
drive with your new replacement, and you'll have a functioning array.
> 
> 2. mdadm.conf
> On the web I read sometimes about modifying mdadm.conf on the new
> machine. But I do not understand why. If so. Why and what do I have to
> modify in the mdadm.conf?
> 
If you've even got one ...

I don't know the history of it, but the early arrays did not have 
superblocks, so mdadm.conf - an ACCURATE - mdadm.conf was essential. Now 
they've got superblocks, it's optional and - to the best of my knowledge 
- none of my systems have mdadm.conf's.

Do you have a superblock? Preferably v1 (1.0, 1.1 or 1.2). If you do, 
don't worry about it, it's old advice, and while it's good to have an 
up-to-date mdadm.conf to tell *you* what's what, the system doesn't need it.

Cheers,
Wol

  reply	other threads:[~2020-11-28 22:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-27 23:10 Assemble RAID on new machine but with missing devices c.buhtz
2020-11-28 17:47 ` antlists [this message]
2020-11-29 17:05 ` Doug Herr
2020-11-28 12:11 c.buhtz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b5d9ee39-3be6-381b-78ac-93b500255945@youngman.org.uk \
    --to=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.