From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mbroz@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
	by mail.saout.de (Postfix) with ESMTP
	for <dm-crypt@saout.de>; Mon, 28 Sep 2009 17:52:49 +0200 (CEST)
Received: from int-mx08.intmail.prod.int.phx2.redhat.com
	(int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8SF3HgC030073
	for <dm-crypt@saout.de>; Mon, 28 Sep 2009 11:03:17 -0400
Received: from [10.36.8.148] (vpn2-8-148.ams2.redhat.com [10.36.8.148])
	by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id n8SF3FRu002011
	for <dm-crypt@saout.de>; Mon, 28 Sep 2009 11:03:16 -0400
Message-ID: <4AC0D033.5040309@redhat.com>
Date: Mon, 28 Sep 2009 17:03:15 +0200
From: Milan Broz <mbroz@redhat.com>
MIME-Version: 1.0
References: <49a25c1e0909280409q4954f659v33eb701c6ab876e1@mail.gmail.com>	<20090928142801.GA6675@fancy-poultry.org>	<49a25c1e0909280729i1b29a3b4n9545e2eaf4b55356@mail.gmail.com>
	<20090928144819.GB7395@resivo.wgnet.de>
In-Reply-To: <20090928144819.GB7395@resivo.wgnet.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] luks partition table altered by linux-swap
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

Jonas Meurer wrote:
> On 28/09/2009 anton ivanov wrote:
> i don't know redhat cryptsetup management, but maybe a swap filesystem
> was created (mkswap) on the disk in question? in that case, the luks
> and/or raid headers might have been overwritten ...

IIRC mkswap in 5.3 do not overwrite first two sectors (so visible LUKS
header is intact) but it probably overwrites part of the first keyslot area.
(I think this changed in new version, there mkswap wipe first 4k.)

If this happens, you are out of luck - it will detect LUKS header but
keyslot is lost and unusable.

(Unfortunately other keyslots are unused, so you cannot use other passphrase.)

> Just curious maybe there is some cryptsetup ability to recover
> partition table on disk without luksFormat but using already stored
> metadata on the drive.

You must first decrypt the data, then you can search in them. Data offset
is known - see LUKS dump and payload offset (in sectors). But without
master key (iow without valid kesylot) you cannot decrypt it anyway.

Milan