DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yaron Sheffer <yaronf@gmx.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] UUID question
Date: Thu, 20 Dec 2012 13:16:12 +0200	[thread overview]
Message-ID: <50D2F37C.1000000@gmx.com> (raw)
In-Reply-To: <mailman.1.1356001202.8121.dm-crypt@saout.de>

Hi Sven,

a quick correction: blkid is (surprisingly) not smart enough, and your 
command line results in duplicates. Both the /dev (e.g. /dev/sdg) and 
the equivalent /dev/disk/by-uuid are listed.

So you want to use:

blkid -t TYPE="crypto_LUKS" -s UUID /dev/disk/by-uuid/*

(tested on Ubuntu 10.04 Lucid).

Thanks,
     Yaron

On 12/20/2012 01:00 PM, dm-crypt-request@saout.de wrote:
> Date: Thu, 20 Dec 2012 00:30:23 +0100
> From: "Sven Eschenberg" <sven@whgl.uni-frankfurt.de>
> To: dm-crypt@saout.de
> Subject: Re: [dm-crypt] UUID question
> Message-ID:
> 	<18e39b1120b315e7553bdb330e5103c5.squirrel@ssl.verfeiert.org>
> Content-Type: text/plain;charset=utf-8
>
> cryptsetup luksUUID <dev> will return the luks header's UUID if <dev>
> holds a luks header, and yes, this should usually not change the same way
> as the UUID of a filesystem souldn't.
>
> There's 2 problems though:
>
> 1.) You'd have to know <dev> in advance or iterate over all possible (non
> locked) blockdevices (which is what blkid usually does anyway for you)
>
> 2.) a blockdev could possibly hold a luks header and still be part of a md
> device (depending on metadata version), you'd better hope that the md
> device is set up already, when you issue your cryptsetup commands.
>
> Concerning the original question:
>
> The UUID within the LUKS header should not change throughout the LUKS
> volume's lifetime, except for enforced changes (as noted before).
>
> To associated keys based on luks UUID, using something like:
> 'blkid -t TYPE="crypto_LUKS" -s UUID'
> is probably a good starting point, as it gives you the UUID to retrieve
> the keys based on the UUID and the device inode you'd use on further calls
> to cryptsetup etc. - The rest is just a little shell magic ;-)
>
> Regards
>
> -Sven
>
>

       reply	other threads:[~2012-12-20 11:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1.1356001202.8121.dm-crypt@saout.de>
2012-12-20 11:16 ` Yaron Sheffer [this message]
2012-12-21  1:24   ` [dm-crypt] UUID question Sven Eschenberg
2012-12-18  0:10 David Li
2012-12-18  0:36 ` Arno Wagner
2012-12-18  8:12   ` Marc Ballarin
2012-12-18  8:57     ` Arno Wagner
2012-12-18 16:46       ` David Li
2012-12-19 23:30         ` Sven Eschenberg
2012-12-18  8:21   ` Milan Broz
2012-12-18  8:55     ` Arno Wagner

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=50D2F37C.1000000@gmx.com \
    --to=yaronf@gmx.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox