From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LImczLc-1C5l for ; Thu, 19 Jul 2012 10:24:48 +0200 (CEST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 19 Jul 2012 10:24:48 +0200 (CEST) Received: by bkwj5 with SMTP id j5so2430102bkw.37 for ; Thu, 19 Jul 2012 01:24:47 -0700 (PDT) Message-ID: <5007C44B.9030200@gmail.com> Date: Thu, 19 Jul 2012 10:24:43 +0200 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] gpt over luks - entire data disk encryption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Two Spirit Cc: dm-crypt@saout.de On 07/18/2012 11:46 PM, Two Spirit wrote: > After some corruptions to my luks environment, I get an opportunity to make some upgrades to my setup. > I need some help. I'm testing a raid5+1 environment, and would like to do whole data disk encryptions > with GPT. once I partition the disk using GPT, I can't run the "cryptsetup luksClose". I've done > whole disk encryption without a partition table with no problems, and I also have done luks encryption > on a GPT partition without problems. What's the exact dvice stack here? (paste lsblk output?) (You have GPT over LUKS device, not directly on /dev/mraid51, correct? > The only way I have found to be able to run luksClose is to blow away the partition table(which is not > acceptable solution). I suspect that udevadm (running ubuntu-12.04) is involved as a /dev/mapper/raid51p1 > exists. When I get rid of the /dev/mapper/raid51p1, and only the /dev/mapper/raid51 exists, I can then run "luksClose". Someone is running kpartx automatically... /dev/mapper/raid51p1 is created by kpartx (or some internal code somewhere) and it should _not_ be there, MD can handle partitions in kernel since 2.6.38 kernel. I see that problem on Fedora 17 as well. I will back to this later, not a LUKS problem but IMHO it is bug. I guess you can "dmsetup remove raid51p1" to get rid of this before shutdown, but it is wrong. For me, it even doesn't set DM-UUID (someone wrongly copied code from kpartx seems :-) Milan