From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Open raid1 with luks encryption after a raid re-create
Date: Sat, 21 Nov 2015 19:49:14 +0100 [thread overview]
Message-ID: <20151121184914.GA28647@tansi.org> (raw)
In-Reply-To: <loom.20151121T172556-770@post.gmane.org>
On Sat, Nov 21, 2015 at 17:29:10 CET, Luis Alexandre wrote:
> Hi.
>
> I have a raid1 (mdadm-based) setup with two disks. I had them encrypted with
> luks. Everything was ok for 2 years. My PC had a problem and I had to mount
> this on a new PC.
> When I tried to start the raid on the new PC it only started 1 of the disks
> because the other had been replaced on a different PC and had a different
> hostname (my original PC had a script to assemble the raid even with the two
> disks having a different hostname).
That is not a good idea at all. It would have been far better to kick
one drive and add it again, giving both disks the same superblock.
> So I tried to fix this different hostname problem by re-creating the raid in
> the new PC using
>
>
> mdadm -C /dev/md127 -l1 -n2 --assume-clean --metadata=1.2 /dev/sdb /dev/sdc1
> --uuid=1d925c8d:8c8bb953:4e9070f7:43344cf9
Is /dev/sdb correct here? The warning below indicates it should
have been a partition, not the complete device.
maybe you should have done that the other way round?
Also, did teh original array use superblock 1.2?
> mdadm: /dev/sdb appears to be part of a raid array:
> level=raid1 devices=2 ctime=Sun Feb 12 19:40:32 2012
> mdadm: partition table exists on /dev/sdb but will be lost or
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> meaningless after creating array
> mdadm: /dev/sdc1 appears to contain an ext2fs file system
> size=976760832K mtime=Mon Aug 25 19:50:27 2014
> mdadm: /dev/sdc1 appears to be part of a raid array:
> level=raid1 devices=2 ctime=Tue Aug 26 09:10:39 2014
> Continue creating array? y
> mdadm: array /dev/md127 started.
>
> All appeared to be OK:
>
> cat /proc/mdstat
> Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4]
> [raid10]
> md127 : active (auto-read-only) raid1 sdc1[1] sdb[0]
> 976629568 blocks super 1.2 [2/2] [UU]
>
> unused devices: <none>
That tells you nothing. If you create a new RAID array (and you did) it
will just ride over everyhting in the superblock's place (as you used
--assume-clean).
>
>
> but now luks does not open the raid:
>
> sudo cryptsetup luksOpen /dev/md127 raid1
> Device /dev/md127 is not a valid LUKS device.
>
> Any ideas on how to re-open the raid with luks?
See below.
> Note: I thought there would be no problem with the create command because of
> this in the mdadm man page:
> "Create Create a new array with per-device metadata (superblocks).
> Appropriate metadata is written to each device, and then the array
> comprising those devices is activated. A 'resync' process is started to make
> sure that the array is consistent (e.g. both sides of a mirror contain the
> same data) but *the content of the device is left otherwise untouched*. "
>
It can sync in the wrong direction. And second, unfortunately,
superblock format 1.2 is a dirty hack designed by incompetents.
It places the RAID header 4k from the start of the device. For
LUKS, this kills the first keyslow of misaligned. Unfortunately,
this is also the default. No, that has not happened here or you
would get the header.
> Thanks for any help you can provide.
Ok, first stop writing to the disks. Second, make a full, binary backup
of each disk. And third, try whether either disk works individually
as degraded array.
If neither gives you a LUKS header, you can still search on the raw
disks by looking for the LUKS signature. If that also fails, you are
out of luck and all your data is gone.
Regards,
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
next prev parent reply other threads:[~2015-11-21 18:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-21 16:29 [dm-crypt] Open raid1 with luks encryption after a raid re-create Luis Alexandre
2015-11-21 18:49 ` Arno Wagner [this message]
[not found] ` <5651B1CF.7090306@sapo.pt>
2015-11-22 12:52 ` Arno Wagner
2015-11-22 15:05 ` Luís Alexandre
2015-11-22 18:15 ` Arno Wagner
2015-11-22 22:30 ` Sven Eschenberg
2015-11-23 3:35 ` Arno Wagner
2015-11-23 3:56 ` Sven Eschenberg
2015-11-23 6:26 ` Arno Wagner
2015-11-24 11:15 ` Luis Alexandre
2015-11-24 12:52 ` Arno Wagner
2015-11-25 11:49 ` Sven Eschenberg
2015-11-21 19:05 ` Sven Eschenberg
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=20151121184914.GA28647@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/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.