All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] renaming of device
Date: Sat, 16 Jan 2010 03:46:45 +0100	[thread overview]
Message-ID: <20100116024645.GA11543@tansi.org> (raw)
In-Reply-To: <1263601811.26202.72.camel@corn.betterworld.us>

On Fri, Jan 15, 2010 at 04:30:11PM -0800, Ross Boylan wrote:
> On Fri, 2010-01-15 at 04:58 +0100, Arno Wagner wrote:
> > 
> > Good idea, but no. Must be something in the udev configuration
> > after all. Not that I found anything. Or anything in the logs.
> > Hmm. Oh, well. It is not that important. But I really hate this
> > badly documented obscure "automagical" stuff. As soon as anything
> > breaks, it really sucks. 
> > 
> > On the side of where cryptsetup finds the device for a specific
> > major and minor number, it is indeed a simple recursive directory
> > traversal. Unfortunately it is in libdevmapper.c, i.e. in the 
> > system lib of that name. That means it cannot easily be changed.
> I have a comment and a question.
> 
> The comment is that I think udev on Debian has some private place that
> it stashes away mappings so that network cards (for sure) and disks (I
> think) have stable names.  I think it's a Debian-specific feature,
> though other distros may do something similar.

May well be that way. However I am pretty sure I do not have stable
disk names. I did have stable network card names, but disabled
that feature, since I swap network cards from time to time
and need to manually adjust anyways.
 
> The question concerns the use of major:minor to identify devices.  I
> thought the same physical device can have different major:minor on
> different boots.*  Is that so, and if so, can it cause problems for
> dm-crypt, such as causing it to pick the wrong underlying volume?

dm-crypt does not do any aoutomation, but if a boot script
were to give the same device to dm-crypt when the mapping has 
changed, that will cause problems. However the mapping can also
change when changing the partitioning, with much the same effects.


> I'm pretty ignorant in this area so a) take what I say with a grain of
> salt and b) I'd appreciate any wisdom.
> 
> Thanks.
> 
> Ross Boylan
> 
> *I think the Debian stuff stabilizes the relation between physical
> devices and names like /dev/sdd, but not necessarily physical devices
> and major:minor.

It does. Each possible /dev/sd<x> has a defined, fixed 
major/minor, see Documentation/devices.txt in a Linux kernel 
source tree.

Arno 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

  reply	other threads:[~2010-01-16  2:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-10 15:16 [dm-crypt] renaming of device Arno Wagner
2010-01-10 19:49 ` Arno Wagner
2010-01-10 20:33   ` Milan Broz
2010-01-11 16:17     ` Arno Wagner
2010-01-13  7:01     ` Luca Berra
2010-01-13 10:20       ` Sven Eschenberg
2010-01-13 13:13         ` Arno Wagner
2010-01-13 16:18           ` Sven Eschenberg
2010-01-13 17:29             ` Arno Wagner
2010-01-14 18:18               ` Sven Eschenberg
2010-01-14 21:42                 ` Arno Wagner
2010-01-14 22:16                   ` Sven Eschenberg
2010-01-14 22:46                     ` Arno Wagner
2010-01-15  2:17                       ` Sven Eschenberg
2010-01-15  3:58                         ` Arno Wagner
2010-01-15 11:28                           ` Sven Eschenberg
2010-01-16  0:30                           ` Ross Boylan
2010-01-16  2:46                             ` Arno Wagner [this message]
2010-01-16  8:39                               ` Milan Broz
2010-01-16 16:22                                 ` Arno Wagner
2010-01-16 18:52                                 ` Sven Eschenberg
2010-01-18 14:06                                   ` Milan Broz
2010-01-18 14:58                                     ` 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=20100116024645.GA11543@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.