renaming of device
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
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
Quoted 33 lines · 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/sddand 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
Signature · 11 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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 [email protected] http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 8 lines · 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 (seeDocumentation/devices.txtin 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
Quoted 10 lines · Milan Broz
Quoted 8 lines · 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 (seeDocumentation/devices.txtin the Linux sources), while the/dev/scsi/entry has not.
Quoted 6 lines
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.
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 4 lines
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/sdbto/dev/sdd.
I know.
Quoted 2 lines
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 7 lines · Milan Broz
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.
Signature · 6 lines
Luca Berra -- [email protected] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \
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
Quoted 14 lines · Luca Berra
Quoted 7 lines · Milan Broz
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.
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
Quoted 33 lines · 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
Quoted 6 lines · Luca Berra
Quoted 5 lines · Milan Broz
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.
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
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
Quoted 49 lines · 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
Quoted 32 lines · 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
Quoted 6 lines · Luca Berra
Quoted 5 lines · Milan Broz
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.
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
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
Quoted 71 lines · 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
Quoted 9 lines · 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.Quoted 40 lines
In fact, I think I prefer for it to report all devices that match.
Arno
Quoted 32 lines · 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
Quoted 6 lines · Luca Berra
Quoted 5 lines · Milan Broz
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.
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
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
Quoted 73 lines · 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
Quoted 64 lines · 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
Quoted 9 lines · 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.Quoted 38 lines
In fact, I think I prefer for it to report all devices that match.
Arno
Quoted 31 lines · 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
Quoted 6 lines · Luca Berra
Quoted 5 lines · Milan Broz
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.
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Hi Sven,
Quoted 6 lines · Sven Eschenberg
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.
Quoted 10 lines
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.).
Quoted 7 lines
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
Quoted 90 lines
Regards
-Sven
Quoted 5 lines · 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.Quoted 72 lines
Arno
Quoted 68 lines · 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
Quoted 9 lines · 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.Quoted 38 lines
In fact, I think I prefer for it to report all devices that match.
Arno
Quoted 31 lines · 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
Quoted 6 lines · Luca Berra
Quoted 5 lines · Milan Broz
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.
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
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
Quoted 112 lines · Arno Wagner
Hi Sven,
Quoted 5 lines · Sven Eschenberg
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.
Quoted 5 lines
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
Quoted 82 lines
Regards
-Sven
Quoted 5 lines · 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.Quoted 65 lines
Arno
Quoted 62 lines · 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
Quoted 9 lines · 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.Quoted 38 lines
In fact, I think I prefer for it to report all devices that match.
Arno
Quoted 31 lines · 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
Quoted 6 lines · Luca Berra
Quoted 5 lines · Milan Broz
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.
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 4 lines · 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).
Ok.
Quoted 4 lines
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.
Quoted 8 lines
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.
Quoted 146 lines
Regards
-Sven
Quoted 33 lines · Arno Wagner
Hi Sven,
Quoted 6 lines · Sven Eschenberg
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.Quoted 10 lines
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.).
Quoted 7 lines
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
Quoted 101 lines
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
Quoted 89 lines
Regards
-Sven
Quoted 5 lines · 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.Quoted 72 lines
Arno
Quoted 69 lines · 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
Quoted 9 lines · 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.Quoted 38 lines
In fact, I think I prefer for it to report all devices that match.
Arno
Quoted 31 lines · 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
Quoted 6 lines · Luca Berra
Quoted 5 lines · Milan Broz
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.
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 7 lines · Arno Wagner
Quoted 6 lines · Sven Eschenberg
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 8 lines
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.Quoted 3 lines
Regards
-Sven
Regards
-Sven
Quoted 24 lines · Sven Eschenberg
Quoted 16 lines · Arno Wagner
Quoted 6 lines · Sven Eschenberg
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.
Quoted 8 lines
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?Quoted 6 lines
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.
Quoted 3 lines
Ah, I guess you unfortunately actiavted kernel managed tmpfs in /dev, which is an experimental feature. Check for
CONFIG_DEVTMPFSin 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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 25 lines · Arno Wagner
Quoted 9 lines · Sven Eschenberg
Quoted 8 lines · Arno Wagner
Quoted 7 lines · Sven Eschenberg
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.Quoted 8 lines
Quoted 7 lines
Quoted 1 line
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_DEVTMPFSin 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.
Quoted 6 lines
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 inlibdevmapper.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
Quoted 11 lines · Arno Wagner
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.
Quoted 12 lines · Ross Boylan
Quoted 11 lines · Arno Wagner
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.
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 10 lines
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 3 lines · Arno Wagner
It does. Each possible /dev/sd<x> has a defined, fixed major/minor, see
Documentation/devices.txtin 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
Quoted 28 lines · Milan Broz
Quoted 3 lines · Arno Wagner
It does. Each possible /dev/sd<x> has a defined, fixed major/minor, see
Documentation/devices.txtin 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/LVas 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.
Quoted 5 lines
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.
Quoted 2 lines
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
Quoted 6 lines
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
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
Quoted 45 lines · Milan Broz
Quoted 3 lines · Arno Wagner
It does. Each possible /dev/sd<x> has a defined, fixed major/minor, see
Documentation/devices.txtin 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/LVas 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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 3 lines · Sven Eschenberg
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:-)
Quoted 4 lines
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.
Quoted 1 line
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
Hi Milan,
Thanks for yoru thorough reply, it helped correnting some misinterpreatations (namely udev/multipath uevents) and get a better overall picture.
Regards
-Sven
Quoted 82 lines · Milan Broz
Quoted 3 lines · Sven Eschenberg
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 completion2) DM (kernel module) send uevent when the device is
created/reconfigured/removed3) (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:-)Quoted 4 lines
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.Quoted 2 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt