Re: RFC: new/changed udev rules - Part 1
Andrew Benton wrote: Let's teach people to administer their own system and not have them rely on magic scripts. Agreed. I can understand why distro maintainers want/need to have all these magic scripts/automatic rule generation. For LFS though, it makes more sense to educate folks as to how to customise CD-ROM symlinks for *their* hardware. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Jeremy Huntwork wrote: Alexander E. Patrakov wrote: Manual creation is also consistent with the situation with network devices in http://www.linuxfromscratch.org/lfs/view/development/chapter07/network.html. From what I've read so far, I'm leaning towards the manual creation. It's consistent with the rest of the book. And while there might very well be educational value in a script, I think there's more without it. +1 Let's teach people to administer their own system and not have them rely on magic scripts. Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
On Sun, May 14, 2006 at 10:20:57PM -0700, Jim Gifford wrote: > Dump the cdsymlinks scripts altogether and use the existing tools that > we have installed with udev. Use path_id and setup the rules based on that. This doesn't give device persistence, but rather location persistence. I've started a new thread that adds much more to think about. And yes, dumping the script and using the pre-existing tools is the way to go if we switch to manual creation of these rules. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Dump the cdsymlinks scripts altogether and use the existing tools that
we have installed with udev. Use path_id and setup the rules based on that.
On the systems, the users will need to run
/lib/udev/path_id /dev/{cdrom-device}
which would give output like this for SCSI
path_id /block/sr0
ID_PATH=pci-:01:0b.0-scsi-0:0:2:0
for IDE
path_id /block/hdc
ID_PATH=pci-:00:09.0-ide-1:0
Then we don't need these external scripts.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce Dubbs wrote:
Alexander E. Patrakov wrote:
So I propose to ditch the script from LFS and optionally move it to BLFS
or to a hint. LFS should provide readers with instructions to create the
relevant rules manually:
# Begin 82-persistent-cd.rules
# SAMSUNG_CD-ROM_SC-148F (pci-:00:07.1-ide-0:1)
ACTION=="add", BUS=="ide", ID=="0.1", SYMLINK+="cdrom"
# PHILIPS_CDD5301 (pci-:00:07.1-ide-1:1)
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrom1"
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrw1"
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="dvd1"
# End 82-persistent-cd.rules
I like this approach. It is actually fairly educational, not terribly
complex, and is not that different in concept from having the users fill
in their own fstab.
I do think there needs to be more comments into the appropriate values
of ID and how it would vary on individual systems. A comment on the
actual name of the device that udev sets would also be appropriate.
The rules above were just a copy-and-paste from the generated file. You can
certainly use any other attributes that won't change.
home:~# udevinfo -q all -n /dev/hdd
P: /block/hdd
N: hdd
S: disk/by-id/ata-PHILIPS_CDD5301_5VO1306DM00190
S: disk/by-path/pci-:00:07.1-ide-1:1
S: cdrom1
S: cdrw
S: dvd
E: ID_CDROM=1
E: ID_CDROM_CD_R=1
E: ID_CDROM_CD_RW=1
E: ID_CDROM_DVD=1
E: ID_CDROM_MRW=1
E: ID_CDROM_MRW_W=1
E: ID_CDROM_RAM=1
E: ID_TYPE=cd
E: ID_MODEL=PHILIPS_CDD5301
E: ID_SERIAL=5VO1306DM00190
E: ID_REVISION=B1.1
E: ID_BUS=ata
E: ID_PATH=pci-:00:07.1-ide-1:1
E: GENERATED=1
(look at lines beginning with E:, they represent environment variables)
home:~# udevinfo -a -p /block/hdd
udevinfo starts with the device the node belongs to and then walks up the
device chain, to print for every device found, all possibly useful attributes
in the udev key format.
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.
looking at device '/block/hdd':
KERNEL=="hdd"
SUBSYSTEM=="block"
SYSFS{stat}==" 000000
00000"
SYSFS{size}=="8388604"
SYSFS{removable}=="1"
SYSFS{range}=="1"
SYSFS{dev}=="22:64"
looking at device '/devices/pci:00/:00:07.1/ide1/1.1':
ID=="1.1"
BUS=="ide"
DRIVER=="ide-cdrom"
looking at device '/devices/pci:00/:00:07.1/ide1':
ID=="ide1"
BUS==""
DRIVER==""
looking at device '/devices/pci:00/:00:07.1':
ID==":00:07.1"
BUS=="pci"
DRIVER=="VIA_IDE"
SYSFS{modalias}=="pci:v1106d0571sv1458sd5002bc01sc01i8a"
SYSFS{local_cpus}=="1"
SYSFS{irq}=="0"
SYSFS{class}=="0x01018a"
SYSFS{subsystem_device}=="0x5002"
SYSFS{subsystem_vendor}=="0x1458"
SYSFS{device}=="0x0571"
SYSFS{vendor}=="0x1106"
looking at device '/devices/pci:00':
ID=="pci:00"
BUS==""
DRIVER==""
that's even more variables to look for. Therefore, _any_ of the rules below will
result in /dev/cdrom1 -> hdd symlink on my system:
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrom1"
ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_PATH}=="pci-:00:07.1-ide-1:1",
SYMLINK+="cdrom1"
ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_MODEL}=="PHILIPS_CDD5301",
SYMLINK+="cdrom1"
Or even, if one doesn't have add-on IDE boards (so that all of the IDE channels
are managed by one driver):
KERNEL=="hdd", SYMLINK+="cdrom1"
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Alexander E. Patrakov wrote: Manual creation is also consistent with the situation with network devices in http://www.linuxfromscratch.org/lfs/view/development/chapter07/network.html. From what I've read so far, I'm leaning towards the manual creation. It's consistent with the rest of the book. And while there might very well be educational value in a script, I think there's more without it. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Archaic wrote: On Mon, May 15, 2006 at 09:39:45AM +0600, Alexander E. Patrakov wrote: So I propose to ditch the script from LFS and optionally move it to BLFS or to a hint. LFS should provide readers with instructions to create the relevant rules manually: Manual would certainly avoid any and all race problems. But on the other hand, wouldn't it be pretty much as educational to edit the generated file? This is assuming that educational text explaining either situation is in the book. So a person wouldn't have to know the detail behind *how* the script works because they will be able to see the output of it when it generates the rules file that the book instructs them to edit. Manual creation is also consistent with the situation with network devices in http://www.linuxfromscratch.org/lfs/view/development/chapter07/network.html. OTOH, one could borrow a network device naming script (that generates rules on the first run) from Debian as well :) but it is not adapted to LFS yet. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Alexander E. Patrakov wrote: > So I propose to ditch the script from LFS and optionally move it to BLFS > or to a hint. LFS should provide readers with instructions to create the > relevant rules manually: > > # Begin 82-persistent-cd.rules > > # SAMSUNG_CD-ROM_SC-148F (pci-:00:07.1-ide-0:1) > ACTION=="add", BUS=="ide", ID=="0.1", SYMLINK+="cdrom" > # PHILIPS_CDD5301 (pci-:00:07.1-ide-1:1) > ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrom1" > ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrw1" > ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="dvd1" > > # End 82-persistent-cd.rules I like this approach. It is actually fairly educational, not terribly complex, and is not that different in concept from having the users fill in their own fstab. I do think there needs to be more comments into the appropriate values of ID and how it would vary on individual systems. A comment on the actual name of the device that udev sets would also be appropriate. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
On Mon, May 15, 2006 at 09:39:45AM +0600, Alexander E. Patrakov wrote: > > So I propose to ditch the script from LFS and optionally move it to BLFS or > to a hint. LFS should provide readers with instructions to create the > relevant rules manually: Manual would certainly avoid any and all race problems. But on the other hand, wouldn't it be pretty much as educational to edit the generated file? This is assuming that educational text explaining either situation is in the book. So a person wouldn't have to know the detail behind *how* the script works because they will be able to see the output of it when it generates the rules file that the book instructs them to edit. I'm indifferent on this. I see merit in both ways. However, if there is ever to be a cooperative udev configuration between the books, we will need community feedback. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
On Sun, May 14, 2006 at 08:09:49PM -0700, Jim Gifford wrote: > > So far my system that has 4 ide cd drives and 4 scsi devices, hasn't > seen any problems. From what I can see there has to be some way in sysfs > that we can use instead of using the Debian method, which something > about that script bugs me(a script that writes rules for itself doesn't > seem right to me) If the order of uevents isn't predictable (which it isn't) then the symlink cannot be predictable, either. Therefore, there is no persistance. It make take you 50 reboots for the order to be different, but the fact remains. Persistance is, as best as I can tell, accessing a device via a known symlink. The physical location of the drives is irrelevant to me, the end user, because I'm using the symlink, so I don't want to worry about whether it is /dev/hda, /dev/hdb, or whatever. So now, what happens if I add/remove/move hardware which cause driveX to change from /dev/hda to /dev/hdb. The symlink I had been using previously is now broken insofar that it isn't the device I expect it to be. This is why the current LFS method exists. A rule file will be generated for these devices only once. This generated file is completely customizable, and those device symlinks will never change. Plus, and new devices added will automatically be added to the generated file (again, each device is added only one time). It seems like a win-win. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Jim Gifford wrote:
Alexander E. Patrakov wrote:
NAK: racy. The helper script assumes that new devices don't appear in
/sys during operation.
So far in the testing we have had done, no issues have come up, we have
tried it with older hardware along with newer hardware.
Testing alone is insufficient. All scripts must be mathematically proved when it
is possible.
So far my system that has 4 ide cd drives and 4 scsi devices, hasn't
seen any problems. From what I can see there has to be some way in sysfs
that we can use instead of using the Debian method, which something
about that script bugs me(a script that writes rules for itself doesn't
seem right to me)
Think about this: udev processes uevents in _random_ order. Thus, to ensure that
each "cdromX" symlink will always point to the same drive, some on-disk database
has to be invented. A natural form of this database is a file with generated rules.
And this is not Debian-specific, Mandriva also does this, and not only for
CD-ROMs.
However, bugs are being reported against the script, see, e.g.,
http://bugs.debian.org/367265 (was never present in LFS, because I modified the
Debian script by adding ENV{ID_CDROM}=="1" to all rules). And the script is
definitely too complex and uneducational.
Moreover, invalid bugs like the following will certainly be filed:
The CD symlinks are wrong on my LFS system:
/dev/cdrom -> sr1
/dev/cdrom1 -> sr0
On the host (that doesn't use udev or uses old udev), the order is natural:
/dev/cdrom -> sr0
/dev/cdrom1 -> sr1
so the bug is somewhere in your book.
(that's just because the uevent for sr1 happened to be processed before sr0 on
the reporter's [aka: my] system)
So I propose to ditch the script from LFS and optionally move it to BLFS or to a
hint. LFS should provide readers with instructions to create the relevant rules
manually:
# Begin 82-persistent-cd.rules
# SAMSUNG_CD-ROM_SC-148F (pci-:00:07.1-ide-0:1)
ACTION=="add", BUS=="ide", ID=="0.1", SYMLINK+="cdrom"
# PHILIPS_CDD5301 (pci-:00:07.1-ide-1:1)
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrom1"
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrw1"
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="dvd1"
# End 82-persistent-cd.rules
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Alexander E. Patrakov wrote: NAK: racy. The helper script assumes that new devices don't appear in /sys during operation. So far in the testing we have had done, no issues have come up, we have tried it with older hardware along with newer hardware. So far my system that has 4 ide cd drives and 4 scsi devices, hasn't seen any problems. From what I can see there has to be some way in sysfs that we can use instead of using the Debian method, which something about that script bugs me(a script that writes rules for itself doesn't seem right to me) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Jim Gifford wrote: Archaic and all I came around an interesting way to fix the cd-symlink issue, without having to use the script that is in LFS.org repo. Just passing on the information I just learned hopefully it will be useful to someone. These new rules are in the udev-cross-lfs packages as of today, if you want to test them out. NAK: racy. The helper script assumes that new devices don't appear in /sys during operation. Also in SVN, you have: while [ $test -lt 1 ] ; do if [ -e /dev/cdrom$link ]; then link=$[$link+1] else test=1 echo $link fi done This is basically a reimplementation of the old "%e" escape that was deliberately removed because it is unreliable. The order in which udev processes uevents is undefined, thus, in some cases, hdd will be handled before hdb, and in other cases, the order will be the opposite. Thus, /dev/cdrom will point to a random CD-ROM. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
The thread was about the udev rules, cdsymlinks are in the rules that are in the archive. That's why I thought this would be the appropriate thread. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
On Sun, May 14, 2006 at 02:52:02PM -0700, Jim Gifford wrote: > Archaic and all I came around an interesting way to fix the cd-symlink > issue Jim, this thread is for discussion of what I posted. There was nothing about disks in my OP. Please start a new thread so people can distinguish between the various udev discussions. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce, Actually I made some bigger changes than that here's the link to the svn with the udev rules in it. http://trac.cross-lfs.org/browser/trunk/udev/35-helper.rules?rev=1640 http://trac.cross-lfs.org/browser/trunk/udev/cdsymlink_helper.sh?rev=1640 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce Dubbs wrote: > > Joe, > I was asking about the situation where I have my hard disk on sda and > a cdrom on hda AND hdb. It's probably not a smart way to go, but its > possible. > > -- Bruce > I set my vm back to normal and it's doing some work now so I'm not going to test. But what would make sense is that /dev/hda will be /dev/cdrom /dev/hdb will be /dev/cdrom0 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Joe Ciccone wrote: > Bruce Dubbs wrote: >> That's cool. What happens if there is a cdrom on hda too? >> > I put my harddrive on hdb and created a cdrom on hda. This has the same > pattern as the last one. > > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom -> hda > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom0 -> hdc > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom1 -> hdd > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom2 -> sr2 > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom3 -> sr3 > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom4 -> sr4 > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom5 -> sr5 > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom6 -> sr6 > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom7 -> sr7 > lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom8 -> sr8 Joe, I was asking about the situation where I have my hard disk on sda and a cdrom on hda AND hdb. It's probably not a smart way to go, but its possible. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce, I added a just in case feature. What do you think. KERN_NAME="$1" if [ "$KERN_NAME" = "" ]; then mesg Bad invocation: \$1 is not set exit 1 fi FILES="`ls /sys/bus/ide/drivers/ide-cdrom | grep '\.' `" for file in $FILES; do TEST="`ls /sys/bus/ide/drivers/ide-cdrom/$file | grep -c $KERN_NAME`" if [ "$TEST" = "1" ]; then link="`echo $file | cut -f2 -d.`" while [ $test -lt 1 ] ; do if [ -e /dev/cdrom$link ]; then link=$[$link+1] else test=1 fi done fi done -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce Dubbs wrote: > > That's cool. What happens if there is a cdrom on hda too? > I put my harddrive on hdb and created a cdrom on hda. This has the same pattern as the last one. lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom -> hda lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom0 -> hdc lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom1 -> hdd lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom2 -> sr2 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom3 -> sr3 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom4 -> sr4 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom5 -> sr5 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom6 -> sr6 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom7 -> sr7 lrwxrwxrwx 1 root root 3 2006-05-14 15:04 /dev/cdrom8 -> sr8 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce Dubbs wrote: I'm by no means an expert here, but does the GROUP do anything for a symlink that has 777 permissions? Or does that apply to the name when the actual device is created? I need to remove a lot of things in these rules before we go to production. How robust is this? It would seem to work if there are two cdroms, but does it generalize to the admittedly unusual case where there are more than two? I'm not sure how the drives are recognized. I only have one and it is at "/sys/bus/ide/drivers/ide-cdrom/0.0" What do the digits before and after the dot stand for? bus.device as in hda => 0.0 ... hdd => 1.1 ? Actually I may need to modify it a little, but it should be able to accommodate anything we through at it. I posted to hotplug list to, to get feedback from hotplug maintainers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Joe Ciccone wrote: > Bruce Dubbs wrote: >> How robust is this? It would seem to work if there are two cdroms, but >> does it generalize to the admittedly unusual case where there are more >> than two? I'm not sure how the drives are recognized. I only have one >> and it is at "/sys/bus/ide/drivers/ide-cdrom/0.0" What do the digits >> before and after the dot stand for? bus.device as in hda => 0.0 ... hdd >> => 1.1 ? >> >> Since my hard disk drive is sata and recognized as sda, would this work >> if I have a cdrom on hda and hdb? Hard coding the 1 doesn't seem to be >> right to me. >> >> > It seems to actualy be very robust, I just created a virtual machine > with a LOT of cdroms. > > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom -> hdb > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom0 -> hdc > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom1 -> hdd > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom2 -> sr2 > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom3 -> sr3 > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom4 -> sr4 > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom5 -> sr5 > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom6 -> sr6 > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom7 -> sr7 > lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom8 -> sr8 That's cool. What happens if there is a cdrom on hda too? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Bruce Dubbs wrote: > How robust is this? It would seem to work if there are two cdroms, but > does it generalize to the admittedly unusual case where there are more > than two? I'm not sure how the drives are recognized. I only have one > and it is at "/sys/bus/ide/drivers/ide-cdrom/0.0" What do the digits > before and after the dot stand for? bus.device as in hda => 0.0 ... hdd > => 1.1 ? > > Since my hard disk drive is sata and recognized as sda, would this work > if I have a cdrom on hda and hdb? Hard coding the 1 doesn't seem to be > right to me. > > It seems to actualy be very robust, I just created a virtual machine with a LOT of cdroms. lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom -> hdb lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom0 -> hdc lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom1 -> hdd lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom2 -> sr2 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom3 -> sr3 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom4 -> sr4 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom5 -> sr5 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom6 -> sr6 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom7 -> sr7 lrwxrwxrwx 1 root root 3 2006-05-14 14:24 /dev/cdrom8 -> sr8 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Jim Gifford wrote:
> Archaic and all I came around an interesting way to fix the cd-symlink
> issue, without having to use the script that is in LFS.org repo. Just
> passing on the information I just learned hopefully it will be useful to
> someone. These new rules are in the udev-cross-lfs packages as of today,
> if you want to test them out.
>
> For SCSI
>
> BUS=="scsi",KERNEL=="sr[0-9]*", ACTION=="add", IMPORT="cdrom_id
> --export $tempnode"
> BUS=="scsi",KERNEL="scd[a-z]", ACTION=="add", IMPORT="cdrom_id
> --export $tempnode"
> BUS=="scsi",KERNEL=="sg[0-9]*", ACTION=="add", DRIVER=="sr",
> GROUP="cdrom"
>
> BUS=="scsi", ENV{ID_CDROM}=="?*", SYMLINK+="cdrom%n", GROUP="cdrom"
I'm by no means an expert here, but does the GROUP do anything for a
symlink that has 777 permissions? Or does that apply to the name when
the actual device is created?
> BUS=="scsi", ENV{ID_CDROM_CD_R}=="?*", SYMLINK+="cdr%n"
> BUS=="scsi", ENV{ID_CDROM_CD_RW}=="?*", SYMLINK+="cdrw%n"
> BUS=="scsi", ENV{ID_CDROM_DVD}=="?*", SYMLINK+="dvd%n"
> BUS=="scsi", ENV{ID_CDROM_DVD_R}=="?*", SYMLINK+="dvdrw%n"
>
> For IDE
>
> BUS=="ide", KERNEL=="hd[a-z]", ACTION=="add", IMPORT="cdrom_id
> --export $tempnode"
>
> BUS=="ide", ENV{ID_CDROM}=="?*",PROGRAM="cdsymlink_helper.sh
> %k", SYMLINK+="cdrom%c", GROUP="cdrom"
> BUS=="ide", ENV{ID_CDROM_CD_R}=="?*", PROGRAM="cdsymlink_helper.sh
> %k", SYMLINK+="cdr%c"
> BUS=="ide", ENV{ID_CDROM_CD_RW}=="?*", PROGRAM="cdsymlink_helper.sh
> %k", SYMLINK+="cdrw%c"
> BUS=="ide", ENV{ID_CDROM_DVD}=="?*",PROGRAM="cdsymlink_helper.sh
> %k", SYMLINK+="dvd%c"
> BUS=="ide", ENV{ID_CDROM_DVD_R}=="?*", PROGRAM="cdsymlink_helper.sh
> %k", SYMLINK+="dvdrw%c"
>
> new file cdsymlink_helper
>
> KERN_NAME="$1"
>
> if [ "$KERN_NAME" = "" ]; then
>mesg Bad invocation: \$1 is not set
>exit 1
> fi
> FILES="`ls /sys/bus/ide/drivers/ide-cdrom | grep 1.`"
Isn't FILES here really a directory or directories? Or links to
directories?
>for file in $FILES; do
>TEST="`ls /sys/bus/ide/drivers/ide-cdrom/$file | grep -c
> $KERN_NAME`"
>if [ "$TEST" = "1" ]; then
>link="`echo $file | cut -f2 -d.`"
>echo $link
>fi
>done
>
How robust is this? It would seem to work if there are two cdroms, but
does it generalize to the admittedly unusual case where there are more
than two? I'm not sure how the drives are recognized. I only have one
and it is at "/sys/bus/ide/drivers/ide-cdrom/0.0" What do the digits
before and after the dot stand for? bus.device as in hda => 0.0 ... hdd
=> 1.1 ?
Since my hard disk drive is sata and recognized as sda, would this work
if I have a cdrom on hda and hdb? Hard coding the 1 doesn't seem to be
right to me.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Archaic and all I came around an interesting way to fix the cd-symlink
issue, without having to use the script that is in LFS.org repo. Just
passing on the information I just learned hopefully it will be useful to
someone. These new rules are in the udev-cross-lfs packages as of today,
if you want to test them out.
For SCSI
BUS=="scsi",KERNEL=="sr[0-9]*", ACTION=="add", IMPORT="cdrom_id
--export $tempnode"
BUS=="scsi",KERNEL="scd[a-z]", ACTION=="add", IMPORT="cdrom_id
--export $tempnode"
BUS=="scsi",KERNEL=="sg[0-9]*", ACTION=="add", DRIVER=="sr",
GROUP="cdrom"
BUS=="scsi", ENV{ID_CDROM}=="?*", SYMLINK+="cdrom%n", GROUP="cdrom"
BUS=="scsi", ENV{ID_CDROM_CD_R}=="?*", SYMLINK+="cdr%n"
BUS=="scsi", ENV{ID_CDROM_CD_RW}=="?*", SYMLINK+="cdrw%n"
BUS=="scsi", ENV{ID_CDROM_DVD}=="?*", SYMLINK+="dvd%n"
BUS=="scsi", ENV{ID_CDROM_DVD_R}=="?*", SYMLINK+="dvdrw%n"
For IDE
BUS=="ide", KERNEL=="hd[a-z]", ACTION=="add", IMPORT="cdrom_id
--export $tempnode"
BUS=="ide", ENV{ID_CDROM}=="?*",PROGRAM="cdsymlink_helper.sh
%k", SYMLINK+="cdrom%c", GROUP="cdrom"
BUS=="ide", ENV{ID_CDROM_CD_R}=="?*", PROGRAM="cdsymlink_helper.sh
%k", SYMLINK+="cdr%c"
BUS=="ide", ENV{ID_CDROM_CD_RW}=="?*", PROGRAM="cdsymlink_helper.sh
%k", SYMLINK+="cdrw%c"
BUS=="ide", ENV{ID_CDROM_DVD}=="?*",PROGRAM="cdsymlink_helper.sh
%k", SYMLINK+="dvd%c"
BUS=="ide", ENV{ID_CDROM_DVD_R}=="?*", PROGRAM="cdsymlink_helper.sh
%k", SYMLINK+="dvdrw%c"
new file cdsymlink_helper
KERN_NAME="$1"
if [ "$KERN_NAME" = "" ]; then
mesg Bad invocation: \$1 is not set
exit 1
fi
FILES="`ls /sys/bus/ide/drivers/ide-cdrom | grep 1.`"
for file in $FILES; do
TEST="`ls /sys/bus/ide/drivers/ide-cdrom/$file | grep -c
$KERN_NAME`"
if [ "$TEST" = "1" ]; then
link="`echo $file | cut -f2 -d.`"
echo $link
fi
done
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Archaic wrote: KERNEL=="rtc", MODE="664" # Changed from 666. The distros disagree on mode, but none allow world write. They are right: you don't want random users to set the hardware clock. And read-only access is still useful for high-precision timing (and used, e.g., by qemu). KERNEL=="tty[0-9]*",MODE="620" GROUP="tty" # Changed from 666 (too lax). Need to ensure this doesn't break anything. A live # debian box shows 620, but the rules show 666. That's because the "login" program sets permissions. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Jim Gifford wrote: Archaic wrote: This is preliminary. I'm still working through the rest of the rules. This covers the first 3 sections of the current 25-lfs.rules file. **NOTE** Due to the size of this email, PLEASE make heavy use of trimming (like stripping my comments and keeping just the rule you are replying to) so the thread stays readable. ...and then he ignored the above text and quoted the whole message. Jim, please learn to trim the message down to just the bits that you need to quote so that people know what you're talking about. Not too much. Not too little. Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
On Sat, May 13, 2006 at 01:12:17PM -0600, Archaic wrote: > This is preliminary. I'm still working through the rest of the rules. > This covers the first 3 sections of the current 25-lfs.rules file. > > KERNEL=="capi", NAME="capi20", > SYMLINK+="isdn/capi20" > > KERNEL=="capi*", NAME="capi/%n" > # Changed the [0-9]* regex to the more simple and equally matching *. According to the document "Writing rules for udev" included in the udev 092 tarball (which does, however, seem to be slightly out of date), this is not the case. "The * operator is used here, which matches literally anything - zero, one, or more characters of any kind." So capi* will match capi (which is apparently a possible device, judging by the previous rule), but cape[0-9]* won't. The only way the old and new patterns would be equivalent is if KERNEL matches NAMEs that have been set earlier on, which is non-intuitive if it is the case (I'd expect KERNEL to match the name the kernel gave it, and only that name). > KERNEL=="vcs*", GROUP="tty" This should match vcs for the same reason, so the additional rule in the second email (KERNEL=="vcs") should be unnecessary. Alex :-) -- Pippin Computer Monkey to the Pelican www.oxrev.org.uk, www.corpusjcr.org, www.rev.org.uk Internal: 30741, external: 0870 2760741 pgpCrplzBBpbG.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: new/changed udev rules - Part 1
Archaic wrote: This is preliminary. I'm still working through the rest of the rules. This covers the first 3 sections of the current 25-lfs.rules file. **NOTE** Due to the size of this email, PLEASE make heavy use of trimming (like stripping my comments and keeping just the rule you are replying to) so the thread stays readable. # Changed all modes of 0xxx to just xxx and I didn't list that as a change in # the individual rules' notes. Otherwise, any changes I make will be listed and # differences to CLFS will be noted (except last_rule). # # When referring to "all others" or "other distros", I'm referring to the rules # in the udev-092 tarball which are debian, frugalware, gentoo, redhat, # slackware, and SuSe. # # The last_rule line will show any of the above listed distros known to use # that option for the given device(s). # Core kernel devices KERNEL=="mem", MODE="640", GROUP="kmem" # No change # (clfs) NAME="%k" is unneeded # last_rule - redhat KERNEL=="kmem", MODE="640", GROUP="kmem" # No change # (clfs) NAME="%k" is unneeded # last_rule - redhat KERNEL=="null", MODE="666" # No change # (clfs) NAME="%k" is unneeded # last_rule - redhat KERNEL=="port", MODE="640", GROUP="kmem" # No change # (clfs) NAME="%k" is unneeded # last_rule - redhat KERNEL=="zero", MODE="666" # No change # (clfs) NAME="%k" is unneeded # last_rule - redhat KERNEL=="full", MODE="666" # No change # (clfs) NAME="%k" is unneeded # (clfs) 622 (SuSe-specific. All others use 666) # last_rule - redhat KERNEL=="random", MODE="664" # Changed from 444 # (clfs) NAME="%k" is unneeded # (clfs) 666 is too lax # last_rule - redhat KERNEL=="urandom", MODE="664" # Changed from 444 # (clfs) NAME="%k" is unneeded # (clfs) 644 (but 664 facilitates someone adding a group assignment later) # last_rule - redhat #KERNEL=="aio", MODE="444" # Commented out (not found in any other distro and requires a kernel patch) #KERNEL=="kmsg", MODE="600" # Commented out (not found in any other distro and 660 root:root is fine) KERNEL=="rtc", MODE="664" # Changed from 666. The distros disagree on mode, but none allow world write. # (clfs) Uses default perms (660) and audio group. # last_rule - none # TTY devices (both communications and terminal types) SUBSYSTEM=="tty", GROUP="dialout" # Added # This rule is a catchall that replaces many of the rules in lfs/clfs. Any later # rule that matches tty subsystem devices will override (or modify) this generic # rule. For example, some tty subsystem need a different group, mode, or name, # or need a symlink. # (clfs) doesn't have this rule. # Never use last_rule on this KERNEL=="ptmx", MODE="666", GROUP="tty" # No change # (clfs) NAME="%k" is unneeded # last_rule - redhat KERNEL=="pty[p-za-e]*", MODE="666", GROUP="tty" KERNEL=="tty[p-za-e]*", GROUP="tty" # Added # (clfs) uses a different match pattern and makes the tty part 666, but 660 is # preferred. When the tty is in use, pt_chown will set the needed perms. # last_rule - debian, gentoo, redhat, suse KERNEL=="capi", NAME="capi20", SYMLINK+="isdn/capi20" # Changed SYMLINK= to SYMLINK+=. All this does is allow for multiple symlinks # should the admin want to add another. It's the generally preferred syntax for # SYMLINK now. # (clfs) doesn't have this rule. # last_rule - none KERNEL=="capi*", NAME="capi/%n" # Changed the [0-9]* regex to the more simple and equally matching *. # (clfs) doesn't have this rule. # last_rule - none KERNEL=="tty", MODE="666", GROUP="tty" # No change # (clfs) NAME="%k" is unneeded # last_rule - debian, gentoo, redhat, suse KERNEL=="tty[0-9]*",MODE="620" GROUP="tty" # Changed from 666 (too lax). Need to ensure this doesn't break anything. A live # debian box shows 620, but the rules show 666. # (clfs) NAME="%k" is unneeded # last_rule - debian, gentoo, redhat, suse KERNEL=="vcs*", GROUP="tty" # Changed from 600 to default # (clfs) NAME="%k" is unneeded and 620 is suse-specific. All others use default. # last_rule - gentoo, redhat, suse KERNEL=="console", MODE="600" GROUP="tty" # Changed from 622 # (clfs) NAME="%k" is unneeded # last_rule - debian, redhat, suse %k is probably not needed, but was needed at one time, it can probably be removed in the clfs rules, but since it hasn't been tested. The "vcs*" should catch all of the vcs devices no need to have a separate one just for vcs. Why duplicate the effort. As far as the difference on the permissions it depends on the builder. If we were building a High Security System, a lot of things would be different. There is no right/wrong way, it's a SWAG at best. But not bad for a base
Re: RFC: new/changed udev rules - Part 1
On Sat, May 13, 2006 at 01:12:17PM -0600, Archaic wrote: > > KERNEL=="vcs*", GROUP="tty" Forgot one that isn't matched by the above: KERNEL=="vcs", GROUP="tty" # Added # (clfs) doesn't have this rule last_rule - redhat -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
