[dm-crypt] renaming of device

[dm-crypt] renaming of device

[Arno Wagner]

Cryptsetup seems to report the device in /dev/scsi/*
if they are present, instead of the device name 
mappings were created with. So I created with /dev/sdd
and status tells me I have /dev/scsi/sdh4-0c0i0l0,
which is really a problem because it could cause me 
to confuse devices and map them twice or the like.

Is there an easy way to map this back or turn off this
behaviour or list both device names? What I do at the 
moment is to look at major and minor of the reported 
device and than look up which traditional device this 
matches.

If this is a fundamental problem, I will likely
write a wrapper (something like crypt-status)
that does the lookup for me, but maybe there is 
an easier solution?

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 

Re: [dm-crypt] renaming of device

[Arno Wagner]

Just found out why I did not notice this before:
When the disk is not present at mount time, the 
respective entry is not created in /dev/scsi/
and you get the traditional output. I think
"status" should always give the traditional one 
as it has a fixed mapping between major/minor and 
device (see Documentation/devices.txt in the 
Linux sources), while the /dev/scsi/ entry has not.
Maybe have the device in /dev/scsi/ in addition, 
if present, e.g. like this:

root ~>cryptsetup status c1
/dev/mapper/c1 is active:
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/sdd (/dev/scsi/sdh4-0c0i0l0)
  offset:  0 sectors
  size:    1953525168 sectors
  mode:    read/write
root ~>

Arno


On Sun, Jan 10, 2010 at 04:16:59PM +0100, Arno Wagner wrote:
> Cryptsetup seems to report the device in /dev/scsi/*
> if they are present, instead of the device name 
> mappings were created with. So I created with /dev/sdd
> and status tells me I have /dev/scsi/sdh4-0c0i0l0,
> which is really a problem because it could cause me 
> to confuse devices and map them twice or the like.
> 
> Is there an easy way to map this back or turn off this
> behaviour or list both device names? What I do at the 
> moment is to look at major and minor of the reported 
> device and than look up which traditional device this 
> matches.
> 
> If this is a fundamental problem, I will likely
> write a wrapper (something like crypt-status)
> that does the lookup for me, but maybe there is 
> an easier solution?
> 
> 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 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
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 

Re: [dm-crypt] renaming of device

[Milan Broz]

On 01/10/2010 08:49 PM, Arno Wagner wrote:
> Just found out why I did not notice this before:
> When the disk is not present at mount time, the 
> respective entry is not created in /dev/scsi/
> and you get the traditional output. I think
> "status" should always give the traditional one 
> as it has a fixed mapping between major/minor and 
> device (see Documentation/devices.txt in the 
> Linux sources), while the /dev/scsi/ entry has not.

Cryptsetup simple tries to map major:minor number back
to device name in /dev.
(device-mapper know only major:minor pair - see dmsetup table)

The algorithm is very simple (and was probably written before
udev was used so these special links in /dev did not exist).

So it need to add some preferred names and not print the first entry.

Please can you add an issue to project pages to not forget about this?
Probably good idea to fix it in next minor release.

p.s. while the major:minor pair is fixed to device name,
device name is not fixed to real disk drive.
You can add some hw, or initialise modules in different order
and disk name changes e.g. from /dev/sdb to /dev/sdd.

Usually it is better use UUID instead of device name and use blkid
to search for device (blkid supports LUKS header).

Milan

Re: [dm-crypt] renaming of device

[Arno Wagner]

On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
> On 01/10/2010 08:49 PM, Arno Wagner wrote:
> > Just found out why I did not notice this before:
> > When the disk is not present at mount time, the 
> > respective entry is not created in /dev/scsi/
> > and you get the traditional output. I think
> > "status" should always give the traditional one 
> > as it has a fixed mapping between major/minor and 
> > device (see Documentation/devices.txt in the 
> > Linux sources), while the /dev/scsi/ entry has not.
> 
> Cryptsetup simple tries to map major:minor number back
> to device name in /dev.
> (device-mapper know only major:minor pair - see dmsetup table)
> 
> The algorithm is very simple (and was probably written before
> udev was used so these special links in /dev did not exist).

Ah, so it probably goes recursively and finds the entries
in /dev/scsi before /dev/sd<somthing>, because c comes
before d in lexicographic order.
 
> So it need to add some preferred names and not print the first entry.

Indeed. The mapping to the traditional names is static.
I can write a bit of code for it and contribute that.

> Please can you add an issue to project pages to not forget about this?
> Probably good idea to fix it in next minor release.

Done.

> p.s. while the major:minor pair is fixed to device name,
> device name is not fixed to real disk drive.
> You can add some hw, or initialise modules in different order
> and disk name changes e.g. from /dev/sdb to /dev/sdd.

I know.
 
> Usually it is better use UUID instead of device name and use blkid
> to search for device (blkid supports LUKS header).

Agreed. The issue I have is when I do manual mappings and then
want to check what I did. The problem is the the traditional
names are not directly clear from the udev scsi names.

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 

Re: [dm-crypt] renaming of device

[Luca Berra]

On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
>The algorithm is very simple (and was probably written before
>udev was used so these special links in /dev did not exist).
>
>So it need to add some preferred names and not print the first entry.
>
>Please can you add an issue to project pages to not forget about this?
>Probably good idea to fix it in next minor release.
it could be useful to have the functionality in device-mapper itself,
instead of duplicating in dm-crypt, lvm, dmraid, whatever ?

Regards,
L.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: [dm-crypt] renaming of device

[Sven Eschenberg]

Hi Luca,

I doubt this is possible. The only possible thing would be: Modify DM,
when a device name is passed in, to keep the passed in name alongside
the actual major:minor and provide an IOCTL, to access the information.

Regards

-Sven


On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
> On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
> >The algorithm is very simple (and was probably written before
> >udev was used so these special links in /dev did not exist).
> >
> >So it need to add some preferred names and not print the first entry.
> >
> >Please can you add an issue to project pages to not forget about this?
> >Probably good idea to fix it in next minor release.
> it could be useful to have the functionality in device-mapper itself,
> instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
> 
> Regards,
> L.
> 

Re: [dm-crypt] renaming of device

[Arno Wagner]

Having had a bit of time to think about it, it seems that
it would indeed be necessary to store the device name.

A possible alternative is to traverse all of /dev/ and
report all devices that match major/minor. This may be
the solution causing the least effort, as cryptsetup
is doing something like it already, just that it currently
stops after the first match.

In fact, I think I prefer for it to report all devices
that match. 

Arno


On Wed, Jan 13, 2010 at 11:20:36AM +0100, Sven Eschenberg wrote:
> Hi Luca,
> 
> I doubt this is possible. The only possible thing would be: Modify DM,
> when a device name is passed in, to keep the passed in name alongside
> the actual major:minor and provide an IOCTL, to access the information.
> 
> Regards
> 
> -Sven
> 
> 
> On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
> > On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
> > >The algorithm is very simple (and was probably written before
> > >udev was used so these special links in /dev did not exist).
> > >
> > >So it need to add some preferred names and not print the first entry.
> > >
> > >Please can you add an issue to project pages to not forget about this?
> > >Probably good idea to fix it in next minor release.
> > it could be useful to have the functionality in device-mapper itself,
> > instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
> > 
> > Regards,
> > L.
> > 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
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 

Re: [dm-crypt] renaming of device

[Sven Eschenberg]

Hi Arno,

Indeed cryyptsetup traverses /dev stating each file for major:minor and 
stops on the first match - at least a trace suggests this. The question 
is though, if this is an appropriated approach. One thing that annoys me 
  when doing this: There's no guarantee that device inodes are in /dev, 
nor links to it. In theory it cann be any place in the filesystem. there 
can be as many links as you want and as many inodes for the same device, 
as you want.

Regards

-Sven


Arno Wagner schrieb:
> Having had a bit of time to think about it, it seems that
> it would indeed be necessary to store the device name.
> 
> A possible alternative is to traverse all of /dev/ and
> report all devices that match major/minor. This may be
> the solution causing the least effort, as cryptsetup
> is doing something like it already, just that it currently
> stops after the first match.
> 
> In fact, I think I prefer for it to report all devices
> that match. 
> 
> Arno
> 
> 
> On Wed, Jan 13, 2010 at 11:20:36AM +0100, Sven Eschenberg wrote:
>> Hi Luca,
>>
>> I doubt this is possible. The only possible thing would be: Modify DM,
>> when a device name is passed in, to keep the passed in name alongside
>> the actual major:minor and provide an IOCTL, to access the information.
>>
>> Regards
>>
>> -Sven
>>
>>
>> On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
>>> On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
>>>> The algorithm is very simple (and was probably written before
>>>> udev was used so these special links in /dev did not exist).
>>>>
>>>> So it need to add some preferred names and not print the first entry.
>>>>
>>>> Please can you add an issue to project pages to not forget about this?
>>>> Probably good idea to fix it in next minor release.
>>> it could be useful to have the functionality in device-mapper itself,
>>> instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
>>>
>>> Regards,
>>> L.
>>>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
> 

Re: [dm-crypt] renaming of device

[Arno Wagner]

Well, I think listing all in /dev/ would be an improvement to
the current behaviour. Of course people can put their device
spceials somewhere else, but that is a pretty big break of
convention that IMO does not need to be supported.

Arno

On Wed, Jan 13, 2010 at 05:18:27PM +0100, Sven Eschenberg wrote:
> Hi Arno,
>
> Indeed cryyptsetup traverses /dev stating each file for major:minor and  
> stops on the first match - at least a trace suggests this. The question  
> is though, if this is an appropriated approach. One thing that annoys me  
>  when doing this: There's no guarantee that device inodes are in /dev,  
> nor links to it. In theory it cann be any place in the filesystem. there  
> can be as many links as you want and as many inodes for the same device,  
> as you want.
>
> Regards
>
> -Sven
>
>
> Arno Wagner schrieb:
>> Having had a bit of time to think about it, it seems that
>> it would indeed be necessary to store the device name.
>>
>> A possible alternative is to traverse all of /dev/ and
>> report all devices that match major/minor. This may be
>> the solution causing the least effort, as cryptsetup
>> is doing something like it already, just that it currently
>> stops after the first match.
>>
>> In fact, I think I prefer for it to report all devices
>> that match. 
>>
>> Arno
>>
>>
>> On Wed, Jan 13, 2010 at 11:20:36AM +0100, Sven Eschenberg wrote:
>>> Hi Luca,
>>>
>>> I doubt this is possible. The only possible thing would be: Modify DM,
>>> when a device name is passed in, to keep the passed in name alongside
>>> the actual major:minor and provide an IOCTL, to access the information.
>>>
>>> Regards
>>>
>>> -Sven
>>>
>>>
>>> On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
>>>> On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
>>>>> The algorithm is very simple (and was probably written before
>>>>> udev was used so these special links in /dev did not exist).
>>>>>
>>>>> So it need to add some preferred names and not print the first entry.
>>>>>
>>>>> Please can you add an issue to project pages to not forget about this?
>>>>> Probably good idea to fix it in next minor release.
>>>> it could be useful to have the functionality in device-mapper itself,
>>>> instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
>>>>
>>>> Regards,
>>>> L.
>>>>
>>>
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

-- 
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 

Re: [dm-crypt] renaming of device

[Sven Eschenberg]

Hi Arno,

Agreed.

Concerning the actual problem: This should not go into cryptsetup, it's 
not the right place. If we talk convetions, then the convention is: 
There is only ONE inode representing the device under /dev. If your 
hotplug manager (and it's configuration) creates multiple such entries, 
it is an indication for misconfiguration (imho). I.E.: Each device 
should have one physical identification (the inode carrying major:minor, 
together with the pathname) and as many logical names (via softlinks) as 
wanted. This guarantees that the right pathname can be found (not only 
for dmcrypt btw) and the device is yet useable via it's symbolic names 
(i.e. UUIDs, volume labels etc.).

If the preference of the system administrator is on UUID names, then 
those should be created as device files, and the 'traditional names' as 
softlinks. If yet there is a need to know all device names that link to 
a certain major:minor, then this can and should be done in a simple 
shell script, where it belongs in my opinion.

Just my 2 cents

Regards

-Sven



Arno Wagner schrieb:
> Well, I think listing all in /dev/ would be an improvement to
> the current behaviour. Of course people can put their device
> spceials somewhere else, but that is a pretty big break of
> convention that IMO does not need to be supported.
> 
> Arno
> 
> On Wed, Jan 13, 2010 at 05:18:27PM +0100, Sven Eschenberg wrote:
>> Hi Arno,
>>
>> Indeed cryyptsetup traverses /dev stating each file for major:minor and  
>> stops on the first match - at least a trace suggests this. The question  
>> is though, if this is an appropriated approach. One thing that annoys me  
>>  when doing this: There's no guarantee that device inodes are in /dev,  
>> nor links to it. In theory it cann be any place in the filesystem. there  
>> can be as many links as you want and as many inodes for the same device,  
>> as you want.
>>
>> Regards
>>
>> -Sven
>>
>>
>> Arno Wagner schrieb:
>>> Having had a bit of time to think about it, it seems that
>>> it would indeed be necessary to store the device name.
>>>
>>> A possible alternative is to traverse all of /dev/ and
>>> report all devices that match major/minor. This may be
>>> the solution causing the least effort, as cryptsetup
>>> is doing something like it already, just that it currently
>>> stops after the first match.
>>>
>>> In fact, I think I prefer for it to report all devices
>>> that match. 
>>>
>>> Arno
>>>
>>>
>>> On Wed, Jan 13, 2010 at 11:20:36AM +0100, Sven Eschenberg wrote:
>>>> Hi Luca,
>>>>
>>>> I doubt this is possible. The only possible thing would be: Modify DM,
>>>> when a device name is passed in, to keep the passed in name alongside
>>>> the actual major:minor and provide an IOCTL, to access the information.
>>>>
>>>> Regards
>>>>
>>>> -Sven
>>>>
>>>>
>>>> On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
>>>>> On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
>>>>>> The algorithm is very simple (and was probably written before
>>>>>> udev was used so these special links in /dev did not exist).
>>>>>>
>>>>>> So it need to add some preferred names and not print the first entry.
>>>>>>
>>>>>> Please can you add an issue to project pages to not forget about this?
>>>>>> Probably good idea to fix it in next minor release.
>>>>> it could be useful to have the functionality in device-mapper itself,
>>>>> instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
>>>>>
>>>>> Regards,
>>>>> L.
>>>>>
>>>> _______________________________________________
>>>> dm-crypt mailing list
>>>> dm-crypt@saout.de
>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
> 

Re: [dm-crypt] renaming of device

[Arno Wagner]

Hi Sven,

On Thu, Jan 14, 2010 at 07:18:50PM +0100, Sven Eschenberg wrote:
> Hi Arno,
>
> Agreed.
>
> Concerning the actual problem: This should not go into cryptsetup, it's  
> not the right place. 

Well, it is actually already in there, just at the moment it 
gives you the first it finds. I think it is acceptable to have
it in there, as cryptsetup already is a frontend. Writing a 
frontend for a frontend is a bit redundant.

> If we talk convetions, then the convention is:  
> There is only ONE inode representing the device under /dev. If your  
> hotplug manager (and it's configuration) creates multiple such entries,  
> it is an indication for misconfiguration (imho). I.E.: Each device  
> should have one physical identification (the inode carrying major:minor,  
> together with the pathname) and as many logical names (via softlinks) as  
> wanted. This guarantees that the right pathname can be found (not only  
> for dmcrypt btw) and the device is yet useable via it's symbolic names  
> (i.e. UUIDs, volume labels etc.).
>
> If the preference of the system administrator is on UUID names, then  
> those should be created as device files, and the 'traditional names' as  
> softlinks. If yet there is a need to know all device names that link to  
> a certain major:minor, then this can and should be done in a simple  
> shell script, where it belongs in my opinion.
>
> Just my 2 cents

I agree to that. It came when I added udev to my system, which
I do not like, and it creating devices under /dev/scsi/ is the
default under Debian. Clearly this has not been thought through.
As such broken configs can happen and it seems easily, it seems
they need to be expected. 

Arno




> Regards
>
> -Sven
>
>
>
> Arno Wagner schrieb:
>> Well, I think listing all in /dev/ would be an improvement to
>> the current behaviour. Of course people can put their device
>> spceials somewhere else, but that is a pretty big break of
>> convention that IMO does not need to be supported.
>>
>> Arno
>>
>> On Wed, Jan 13, 2010 at 05:18:27PM +0100, Sven Eschenberg wrote:
>>> Hi Arno,
>>>
>>> Indeed cryyptsetup traverses /dev stating each file for major:minor 
>>> and  stops on the first match - at least a trace suggests this. The 
>>> question  is though, if this is an appropriated approach. One thing 
>>> that annoys me   when doing this: There's no guarantee that device 
>>> inodes are in /dev,  nor links to it. In theory it cann be any place 
>>> in the filesystem. there  can be as many links as you want and as 
>>> many inodes for the same device,  as you want.
>>>
>>> Regards
>>>
>>> -Sven
>>>
>>>
>>> Arno Wagner schrieb:
>>>> Having had a bit of time to think about it, it seems that
>>>> it would indeed be necessary to store the device name.
>>>>
>>>> A possible alternative is to traverse all of /dev/ and
>>>> report all devices that match major/minor. This may be
>>>> the solution causing the least effort, as cryptsetup
>>>> is doing something like it already, just that it currently
>>>> stops after the first match.
>>>>
>>>> In fact, I think I prefer for it to report all devices
>>>> that match. 
>>>>
>>>> Arno
>>>>
>>>>
>>>> On Wed, Jan 13, 2010 at 11:20:36AM +0100, Sven Eschenberg wrote:
>>>>> Hi Luca,
>>>>>
>>>>> I doubt this is possible. The only possible thing would be: Modify DM,
>>>>> when a device name is passed in, to keep the passed in name alongside
>>>>> the actual major:minor and provide an IOCTL, to access the information.
>>>>>
>>>>> Regards
>>>>>
>>>>> -Sven
>>>>>
>>>>>
>>>>> On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
>>>>>> On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
>>>>>>> The algorithm is very simple (and was probably written before
>>>>>>> udev was used so these special links in /dev did not exist).
>>>>>>>
>>>>>>> So it need to add some preferred names and not print the first entry.
>>>>>>>
>>>>>>> Please can you add an issue to project pages to not forget about this?
>>>>>>> Probably good idea to fix it in next minor release.
>>>>>> it could be useful to have the functionality in device-mapper itself,
>>>>>> instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
>>>>>>
>>>>>> Regards,
>>>>>> L.
>>>>>>
>>>>> _______________________________________________
>>>>> dm-crypt mailing list
>>>>> dm-crypt@saout.de
>>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>>
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

-- 
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 

Re: [dm-crypt] renaming of device

[Sven Eschenberg]

Hi Arno,

What I was trying to say, I think the current behavior usually should do 
a good job, when there is only one device inode (as expected).

Concerning udev - you could either modify the configuration for the scsi 
subsystem, or you could copy it to you own rule file modify it and 
override debian's defaults.

This ways you are a little safer, when the distribution modifies some 
rules (for some odd reason) and are sure that dmcrypt returns the name 
you expect. In general this is true for most device names where you have 
special needs.

On my debian there are no rules for creating /dev/scsi/* names, at least 
not for scsi disks. Might be you are stuck with an older udev or some 
outdated configuration maybe?

Regards

-Sven


Arno Wagner schrieb:
> Hi Sven,
> 
> On Thu, Jan 14, 2010 at 07:18:50PM +0100, Sven Eschenberg wrote:
>> Hi Arno,
>>
>> Agreed.
>>
>> Concerning the actual problem: This should not go into cryptsetup, it's  
>> not the right place. 
> 
> Well, it is actually already in there, just at the moment it 
> gives you the first it finds. I think it is acceptable to have
> it in there, as cryptsetup already is a frontend. Writing a 
> frontend for a frontend is a bit redundant.
> 
>> If we talk convetions, then the convention is:  
>> There is only ONE inode representing the device under /dev. If your  
>> hotplug manager (and it's configuration) creates multiple such entries,  
>> it is an indication for misconfiguration (imho). I.E.: Each device  
>> should have one physical identification (the inode carrying major:minor,  
>> together with the pathname) and as many logical names (via softlinks) as  
>> wanted. This guarantees that the right pathname can be found (not only  
>> for dmcrypt btw) and the device is yet useable via it's symbolic names  
>> (i.e. UUIDs, volume labels etc.).
>>
>> If the preference of the system administrator is on UUID names, then  
>> those should be created as device files, and the 'traditional names' as  
>> softlinks. If yet there is a need to know all device names that link to  
>> a certain major:minor, then this can and should be done in a simple  
>> shell script, where it belongs in my opinion.
>>
>> Just my 2 cents
> 
> I agree to that. It came when I added udev to my system, which
> I do not like, and it creating devices under /dev/scsi/ is the
> default under Debian. Clearly this has not been thought through.
> As such broken configs can happen and it seems easily, it seems
> they need to be expected. 
> 
> Arno
> 
> 
> 
> 
>> Regards
>>
>> -Sven
>>
>>
>>
>> Arno Wagner schrieb:
>>> Well, I think listing all in /dev/ would be an improvement to
>>> the current behaviour. Of course people can put their device
>>> spceials somewhere else, but that is a pretty big break of
>>> convention that IMO does not need to be supported.
>>>
>>> Arno
>>>
>>> On Wed, Jan 13, 2010 at 05:18:27PM +0100, Sven Eschenberg wrote:
>>>> Hi Arno,
>>>>
>>>> Indeed cryyptsetup traverses /dev stating each file for major:minor 
>>>> and  stops on the first match - at least a trace suggests this. The 
>>>> question  is though, if this is an appropriated approach. One thing 
>>>> that annoys me   when doing this: There's no guarantee that device 
>>>> inodes are in /dev,  nor links to it. In theory it cann be any place 
>>>> in the filesystem. there  can be as many links as you want and as 
>>>> many inodes for the same device,  as you want.
>>>>
>>>> Regards
>>>>
>>>> -Sven
>>>>
>>>>
>>>> Arno Wagner schrieb:
>>>>> Having had a bit of time to think about it, it seems that
>>>>> it would indeed be necessary to store the device name.
>>>>>
>>>>> A possible alternative is to traverse all of /dev/ and
>>>>> report all devices that match major/minor. This may be
>>>>> the solution causing the least effort, as cryptsetup
>>>>> is doing something like it already, just that it currently
>>>>> stops after the first match.
>>>>>
>>>>> In fact, I think I prefer for it to report all devices
>>>>> that match. 
>>>>>
>>>>> Arno
>>>>>
>>>>>
>>>>> On Wed, Jan 13, 2010 at 11:20:36AM +0100, Sven Eschenberg wrote:
>>>>>> Hi Luca,
>>>>>>
>>>>>> I doubt this is possible. The only possible thing would be: Modify DM,
>>>>>> when a device name is passed in, to keep the passed in name alongside
>>>>>> the actual major:minor and provide an IOCTL, to access the information.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> -Sven
>>>>>>
>>>>>>
>>>>>> On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
>>>>>>> On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
>>>>>>>> The algorithm is very simple (and was probably written before
>>>>>>>> udev was used so these special links in /dev did not exist).
>>>>>>>>
>>>>>>>> So it need to add some preferred names and not print the first entry.
>>>>>>>>
>>>>>>>> Please can you add an issue to project pages to not forget about this?
>>>>>>>> Probably good idea to fix it in next minor release.
>>>>>>> it could be useful to have the functionality in device-mapper itself,
>>>>>>> instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
>>>>>>>
>>>>>>> Regards,
>>>>>>> L.
>>>>>>>
>>>>>> _______________________________________________
>>>>>> dm-crypt mailing list
>>>>>> dm-crypt@saout.de
>>>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>>>
>>>> _______________________________________________
>>>> dm-crypt mailing list
>>>> dm-crypt@saout.de
>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
> 

Re: [dm-crypt] renaming of device

[Arno Wagner]

On Thu, Jan 14, 2010 at 11:16:29PM +0100, Sven Eschenberg wrote:
> Hi Arno,
>
> What I was trying to say, I think the current behavior usually should do  
> a good job, when there is only one device inode (as expected).

Ok. 

> Concerning udev - you could either modify the configuration for the scsi  
> subsystem, or you could copy it to you own rule file modify it and  
> override debian's defaults.
>
> This ways you are a little safer, when the distribution modifies some  
> rules (for some odd reason) and are sure that dmcrypt returns the name  
> you expect. In general this is true for most device names where you have  
> special needs.
>
> On my debian there are no rules for creating /dev/scsi/* names, at least  
> not for scsi disks. Might be you are stuck with an older udev or some  
> outdated configuration maybe?

I don't know and do not really have time to investigate now.
Come to think of it, it could also have some connection to a
recent kernel upgrade, I am running 2.6.32.2 from kernel.org.
I did not notice the issue before, so maybe the kernel now also
creates device files and there was something about a device
pseudo filesystem or the like in the patchnotes.

Anyways, I will just look up major and minor numbers manually 
until cryptsetup either reports all matching in /dev/ or has
a preferred device for a major/minor combination.


> Regards
>
> -Sven
>
>
> Arno Wagner schrieb:
>> Hi Sven,
>>
>> On Thu, Jan 14, 2010 at 07:18:50PM +0100, Sven Eschenberg wrote:
>>> Hi Arno,
>>>
>>> Agreed.
>>>
>>> Concerning the actual problem: This should not go into cryptsetup, 
>>> it's  not the right place. 
>>
>> Well, it is actually already in there, just at the moment it gives you 
>> the first it finds. I think it is acceptable to have
>> it in there, as cryptsetup already is a frontend. Writing a frontend 
>> for a frontend is a bit redundant.
>>
>>> If we talk convetions, then the convention is:  There is only ONE 
>>> inode representing the device under /dev. If your  hotplug manager 
>>> (and it's configuration) creates multiple such entries,  it is an 
>>> indication for misconfiguration (imho). I.E.: Each device  should 
>>> have one physical identification (the inode carrying major:minor,   
>>> together with the pathname) and as many logical names (via softlinks) 
>>> as  wanted. This guarantees that the right pathname can be found (not 
>>> only  for dmcrypt btw) and the device is yet useable via it's 
>>> symbolic names  (i.e. UUIDs, volume labels etc.).
>>>
>>> If the preference of the system administrator is on UUID names, then  
>>> those should be created as device files, and the 'traditional names' 
>>> as  softlinks. If yet there is a need to know all device names that 
>>> link to  a certain major:minor, then this can and should be done in a 
>>> simple  shell script, where it belongs in my opinion.
>>>
>>> Just my 2 cents
>>
>> I agree to that. It came when I added udev to my system, which
>> I do not like, and it creating devices under /dev/scsi/ is the
>> default under Debian. Clearly this has not been thought through.
>> As such broken configs can happen and it seems easily, it seems
>> they need to be expected. 
>>
>> Arno
>>
>>
>>
>>
>>> Regards
>>>
>>> -Sven
>>>
>>>
>>>
>>> Arno Wagner schrieb:
>>>> Well, I think listing all in /dev/ would be an improvement to
>>>> the current behaviour. Of course people can put their device
>>>> spceials somewhere else, but that is a pretty big break of
>>>> convention that IMO does not need to be supported.
>>>>
>>>> Arno
>>>>
>>>> On Wed, Jan 13, 2010 at 05:18:27PM +0100, Sven Eschenberg wrote:
>>>>> Hi Arno,
>>>>>
>>>>> Indeed cryyptsetup traverses /dev stating each file for 
>>>>> major:minor and  stops on the first match - at least a trace 
>>>>> suggests this. The question  is though, if this is an 
>>>>> appropriated approach. One thing that annoys me   when doing 
>>>>> this: There's no guarantee that device inodes are in /dev,  nor 
>>>>> links to it. In theory it cann be any place in the filesystem. 
>>>>> there  can be as many links as you want and as many inodes for 
>>>>> the same device,  as you want.
>>>>>
>>>>> Regards
>>>>>
>>>>> -Sven
>>>>>
>>>>>
>>>>> Arno Wagner schrieb:
>>>>>> Having had a bit of time to think about it, it seems that
>>>>>> it would indeed be necessary to store the device name.
>>>>>>
>>>>>> A possible alternative is to traverse all of /dev/ and
>>>>>> report all devices that match major/minor. This may be
>>>>>> the solution causing the least effort, as cryptsetup
>>>>>> is doing something like it already, just that it currently
>>>>>> stops after the first match.
>>>>>>
>>>>>> In fact, I think I prefer for it to report all devices
>>>>>> that match. 
>>>>>>
>>>>>> Arno
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 13, 2010 at 11:20:36AM +0100, Sven Eschenberg wrote:
>>>>>>> Hi Luca,
>>>>>>>
>>>>>>> I doubt this is possible. The only possible thing would be: Modify DM,
>>>>>>> when a device name is passed in, to keep the passed in name alongside
>>>>>>> the actual major:minor and provide an IOCTL, to access the information.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> -Sven
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
>>>>>>>> On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
>>>>>>>>> The algorithm is very simple (and was probably written before
>>>>>>>>> udev was used so these special links in /dev did not exist).
>>>>>>>>>
>>>>>>>>> So it need to add some preferred names and not print the first entry.
>>>>>>>>>
>>>>>>>>> Please can you add an issue to project pages to not forget about this?
>>>>>>>>> Probably good idea to fix it in next minor release.
>>>>>>>> it could be useful to have the functionality in device-mapper itself,
>>>>>>>> instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> L.
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dm-crypt mailing list
>>>>>>> dm-crypt@saout.de
>>>>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>>>>
>>>>> _______________________________________________
>>>>> dm-crypt mailing list
>>>>> dm-crypt@saout.de
>>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>>
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

-- 
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 

Re: [dm-crypt] renaming of device

[Sven Eschenberg]

Arno Wagner schrieb:
> On Thu, Jan 14, 2010 at 11:16:29PM +0100, Sven Eschenberg wrote:
>> Hi Arno,
> 
>> Concerning udev - you could either modify the configuration for the scsi  
>> subsystem, or you could copy it to you own rule file modify it and  
>> override debian's defaults.
>>
>> This ways you are a little safer, when the distribution modifies some  
>> rules (for some odd reason) and are sure that dmcrypt returns the name  
>> you expect. In general this is true for most device names where you have  
>> special needs.
>>
>> On my debian there are no rules for creating /dev/scsi/* names, at least  
>> not for scsi disks. Might be you are stuck with an older udev or some  
>> outdated configuration maybe?
> 
> I don't know and do not really have time to investigate now.
> Come to think of it, it could also have some connection to a
> recent kernel upgrade, I am running 2.6.32.2 from kernel.org.
> I did not notice the issue before, so maybe the kernel now also
> creates device files and there was something about a device
> pseudo filesystem or the like in the patchnotes.

Ah, I guess you unfortunately actiavted kernel managed tmpfs in /dev, 
which is an experimental feature. Check for CONFIG_DEVTMPFS in your 
kernel config, I bet it is turned on.

> 
> Anyways, I will just look up major and minor numbers manually 
> until cryptsetup either reports all matching in /dev/ or has
> a preferred device for a major/minor combination.
> 
> 
>> Regards
>>
>> -Sven

Regards

-Sven

Re: [dm-crypt] renaming of device

[Arno Wagner]

On Fri, Jan 15, 2010 at 03:17:25AM +0100, Sven Eschenberg wrote:
> Arno Wagner schrieb:
>> On Thu, Jan 14, 2010 at 11:16:29PM +0100, Sven Eschenberg wrote:
>>> Hi Arno,
>>
>>> Concerning udev - you could either modify the configuration for the 
>>> scsi  subsystem, or you could copy it to you own rule file modify it 
>>> and  override debian's defaults.
>>>
>>> This ways you are a little safer, when the distribution modifies some 
>>>  rules (for some odd reason) and are sure that dmcrypt returns the 
>>> name  you expect. In general this is true for most device names where 
>>> you have  special needs.
>>>
>>> On my debian there are no rules for creating /dev/scsi/* names, at 
>>> least  not for scsi disks. Might be you are stuck with an older udev 
>>> or some  outdated configuration maybe?
>>
>> I don't know and do not really have time to investigate now.
>> Come to think of it, it could also have some connection to a
>> recent kernel upgrade, I am running 2.6.32.2 from kernel.org.
>> I did not notice the issue before, so maybe the kernel now also
>> creates device files and there was something about a device
>> pseudo filesystem or the like in the patchnotes.
>
> Ah, I guess you unfortunately actiavted kernel managed tmpfs in /dev,  
> which is an experimental feature. Check for CONFIG_DEVTMPFS in your  
> kernel config, I bet it is turned on.

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.

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 

Re: [dm-crypt] renaming of device

[Sven Eschenberg]

Arno Wagner schrieb:
> On Fri, Jan 15, 2010 at 03:17:25AM +0100, Sven Eschenberg wrote:
>> Arno Wagner schrieb:
>>> On Thu, Jan 14, 2010 at 11:16:29PM +0100, Sven Eschenberg wrote:
>>>> Hi Arno,
>>>> Concerning udev - you could either modify the configuration for the 
>>>> scsi  subsystem, or you could copy it to you own rule file modify it 
>>>> and  override debian's defaults.
>>>>
>>>> This ways you are a little safer, when the distribution modifies some 
>>>>  rules (for some odd reason) and are sure that dmcrypt returns the 
>>>> name  you expect. In general this is true for most device names where 
>>>> you have  special needs.
>>>>
>>>> On my debian there are no rules for creating /dev/scsi/* names, at 
>>>> least  not for scsi disks. Might be you are stuck with an older udev 
>>>> or some  outdated configuration maybe?
>>> I don't know and do not really have time to investigate now.
>>> Come to think of it, it could also have some connection to a
>>> recent kernel upgrade, I am running 2.6.32.2 from kernel.org.
>>> I did not notice the issue before, so maybe the kernel now also
>>> creates device files and there was something about a device
>>> pseudo filesystem or the like in the patchnotes.
>> Ah, I guess you unfortunately actiavted kernel managed tmpfs in /dev,  
>> which is an experimental feature. Check for CONFIG_DEVTMPFS in your  
>> kernel config, I bet it is turned on.
> 
> 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.
> 
> Arno
> 

Bummer.

And I feel with you, don't get me startet on hal's 'auto-magic' though, 
compared to hal udev is pretty well documented *g*.

Doesn't libdevmapper come with the lvm2 package? That makes it indeed a 
little difficult to change.

Regards

-Sven

Re: [dm-crypt] renaming of device

[Ross Boylan]

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.

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?

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.

Re: [dm-crypt] renaming of device

[Arno Wagner]

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 

Re: [dm-crypt] renaming of device

[Milan Broz]

On 01/16/2010 03:46 AM, Arno Wagner wrote:
> It does. Each possible /dev/sd<x> has a defined, fixed 
> major/minor, see Documentation/devices.txt in a Linux kernel 
> source tree.

so long thread:-)

Well, the situation is more complicated.

If cryptsetup uses only "real" block devices (like /dev/sdaX),
then fix to display proper device is is trivial.
(Parsing is in cryptsetup internal, not system libdevmapper currently.)

But if you have stacked devices "virtual block devices"
(crypt over MD or over LVM) it can be different - you want to see
/dev/VG/LV as device, not /dev/dm-X.

(btw dm-X names are not persistent and were intended to be kernel internal
only, unfortunately now are visible in userspace because of unified
udev event processing. And renaming these nodes to me more user-frientdly
in kernel is not easy because of various name length limits and different
approach for renaming of active DM devices) 

But the real problem now is that device-mapper library is just
in process of transition to udev (all nodes and symlinks will be created
by udev and not internally in libdevmapper).
And this changed (unified) some nodes to symlinks and vice versa.

With various maintainer's udev rules in various ditributions it creates nice
mix and Debian usually modifies even default rules for dm devices.

(Actually if you have an udev rule, which creates another node and not
symlink in /dev/scsi/..., it is  probably not correct, it should be symlink.)

Anyway, I'll plan to fix it somehow in next minor release of cryptsetup
(1.1.1 probably).

Milan

Re: [dm-crypt] renaming of device

[Arno Wagner]

On Sat, Jan 16, 2010 at 09:39:58AM +0100, Milan Broz wrote:
> On 01/16/2010 03:46 AM, Arno Wagner wrote:
> > It does. Each possible /dev/sd<x> has a defined, fixed 
> > major/minor, see Documentation/devices.txt in a Linux kernel 
> > source tree.
> 
> so long thread:-)
> 
> Well, the situation is more complicated.
> 
> If cryptsetup uses only "real" block devices (like /dev/sdaX),
> then fix to display proper device is is trivial.
> (Parsing is in cryptsetup internal, not system libdevmapper currently.)
> 
> But if you have stacked devices "virtual block devices"
> (crypt over MD or over LVM) it can be different - you want to see
> /dev/VG/LV as device, not /dev/dm-X.
> 
> (btw dm-X names are not persistent and were intended to be kernel internal
> only, unfortunately now are visible in userspace because of unified
> udev event processing. And renaming these nodes to me more user-frientdly
> in kernel is not easy because of various name length limits and different
> approach for renaming of active DM devices) 
> 
> But the real problem now is that device-mapper library is just
> in process of transition to udev (all nodes and symlinks will be created
> by udev and not internally in libdevmapper).
> And this changed (unified) some nodes to symlinks and vice versa.
> 
> With various maintainer's udev rules in various ditributions it creates nice
> mix and Debian usually modifies even default rules for dm devices.
> 
> (Actually if you have an udev rule, which creates another node and not
> symlink in /dev/scsi/..., it is  probably not correct, it should be symlink.)

I think so too, but I am unable to find it. Maybe I will just 
start to disable udev rules, until the behaviour goes away. 
Then I can file a bug report wth Debian.
 
> Anyway, I'll plan to fix it somehow in next minor release of cryptsetup
> (1.1.1 probably).

Looking forward to find out what your solutin will be ;-)

Arno




 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
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 

Re: [dm-crypt] renaming of device

[Sven Eschenberg]

Hi Milan,

Short question: When you say, libdevmapper supposely hands creation of
inodes and links to udev, do you mean really udev, or just creating
uevents, that can be handled by any hotplug processor?

That reminds me, just yesterday on one of my boxes I started getting a
message, that udev IIRC cannot create some inode, because it is already
existant (I guess cryptsetup created it as usual), I guess it's another
sign of those transisitions. On the other hand, dm-uvenets are still
marked experimental in current kernels.


Regards

-Sven


On Sat, January 16, 2010 09:39, Milan Broz wrote:
> On 01/16/2010 03:46 AM, Arno Wagner wrote:
>> It does. Each possible /dev/sd<x> has a defined, fixed
>> major/minor, see Documentation/devices.txt in a Linux kernel
>> source tree.
>
> so long thread:-)
>
> Well, the situation is more complicated.
>
> If cryptsetup uses only "real" block devices (like /dev/sdaX),
> then fix to display proper device is is trivial.
> (Parsing is in cryptsetup internal, not system libdevmapper currently.)
>
> But if you have stacked devices "virtual block devices"
> (crypt over MD or over LVM) it can be different - you want to see
> /dev/VG/LV as device, not /dev/dm-X.
>
> (btw dm-X names are not persistent and were intended to be kernel internal
> only, unfortunately now are visible in userspace because of unified
> udev event processing. And renaming these nodes to me more user-frientdly
> in kernel is not easy because of various name length limits and different
> approach for renaming of active DM devices)
>
> But the real problem now is that device-mapper library is just
> in process of transition to udev (all nodes and symlinks will be created
> by udev and not internally in libdevmapper).
> And this changed (unified) some nodes to symlinks and vice versa.
>
> With various maintainer's udev rules in various ditributions it creates
> nice
> mix and Debian usually modifies even default rules for dm devices.
>
> (Actually if you have an udev rule, which creates another node and not
> symlink in /dev/scsi/..., it is  probably not correct, it should be
> symlink.)
>
> Anyway, I'll plan to fix it somehow in next minor release of cryptsetup
> (1.1.1 probably).
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] renaming of device

[Milan Broz]

On 01/16/2010 07:52 PM, Sven Eschenberg wrote:
> Short question: When you say, libdevmapper supposely hands creation of
> inodes and links to udev, do you mean really udev, or just creating
> uevents, that can be handled by any hotplug processor?

Both. Block device uevents + required udev rules (provided by lvm2
device-mapper subpackage).

(Note the dm-uevents kernel configure option is only related to multipath path
notification, basic uevents related to DM devices are sent always).

Simplified, it works this way now:

 1) some sybsystem (lvm2, cryptsetup, etc) configures DM-device in kernel and waits for completion

 2) DM (kernel module) send uevent when the device is created/reconfigured/removed

 3) (hotplug) udev device-mapper rule processes event and update /dev/ layout (nodes, symlinks, etc.)
    then sends notification to waiting libdevmapper call from step 1)
    (this notification uses dmsetup triggered from udev rules and system-wide semaphores
     identified by cookie value)

There is still fallback to direct node manipulation - so if it prints something
like "Falling back to direct link creation." something is broken, but libdevmapper
tries to fix it (I guess this fallback will be removed in future.)

Proper device-mapper udev-enabled installation of this require
- recent kernel (>=2.6.31, it must support DM uevent cookie which identifies device)
- recent device-mapper userspace (part of lvm2, now includes also dm udev rules,
must be compiled with udev support)

(Just one note - device-mapper block devices are special, udev rules must react
to change/remove event and ignore "add" event. This is because add event is sent
by block layer too early but device mapper must initialize mapping table etc.)

Also other packages, which scan block devices (device-kit-disks aka udisks)
must be updated to not interfere with udev rules.

Also there was add new read-only uevent in 2.6.32 which breaks old udev rules
(this breaks cryptsetup operation also). So be sure you have new userspace
of everything related before using that udev machinery:-)


> That reminds me, just yesterday on one of my boxes I started getting a
> message, that udev IIRC cannot create some inode, because it is already
> existant (I guess cryptsetup created it as usual), I guess it's another
> sign of those transisitions.

Not sure - it depends if your distributions have all bits mentioned above ready,
and also this can be completely different problem.

I know only that Fedora rawhide now is fully dm udev enabled, not sure about other
distributions.

> On the other hand, dm-uvenets are still marked experimental in current kernels.

See above - this is not related, basic block device uevents are sent always.

Milan

Re: [dm-crypt] renaming of device

[Sven Eschenberg]

Hi Milan,

Thanks for yoru thorough reply, it helped correnting some
misinterpreatations (namely udev/multipath uevents) and get a better
overall picture.

Regards

-Sven

On Mon, January 18, 2010 15:06, Milan Broz wrote:
> On 01/16/2010 07:52 PM, Sven Eschenberg wrote:
>> Short question: When you say, libdevmapper supposely hands creation of
>> inodes and links to udev, do you mean really udev, or just creating
>> uevents, that can be handled by any hotplug processor?
>
> Both. Block device uevents + required udev rules (provided by lvm2
> device-mapper subpackage).
>
> (Note the dm-uevents kernel configure option is only related to multipath
> path
> notification, basic uevents related to DM devices are sent always).
>
> Simplified, it works this way now:
>
>  1) some sybsystem (lvm2, cryptsetup, etc) configures DM-device in kernel
> and waits for completion
>
>  2) DM (kernel module) send uevent when the device is
> created/reconfigured/removed
>
>  3) (hotplug) udev device-mapper rule processes event and update /dev/
> layout (nodes, symlinks, etc.)
>     then sends notification to waiting libdevmapper call from step 1)
>     (this notification uses dmsetup triggered from udev rules and
> system-wide semaphores
>      identified by cookie value)
>
> There is still fallback to direct node manipulation - so if it prints
> something
> like "Falling back to direct link creation." something is broken, but
> libdevmapper
> tries to fix it (I guess this fallback will be removed in future.)
>
> Proper device-mapper udev-enabled installation of this require
> - recent kernel (>=2.6.31, it must support DM uevent cookie which
> identifies device)
> - recent device-mapper userspace (part of lvm2, now includes also dm udev
> rules,
> must be compiled with udev support)
>
> (Just one note - device-mapper block devices are special, udev rules must
> react
> to change/remove event and ignore "add" event. This is because add event
> is sent
> by block layer too early but device mapper must initialize mapping table
> etc.)
>
> Also other packages, which scan block devices (device-kit-disks aka
> udisks)
> must be updated to not interfere with udev rules.
>
> Also there was add new read-only uevent in 2.6.32 which breaks old udev
> rules
> (this breaks cryptsetup operation also). So be sure you have new userspace
> of everything related before using that udev machinery:-)
>
>
>> That reminds me, just yesterday on one of my boxes I started getting a
>> message, that udev IIRC cannot create some inode, because it is already
>> existant (I guess cryptsetup created it as usual), I guess it's another
>> sign of those transisitions.
>
> Not sure - it depends if your distributions have all bits mentioned above
> ready,
> and also this can be completely different problem.
>
> I know only that Fedora rawhide now is fully dm udev enabled, not sure
> about other
> distributions.
>
>> On the other hand, dm-uvenets are still marked experimental in current
>> kernels.
>
> See above - this is not related, basic block device uevents are sent
> always.
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>