FS#4419 - udev 089 Breaks cdrom and cdrw Symlinks
Attached to Project:
Arch Linux
Opened by Rob (RobK) - Sunday, 09 April 2006, 13:39 GMT
Last edited by arjan timmerman (blaasvis) - Sunday, 09 April 2006, 14:03 GMT
Opened by Rob (RobK) - Sunday, 09 April 2006, 13:39 GMT
Last edited by arjan timmerman (blaasvis) - Sunday, 09 April 2006, 14:03 GMT
|
Details
I upgraded recently from udev 088 to udev 089. It would
appear that udev 089 has broken the /dev/cdrom and /dev/cdrw
symlinks.
# ls /dev/cdrom ls: /dev/cdrom: No such file or directory # ls /dev/cd* ls: /dev/cd* : No such file or directory I have configured /etc/udev/cdsymlinks.conf as follows: OUTPUT="CD CDRW" NUMBERED_LINKS=1 LINK_ZERO=0 I have tried running /etc/start_udev. /etc/start_udev runs with no errors but I still do not have a /dev/cdrom symlink. I also tried creating my own udev rule 10-local.rules which I placed in the /etc/udev/rules.d directory. My 10-local.rules file reads as follows: KERNEL=="scd0", SYMLINK="cdwriter" /dev/scd0 is the device node for my CDRW burner. udev does create it. But even if one manually runs /dev/scd0, udev never creates the /dev/cdwriter symlink or the /dev/cdrw symlink. Any ideas? Rob |
This task depends upon
But even if one manually runs /etc/udev_start, udev never creates the /dev/cdwriter symlink or the /dev/cdrw symlink.
Rob
P.S. I can access the cdrom and the CDRW burner but not through the usual /dev/cdrom or /dev/cdrw symlinks. If you look at the forums, it looks like I am not the only one having problems with the cdrom or cdrw symlinks.
But there is a bug which reproduces on my system everytime. My simple rule in my 10-local.rules file never creates the /dev/cdwriter symlink. It used to. Now it never does. This is very strange.
I have also noticed some very strange symlink behaviour. When my external CDRW burner drive is hotplugged or coldplugged, the following symlinks are sometimes created (P.S. they should be created everytime):
[rob@myarch ~]$ ls /dev/cd* -l
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom0 -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom1 -> /dev/cd/cdrom-sr0
lrwxrwxrwx 1 root root 16 2006-04-09 16:32 /dev/cdrw -> /dev/cd/cdrw-sr0
lrwxrwxrwx 1 root root 16 2006-04-09 16:32 /dev/cdrw0 -> /dev/cd/cdrw-sr0
/dev/cd:
total 0
lrwxrwxrwx 1 root root 6 2006-04-09 12:27 cdrom-hdc -> ../hdc
lrwxrwxrwx 1 root root 7 2006-04-09 16:32 cdrom-sr0 -> ../scd0
lrwxrwxrwx 1 root root 7 2006-04-09 16:32 cdrw-sr0 -> ../scd0
[rob@myarch ~]$
When I unplpug the external CDRW burner, many of the cdrw links still remain. See:
[rob@myarch ~]$ ls /dev/cd* -l
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom0 -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom1 -> /dev/cd/cdrom-sr0
lrwxrwxrwx 1 root root 16 2006-04-09 16:32 /dev/cdrw -> /dev/cd/cdrw-sr0
lrwxrwxrwx 1 root root 16 2006-04-09 16:32 /dev/cdrw0 -> /dev/cd/cdrw-sr0
/dev/cd:
total 0
lrwxrwxrwx 1 root root 6 2006-04-09 12:27 cdrom-hdc -> ../hdc
[rob@myarch ~]$
Hmm. All the burner CDRW symlinks should be removed. They aren't.
I tried commenting out all the parameters in /etc/udev/cdsymlinks.conf. It had no effect. It would appear that this configuration file is not being used.
I am also running another computer with Frugalware Linux using 2.6.16 kernel and udev 089. When I plug in the external USB drive, the following symlinks are created:
/dev/cdrom --> hdc (This symlink is always there for my built-in cdrom drive)
/dev/cdrom1 --> sr0
/dev/cdrw --> sr0
/dev/cdwriter --> sr0
When I unplug the external CDRW burner, only the /dev/cdrom symlink remains. The way it should be. It looks like arch is doing something different.
To summarize, it would appear that udev in arch is NOT recognizing my simple rule in my 10-local.rules file. udev in arch is also NOT removing the useless cdrw related symlinks when the external cdrw drive is removed.
I also hope that the flakey behaviour of udev in creating symlinks can be tracked down. This creates problems when the /dev/cdrom or /dev/cdrw symlink is NOT created by udev especially at bootup.
Rob
does it help if you change this to KERNEL=="scd[0-9]*"
and also on the remove line
i.e. udev should be looking at all the files in the /etc/udev/rules.d directory.
Rob
Rob
please disable your probably broken rules, that the standard rules can work.
I also checked to see if I had the following rules in udev.rules:
BUS=="scsi", KERNEL=="sg[0-9]*", SYSFS{type}=="5", RUN+="/lib/udev/cdsymlinks.sh"
ACTION =="remove", BUS=="scsi", KERNEL=="sg[0-9]*", SYSFS{type}=="5", RUN+="/lib/udev/cdsymlinks.sh"
The two rules are there since it would appear that this rule is part of the standard udev.rules file in arch.
I then ran /etc/start_udev. When I plug in my external harddrive, the following symlinks appear:
[rob@myarch ~]$ ls /dev/cd* -l
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom0 -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom1 -> /dev/cd/cdrom-sr0
lrwxrwxrwx 1 root root 16 2006-04-09 16:32 /dev/cdrw -> /dev/cd/cdrw-sr0
lrwxrwxrwx 1 root root 16 2006-04-09 16:32 /dev/cdrw0 -> /dev/cd/cdrw-sr0
/dev/cd:
total 0
lrwxrwxrwx 1 root root 6 2006-04-09 12:27 cdrom-hdc -> ../hdc
lrwxrwxrwx 1 root root 7 2006-04-09 16:32 cdrom-sr0 -> ../scd0
lrwxrwxrwx 1 root root 7 2006-04-09 16:32 cdrw-sr0 -> ../scd0
[rob@myarch ~]$
When I unplpug the external CDRW burner, many of the cdrw links still remain. See:
[rob@myarch ~]$ ls /dev/cd* -l
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom0 -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-09 16:32 /dev/cdrom1 -> /dev/cd/cdrom-sr0
lrwxrwxrwx 1 root root 16 2006-04-09 16:32 /dev/cdrw -> /dev/cd/cdrw-sr0
lrwxrwxrwx 1 root root 16 2006-04-09 16:32 /dev/cdrw0 -> /dev/cd/cdrw-sr0
/dev/cd:
total 0
lrwxrwxrwx 1 root root 6 2006-04-09 12:27 cdrom-hdc -> ../hdc
[rob@myarch ~]$
Hmm. All the burner CDRW symlinks are still not being removed.
I also tried changing KERNEL=="sg[0-9]*" to KERNEL=="scd[0-9]*" in the two rules. Then I ran /etc/start_udev. It did not make a difference. The same behaviour occurred.
I see these rules run a script. When I have some more time, I will take a look at your /lib/udev/cdsymlinks.sh script to see if I can see anything that might be the cause.
Rob
P.S. The only thing that might be different on my system than yours is the preseence of backpackusb.rules. These rules detect my cd burner and load firmware into the burner using fxload. I highly doubt this is the cause. I have these rules on other computers and they work well. I will post them for you to see.
#these are the entries for bpck-usb devices
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0000", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0001", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1000", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1001", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1002", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1003", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1004", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1005", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1006", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1007", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0010", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0011", RUN+="/lib/udev/backpackusb.sh"
And here is the script to load the firmware into the drive:
[rob@myarch ~]$ cat /lib/udev/backpackusb.sh
#!/bin/sh
# Load bulk/interrupt transfer test firmware into
# various EZ-USB USB devices that will run it
#TEMPLATE PROGRAM TAKEN FROM http://linux-hotplug.sourceforge.net/perf 4/2/2002
#Adapted for BACKPACK USB drives
FIRMWARE=
FLAGS=
# pre-renumeration device IDs
case $PRODUCT in
# BACKPACK USB2 INTERNAL ADAPTER
#----------------------SCANNNERS SCANNERS-------------------------------
#external usb1 scanner
ac9/0/0)
FIRMWARE=/lib/firmware/backpackusb.d/BP1SCAN.HEX
;;
#external usb2 scanner
ac9/1/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP2SCAN.HEX
FLAGS="-2"
;;
#----------------------USB1 EXTERNAL-------------------------------
#external usb1 cd-romish series 5
ac9/1000/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP1CD5.HEX
;;
#external usb1 cd-romish series 6
ac9/1001/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP1CD6.HEX
;;
#external usb1 hard drive series 5
ac9/1002/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP1HD5.HEX
;;
#external usb1 hard drive series 6
ac9/1003/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP1HD6.HEX
;;
#----------------------USB2 EXTERNAL-------------------------------
#external usb2 cd-romish series 5
ac9/1004/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP2CD5.HEX
FLAGS="-2"
;;
#external usb2 cd-romish series 6
ac9/1005/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP2CD6.HEX
FLAGS="-2"
;;
#external usb2 hard drive series 5
ac9/1006/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP2HD5.HEX
FLAGS="-2"
;;
#external usb2 hard drive series 6
ac9/1007/*)
FIRMWARE=/lib/firmware/backpackusb.d/BP2HD6.HEX
FLAGS="-2"
;;
#----------------------USB2 INTERNAL-------------------------------
#internal usb2 cd-romish drive
ac9/10/*)
FIRMWARE=/lib/firmware/backpackusb.d/BPINTCD.HEX
FLAGS="-2"
;;
#internal usb2 cd-romish drive
ac9/11/*)
FIRMWARE=/lib/firmware/backpackusb.d/BPINTHD.HEX
FLAGS="-2"
;;
esac
# quit unless we were called to download some firmware
if [ "$FIRMWARE" = "" ]; then
# OR: restructure to do other things for
# specific post-renumeration devices
exit 0
fi
# missing firmware?
if [ ! -r $FIRMWARE ]; then
if [ -x /usr/bin/logger ]; then
/usr/bin/logger -t $0 "missing $FIRMWARE for $PRODUCT ??"
fi
exit 1
fi
if [ ! -x /sbin/fxload ]; then
if [ -x /usr/bin/logger ]; then
/usr/bin/logger -t $0 "cannot load firmware, missing fxload"
fi
exit 1
fi
if [ -x /usr/bin/logger ]; then
/usr/bin/logger -t $0 "load $FIRMWARE for $PRODUCT to $DEVICE"
fi
/sbin/fxload $FLAGS -I $FIRMWARE
# END
As you can see the script just loads the needed firmware into the drive using fxload.
I also tried renaming the backpackusb.rules to zbackpackusb.rules to make sure it executed after the udev.rule but it made no difference.
Rob
probably because the rule is done for scsi devices and not for usb devices.
ACTION=="remove", BUS=="usb", KERNEL=="sr[0-9]*", SYSFS{type}=="5", RUN+="/lib/udev/cdsymlinks.sh"
ACTION=="remove", BUS=="usb", KERNEL=="sg[0-9]*", SYSFS{type}=="5", RUN+="/lib/udev/cdsymlinks.sh"
1. Sometimes on booting up (about 10% of the time here), udev does not create any symlinks for either my built-in cdrom drive or my exteral USB CDRW drive. It is unpredictable as noted by others on the forums. Since it is unpredictable I think it is impossible to track down at this time (but you should be aware of it). I am not expecting a solution at this time unless you have ESP - Extra Sensory Power (smile).
2. udev does not remove the /dev/cdrom1 /dev/cdrw and /dev/cdrw1 symlinks when you unplug my external CDRW drive. udev does remove the /dev/scd0 and /dev/sg0 symlinks as well as the /dev/cd/cdrom-sr0 and /dev/cd/sr0 symlinks. I think you cdsymlinks.sh must be removing the latter two. But for some reason the /dev/cdrom1, /dev/cdrw and /dev/cdrw0 symlinks are not being removed.
I tried adding the two rules above with BUS=="usb". It did not make a difference.
3. The third problem is small. My simple rule in 10-local.rules to create the /dev/cdwriter symlink no longer works in the latest version of udev. (it worked in earlier versions). The rule was
KERNEL=="scd0", SYMLINK="cdwriter"
This is a strange one. I may ask the folks on the udev mailing list about this one. It should work unless they changed something in the latest version of udev.
I deleted the 10-local.rules file that contained this one rule to make sure that this was not the cause of the problems in 2 above. I am not concerned that it cannot be solved. I can live with the default /dev/cdrw symlinks if need be.
I think we should focus on tracking down the apparent bug in 2 above.
Rob
I have posted a message on the udev mailing list with respect to my simple rule that is now broken in udev 089.
Kay Sievers and I are exchanging some EMAILS. It is possible that the reason beind my broken simple rule may be the same reason behind the strange cd symlink behaviour (i.e. cd symlinks not disappearing).
udev in arch creates a /dev/scd0 node NOT an /dev/sr0 node for my CD-RW Burner. In other distros, udev creates a /dev/sr0 node for this same CD-RW Burner.
In arch, if I do a "ls /sys/block/" I see sr0 NOT scd0. See the following:
[root@myarch ~]# ls -l /sys/block/
total 0
drwxr-xr-x 3 root root 0 2006-04-13 13:57 fd0
drwxr-xr-x 9 root root 0 2006-04-13 13:58 hda
drwxr-xr-x 3 root root 0 2006-04-13 20:30 hdc
drwxr-xr-x 2 root root 0 2006-04-13 13:57 loop0
drwxr-xr-x 2 root root 0 2006-04-13 13:57 loop1
drwxr-xr-x 2 root root 0 2006-04-13 13:57 loop2
drwxr-xr-x 2 root root 0 2006-04-13 13:57 loop3
drwxr-xr-x 2 root root 0 2006-04-13 13:57 loop4
drwxr-xr-x 2 root root 0 2006-04-13 13:57 loop5
drwxr-xr-x 2 root root 0 2006-04-13 13:57 loop6
drwxr-xr-x 2 root root 0 2006-04-13 13:57 loop7
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram0
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram1
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram10
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram11
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram12
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram13
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram14
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram15
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram2
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram3
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram4
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram5
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram6
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram7
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram8
drwxr-xr-x 2 root root 0 2006-04-13 13:57 ram9
drwxr-xr-x 3 root root 0 2006-04-13 20:31 sr0
[root@myarch ~]#
Hmm.. It is strange that udev in arch creates /dev/scd0 instead.
I will let you know if my post on the udev mailing list comes up with any ideas on what may be behind the strange cd symlink behaviour on my PC.
Rob
change this:
BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5", NAME="scd%n", GROUP="optical"
to:
BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5", SYMLINK+="scd%n", GROUP="optical"
CD_RW Plugged into computer:
ls /dev/cd* /dev/sc* -l
lrwxrwxrwx 1 root root 17 2006-04-15 14:51 /dev/cdrom -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-15 14:51 /dev/cdrom0 -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-15 14:51 /dev/cdrom1 -> /dev/cd/cdrom-sr0
lrwxrwxrwx 1 root root 16 2006-04-15 14:51 /dev/cdrw -> /dev/cd/cdrw-sr0
lrwxrwxrwx 1 root root 16 2006-04-15 14:51 /dev/cdrw0 -> /dev/cd/cdrw-sr0
lrwxrwxrwx 1 root root 3 2006-04-15 14:51 /dev/scd0 -> sr0
/dev/cd:
total 0
lrwxrwxrwx 1 root root 6 2006-04-15 14:47 cdrom-hdc -> ../hdc
lrwxrwxrwx 1 root root 6 2006-04-15 14:51 cdrom-sr0 -> ../sr0
lrwxrwxrwx 1 root root 6 2006-04-15 14:51 cdrw-sr0 -> ../sr0
CDRW unplugged from computer:
[root@myarch ~]# ls /dev/cd* /dev/sc* -l
ls: /dev/sc*: No such file or directory
lrwxrwxrwx 1 root root 17 2006-04-15 14:51 /dev/cdrom -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-15 14:51 /dev/cdrom0 -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-15 14:51 /dev/cdrom1 -> /dev/cd/cdrom-sr0
lrwxrwxrwx 1 root root 16 2006-04-15 14:51 /dev/cdrw -> /dev/cd/cdrw-sr0
lrwxrwxrwx 1 root root 16 2006-04-15 14:51 /dev/cdrw0 -> /dev/cd/cdrw-sr0
/dev/cd:
total 0
lrwxrwxrwx 1 root root 6 2006-04-15 14:47 cdrom-hdc -> ../hdc
[root@myarch ~]#
Rob
Rob
KERNEL=="sr0", SYMLINK+="cdwriter"
Now, I get a /dev/cdwriter symlink! It is strange that if you originak rules I could not use KERNEL=="scd0" in my simple rule. You would think that when you changed the KERNEL name from sr0 to scd0, you could use the new kernel name!
Now if only we can find a way to get rid of the unnecessary symlinks when the CDRW drive is unplugged.
Rob
I changed the rule from:
ACTION=="remove", BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5", RUN+="/lib/udev/cdsymlinks.sh"
to
ACTION=="remove", BUS=="block", KERNEL=="sr[0-9]*", RUN+="/lib/udev/cdsymlinks.sh"
Now it works. It is strange that the rule would not be matched when SYS{type}=="5" was in the rule.
To summarize, the changes to date were as follows:
Change the rule from:
ACTION=="remove", BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5", RUN+="/lib/udev/cdsymlinks.sh"
to
ACTION=="remove", BUS=="block", KERNEL=="sr[0-9]*", RUN+="/lib/udev/cdsymlinks.sh"
Change the rule from:
BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5", NAME="scd%n", GROUP="optical"
to:
BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5", SYMLINK+="scd%n", GROUP="optical"
I do hope you incorporate these changes in the next release of udev.
I don't know whether the following REMOVE rule relating to sg0 also needs to be changed.
(i.e. should the sg0 rule be changed to ACTION=="remove", BUS=="block", KERNEL=="sg[0-9]*", RUN+="/lib/udev/cdsymlinks.sh"??)
Now hotplugging of my CDRW burner appears to work as it should.
But I still cannot get coldplugging to work. /dev/sr0, /dev/cdrw etc are NOT created at all upon reboot.
SInce I am loading firmware into the drive at each reboot using fxload, perhaps more time is needed for udev to settle down. I see udev 090 is out when udevsettle. Maybe that is the answer to the cold plugging problem.
Rob
On Sunday 16 April 2006 01:04, Robert Kennedy wrote:
> I have a simple rule that runs a script that creates extra cd related
> symlinks.
>
> The rule is as follows:
>
> ACTION=="add", BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5",
> RUN+="/lib/udev/cdsymlinks.sh"
>
> This rule works great. When a new CDRW drive is plugged in, the script is
> called and creates additional symlinks.
>
it is better to change this script to return list of symlinks and use
ACTION=="add", BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5",
PROGRAM="/lib/udev/cdsymlinks.sh", SYMLINK="%c"
In this case symlinks will be deleted by udev in "remove". It also allows
querying for them using udevinfo.
> I also have a rule to run the same script which will remove these cd
> symlinks when the CDRW driver is removed (e.g. removable CDRW drive). I
> first tried this rule:
>
> ACTION=="remove", BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5",
> RUN+="/lib/udev/cdsymlinks.sh"
>
> It did not work. I could only get the rule to be matched and run when I
> changed the rule to:
>
> ACTION=="add", BUS=="block", KERNEL=="sr[0-9]*",
> RUN+="/lib/udev/cdsymlinks.sh"
>
> I am curious why I had to change the remove rule. Does anyone have any
> ideas?
>
sysfs entry for device is not available on "remove".
- -andrey
ACTION=="remove", BUS=="block", KERNEL=="sr[0-9]*", RUN+="/lib/udev/cdsymlinks.sh"
It is also interesting to note that my simple rule KERNEL=="sr0", SYMLINK+="cdwriter" in 10-local.rule works again even though you keep the old rule that remaned the kernal block name sr0 to the device node /dev/scd0.
I would have preferred it if you changed the rule from:
BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5", NAME="scd%n", GROUP="optical"
to:
BUS=="scsi", KERNEL=="sr[0-9]*", SYSFS{type}=="5", SYMLINK+="scd%n", GROUP="optical"
This latter rule would create two nodes -- /dev/sr0 as the block device and /dev/scd0 as a symlink pointing to /dev/sr0.
In my view, if the kernel calls it sr0, I would have kept it as /dev/sr0 and created a symlink /dev/scd0 if you really need that node for any of your other rules. That is just my personal preference...
Apparently, udev090 has a new parameter -udevsettle. Perhaps, a longer udevsettle time will fix my coldplugging. Do you know how I can change udevsettle?
Rob
i can change the rule as you want
Rob
But I find this new behaviour strange since it is my understanding that the bootup scripts simply run /etc/udev_start.
I tried adjusting the udevsettle time by adding the option --timeout=20 in /etc/udev_start. Unfortunately, that did not make a difference.
I am still at a loss why running /etc/start_udev a second time after bootup solves my coldplugging problem.
Rob
http://www.archlinux.org/~tpowa/ contains .17-rc2 kernel
Instead of running /etc/start_udev after I boot up, I tried simply running /sbin/udevtrigger. /sbin/udevtrigger also creates the /dev nodes for my CDRW burner. I tried modifying /etc/start_udev and added a second /sbin/udevtrigger in the script and rebooted. Hmm. For some reason, the ndoes are NOT created. Very strange.
But I have posted a message on the udev mailing list. Perhaps someone may have an idea on what may be going on.
Rob
But I would like to report some weird begaviour with udev 091. I just upgraded to udev 091, now when I hotplug my CDRW Burner, the following links appear:
[root@myarch ~]# ls -l /dev/cd* /dev/sr* /dev/sc*
lrwxrwxrwx 1 root root 17 2006-04-26 18:49 /dev/cdrom -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 17 2006-04-26 18:49 /dev/cdrom0 -> /dev/cd/cdrom-hdc
lrwxrwxrwx 1 root root 3 2006-04-26 18:49 /dev/cdwriter -> sr0
lrwxrwxrwx 1 root root 3 2006-04-26 18:49 /dev/scd0 -> sr0
brw-rw---- 1 root optical 11, 0 2006-04-26 18:49 /dev/sr0
/dev/cd:
total 0
lrwxrwxrwx 1 root root 6 2006-04-26 14:44 cdrom-hdc -> ../hdc
[root@myarch ~]#
The following links have disappeared:
/dev/cdrom
/dev/cdrw
/dev/cdrw0
/dev/cd/cdrom-sr0
/dev/cd/cdrw-sr0
Very strange since it would appear that udev.rules have not changed.
Rob
Rob
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/*checkout*/base/udev/start_udev?rev=1.11&cvsroot=Current
thanks
greetings
tpowa
I am not that concerned that coldplugging does not work. I can live with either manually running /etc/start_udev or just unplug and plug the CDRW Drive back in (i.e. hotplugging). But I wish I knew why udev is acting this way.
Rob
But when I do hotplug the CDRW, the symlinks are being created properly.
Rob
so tpowa something is wrong on startup if guess ?
Rob
1. Hotplugging the CDRW after booting up; OR
2. Running /etc/start_udev after booting up.
Very strange. What is different between the Arch boot up scripts and /etc/start_udev?
Don't the arch bootup scripts run /etc/start_udev?
Rob
For some reason it is NOT recognizing anything on the USB bus properly. See the following:
[root@myarch ~]# tail /var/log/messages.log
Jun 24 08:49:13 myarch lo: Disabled Privacy Extensions
Jun 24 08:49:13 myarch IPv6 over IPv4 tunneling driver
Jun 24 08:49:59 myarch (rob-2710): starting (version 2.14.0), pid 2710 user 'rob'
Jun 24 08:49:59 myarch (rob-2710): Resolved address "xml:readonly:/opt/gnome/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
Jun 24 08:49:59 myarch (rob-2710): Resolved address "xml:readwrite:/home/rob/.gconf" to a writable configuration source at position 1
Jun 24 08:49:59 myarch (rob-2710): Resolved address "xml:readonly:/opt/gnome/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Jun 24 08:54:38 myarch usb 1-1: USB disconnect, address 2
Jun 24 08:54:41 myarch usb 1-1: new full speed USB device using uhci_hcd and address 3
Jun 24 08:54:41 myarch usb 1-1: configuration #1 chosen from 1 choice
Jun 24 08:54:42 myarch /lib/udev/backpackusb.sh: load /lib/firmware/backpackusb.d/BP1SCAN.HEX for ac9/0/0 to /proc/bus/usb/001/003
[root@myarch ~]# ls -la /proc/bus/usb/
total 0
dr-xr-xr-x 2 root root 0 2006-06-24 08:55 .
dr-xr-xr-x 6 root root 0 2006-06-24 08:49 ..
[root@myarch ~]# uname -a
Linux myarch 2.6.17-ARCH #1 SMP PREEMPT Tue Jun 20 12:31:51 CEST 2006 i686 Pentium II (Deschutes) GenuineIntel GNU/Linux
[root@myarch ~]# udevinfo -V
udevinfo, version 094
[root@myarch ~]#
Hotplugging did attempt to load some firmware into my external USB CD-RW drive using fxload using the /proc/bus/usb/001/003 address. But there is NOTHING in /proc/bus/usb. Very strange.
To make my USB drive work. One more piece of firmware must be downloaded into the USB CD RW drive. In the past, after the first upload of firmware into the USB CD RW drive, a new uevent would be created calling the script to load the second piece of firmware into the CD RW drive. I can show you the script if you like. But it looks like the problem is a more fundamental one realting to USB hotplugging in general.
Rob
P.S. I also tried using the mkinitcpio. Same problem. I don't think the problem is related to initrd or mkinitcpio. (By the way, I really like mkinitcpio. This is clearly the way to go).
In my case, I have NOT changed the standard udev.rules file BUT I do have a backpackusb.rules file as follows:
60-pcmcia.rules backpackusb.rules udev.rules udev.rules.veryold
[rob@myarch rules.d]$ cat backpackusb.rules
#these are the entries for bpck-usb devices
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0000", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0001", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1000", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1001", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1002", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1003", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1004", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1005", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1006", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="1007", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0010", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0011", RUN+="/lib/udev/backpackusb.sh"
[rob@myarch rules.d]$
As you can see this file just calls /lib/udev/backpackusb.sh when the right device is hotplugged. That still appears to happen. (The /lib/udev/backbackusb.sh script uses fxload to load firmware into the USB RW devices).
Do I need to change the firmware loader, fxload?
Rob
[root@myarch ~]# tail /var/log/everything.log
Jun 24 12:18:31 myarch syslog-ng[2565]: STATS: dropped 0
Jun 24 12:28:31 myarch syslog-ng[2565]: STATS: dropped 0
Jun 24 12:38:31 myarch syslog-ng[2565]: STATS: dropped 0
Jun 24 12:48:32 myarch syslog-ng[2565]: STATS: dropped 0
Jun 24 12:58:32 myarch syslog-ng[2565]: STATS: dropped 0
Jun 24 12:59:43 myarch usb 1-1: USB disconnect, address 3
Jun 24 12:59:45 myarch usb 1-1: new full speed USB device using uhci_hcd and address 4
Jun 24 12:59:45 myarch usb 1-1: device descriptor read/64, error -71
Jun 24 12:59:46 myarch usb 1-1: configuration #1 chosen from 1 choice
Jun 24 12:59:46 myarch /lib/udev/backpackusb.sh: load /lib/firmware/backpackusb.d/BP1SCAN.HEX for ac9/0/0 to /proc/bus/usb/001/004
I also tried mounting my USB memory Stick. When I first insert the stick, I get the following errors:
[root@myarch ~]# tail /var/log/everything.log
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130835
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130835
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130835
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130835
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130835
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130835
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130834
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130834
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130834
Jun 24 13:03:44 myarch Buffer I/O error on device sda1, logical block 130835
[root@myarch ~]#
But I can mount the stick and read and write to it. Strange.
Rob
For some reason the latest kernel 2.6.17 is NOT creating any entries in /proc/bus/usb. My device driver is trying to upload firmware (via fxload) to my USB CD-RW drive using /proc/bus/usb as the address. It fails since /proc/bus/usb does NOT exist ever.
I can load the firmware manually via fxload by using /dev/bus/usb/etc etc as the address. see Below:
[root@myarch 001]# tail /var/log/everything.log
Jun 24 13:32:03 myarch usb 1-1: USB disconnect, address 5
Jun 24 13:32:13 myarch usb 1-1: new full speed USB device using uhci_hcd and address 6
Jun 24 13:32:13 myarch usb 1-1: device descriptor read/64, error -71
Jun 24 13:32:13 myarch usb 1-1: configuration #1 chosen from 1 choice
Jun 24 13:32:14 myarch /lib/udev/backpackusb.sh: load /lib/firmware/backpackusb.d/BP1SCAN.HEX for ac9/0/0 to /proc/bus/usb/001/006
[root@myarch 001]# fxload -D /dev/bus/usb/001/006 -I /lib/firmware/backpackusb.d/BP1SCAN.HEX
[root@myarch 001]# tail /var/log/everything.log
Jun 24 13:34:54 myarch usb 1-1: USB disconnect, address 6
Jun 24 13:34:55 myarch usb 1-1: new full speed USB device using uhci_hcd and address 7
Jun 24 13:34:56 myarch usb 1-1: configuration #1 chosen from 1 choice
Jun 24 13:34:56 myarch /lib/udev/backpackusb.sh: load /lib/firmware/backpackusb.d/BP1CD6.HEX for ac9/1001/306 to /proc/bus/usb/001/007
Now I must manually upload the second piece of firmware into the CD-RW:
[root@myarch 001]# fxload -D /dev/bus/usb/001/007 -I /lib/firmware/backpackusb.d/BP1CD6.HEX
[root@myarch 001]# ls /dev/cd*
/dev/cdrom /dev/cdrom0 /dev/cdrom1 /dev/cdrw /dev/cdrw0 /dev/cdwriter
/dev/cd:
cdrom-hdc cdrom-sr0 cdrw-sr0
Success! But there is NEVER any entries in /proc/bus/usb ..
[root@myarch 001]# ls -la /proc/bus/usb
total 0
dr-xr-xr-x 2 root root 0 2006-06-24 13:49 .
dr-xr-xr-x 6 root root 0 2006-06-24 08:49 ..
[root@myarch 001]#
Is this a BUG in the KERNEL? Or is /proc/bus/usb deprecated?
I am also at a loss on how to change my backpackusb.sh script to use /dev/bus/usb instaed of /proc/bus/usb. The fix is not obvious.
Rob
To my knowledge, the only way I can download firmware into my external USB CD-RW device is by using the fxload program (See http://linux-hotplug.sourceforge.net/?selected=usb )
fxload was written and designed to use usbfs. It typically uses the DEVICE environment (set by thr kernel during hotplugging) for the address of the external USB device. e.g. /proc/bus/usb/001.
Since it looks like usbfs is on the way out, I have asked the folks on the usb hotplugging mailing list whethere there are any plans to update the old fxload program to use /dev/bus/usb paths instead?
In the meantime, is there a way to re-implement the usbfs in the latest arch kernel?
(I don't see any modules in /lib/modules ...)
Rob
I still have this line in my fstab:
usbfs /proc/bus/usb usbfs defaults, noauto 0 0
I edited this line and removed the "noauto" option and rebooted but it made no difference.
I can still manually mount usbfs with the folloiwng:
root# mount -t usbfs usbfs /proc/bus/usb
But I wish it still worked in my /etc/fstab file so its automatic at bootup.
Since it looks like arch is dropping support for usbfs, is there a way to pass the new addressing from a udev rule into a script? (i.e. the /dev/bus/usb/xxx/yyy addressing)
Right now my udev rules are pretty simple. Here are some of them:
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0000", RUN+="/lib/udev/backpackusb.sh"
SYSFS{idVendor}=="0ac9", SYSFS{idProduct}=="0001", RUN+="/lib/udev/backpackusb.sh"
As you see when you plug in the right CD-RW USB device into the USB bus,
these udev rules just call the "/lib/udev/backpackusb.sh" script. This
script uses a case statement on $PRODUCT to load the right firmware into the
external CD-RW device using fxload. Right now it uses DEVICE as the
address to which fxload will upload the firmware.
I can override the address with a -D option to fxload.
How can I pass the new /dev/bus/usb address from the udev rule into my
script? Does udev set a different ENVIRONMENT variable to the newer
/dev/bus/usb addressing scheme?
Rob
But for some reason usbfs is broken in current. You can manually activate usbfs with a mount command as root but the usbfs statement in /etc/fstab no longer works.
I hope that can be fixed soon.
Rob
My external USB drive will not be properly recognized by udev until firmware is uploaded into it via the fxload utility from http://linux-hotplug.sourceforge.net. This utility assumes that usbfs is up and running.
I believe that arch NEVER mount any filesystem, including usbfs, until after the udev autodetecting stage.
The solution -- modify the arch init scripts so that usbfs is mounted before the udev autodetect module stage.
(You can still mount all the egular filsystems like ext3 etc later).
I hope you get usbfs working again under arch.
Rob
usbfs /proc/bus/usb usbfs defaults, noauto 0 0
(i.e. usbfs is never mounted anymore).
The key is to scan the /etc/fstab file before the udev stage in the init scripts. If the line is present, then load usbfs. (I would still mount all the regular filesystems like ext3 later).
I will have to do some digging and get back to you. First I will need to learn about BSD style init scripts. (They look a lot easier than Sys V init scripts).
Rob
Please let me explain what I have done.
Before fxload and udev can load the firmware into a supported external USB Device (such as my Backpack USB drive), USB support must be included in the initrd image (or the newer initcpio image using the USB hook). In addition, the usbfs MUST be mounted before Udev uevents is run.
My proposed changes to the /etc/rc.sysinit script checks to see whether USB support is included in the initcpio image (if it is the /proc/bus/usb directory will be present), and whether you have enabled usbfs in /etc/fstab. If this is the case, /etc/rc.sysinit will mount usbfs to /proc/bus/usb. Udev will run and should automatically load any firmware into your external USB device via fxload (assuming you have the proper udev rule in place).
Later on the usbfs is remounted so that it shows up in /etc/mtab (like is done with /proc, /sys etc).
If you have NOT enabled USB support in the initrd or initcpio image but have enabled usbfs in /etc/fstab, usbfs will still be mounted but later on. (This used to happen in previous versions of arch's init scripts). But of course, fxload will not run at bootup. (i.e coldplugging will not work but hotplugging will still work).
So if you want coldplugging to work with the older USB devices that use fxload to load firmware into them, you must enable USB support in the initrd or initcpio image and enable usbfs support in /etc/fstab.
Below are the changes I made to /etc/rc.sysinit. The code could be simplified further if you want to eliminate the status messages showing usbfs being mounted (before the udev stage) and showing usbfs being remounted later on.
[rob@myarch ~]$ diff /etc/rc.sysinit /etc/rc.sysinit.orig
25,36c25
<
< # mount /usbfs if specified in /etc/fstab
< usbfs_remount="no"
< if [ -f /etc/fstab ] && [ -d /proc/bus/usb ] && \
< [ -n "$(grep /proc/bus/usb /etc/fstab)" ] && \
< [ -z "$(grep /proc/bus/usb /etc/fstab | grep "^.*#.*")" ]; then
< if status "Mounting usbfs" mount -n -a -t usbfs
< then
< usbfs_remount="yes"
< fi
< fi
<
---
>
169c158
< stat_busy "Remounting Root Read/Write"
---
> stat_busy "Mounting Local Filesystems"
174,192c163,164
< stat_done
<
< # re-mount /proc and if necessary usbfs so they can be written to /etc/mtab
< if [ "$usbfs_remount" = "yes" ]
< then
< umount /proc/bus/usb
< umount /proc && mount -t proc none /proc
< status "Remounting usbfs" mount -a -t usbfs
< else
< umount /proc && mount -t proc none /proc
< # try to mount usbfs if in /etc/fstab
< # (initrd may not have supported usbfs)
< if [ -n "$(grep /proc/bus/usb /etc/fstab)" ] && \
< [ -z "$(grep /proc/bus/usb /etc/fstab | grep "^.*#.*")" ]; then
< status "Mounting usbfs" mount -a -t usbfs
< fi
< fi
<
< # re-mount /sys so it can be written to /etc/mtab
---
> # re-mount /proc and /sys so they can be written to /etc/mtab
> umount /proc && mount -t proc none /proc
194,196c166
<
< # now mount all the other local filesystems
< stat_busy "Mounting Other Local Filesystems"
---
> # now mount all the local filesystems
[rob@myarch ~]$
If you want the complete modified /etc/rc.sysinit file, please let me know and I will send it via EMAIL.
Rob
Rob
Rob
Rob
I have added my proposed changes to the latest /etc/rc.sysinit file and have attached my modified /etc/rc.sysinit file to this message for your convenience.
Rob
and then probably this must only be added to base hook in mkinitcpio to get it working in initramfs.
But you may want to consider changing "umount /proc/bus/usb" to "umount /proc/bus/usb > /dev/null" to prevent displaying an error message if the first mount of the usbfs failed for some reason. (e.g. initcpio did not have usb hook)
Rob
I like your code since it is cleaner. But to be consistent with the existing code, you may want to use the -n option to the first time you use the mount command to mount the usbfs. e.g.
# mount usbfs
/sbin/modprobe usbcore >/dev/null 2>&1
[ "`grep usbfs /proc/filesystems`" ] && mount -n -t usbfs none /proc/bus/usb
As you know, your code will always try to remount the usbfs regardless of whether it is specified in /etc/fstab. I don't mind this at all but some users may not want to mount the usbfs (so that they can free up some resources). If you want to give users more control over whether usbfs is remounted (via /etc/fstab), you may want to consider using code this this:
# re-mount /proc , /sys and usbfs so they can be written to /etc/mtab
umount /proc/bus/usb
umount /proc && mount -t proc none /proc
[ "`grep sysfs /proc/filesystems`" ] && umount /sys && mount -t sysfs none /sys
[ "`grep usbfs /proc/filesystems`" ] && mount -t usbfs /proc/bus/usb 2> /dev/null
I have not had a chance to try the code above but it should work. (I will try the code above tonight).
Of course, before fxload will work with udev either of the following is necessary:
1) the base, udev and usb hooks are specified in /etc/mkinitcpio.conf (so that they are in the initcpio image); or,
2) the base and usb hooks are specified in /etc/mkinitcpio.conf and the required usb driver (e.g. uhci_hcd) is specified in "MODULES= " in /etc/mkinitcpio.conf (so that they are in the initcpio image)
To keep my initcpio image to a minimum, I have been using the following:
MODULES="piix ide_disk uhci_hcd reiserfs"
HOOKS="base autodetect ide usb filesystems"
This works great for me!
Thanks for all your help and patience. It looks like this bug has been squashed.
Rob
As I mentioned in my last post, I said I would test the code above that would only remount the usbfs if it was specified in /etc/fstab. Well the code does not work due to the weird syntax of the mount command. You must drop the -t usbfs option. In other words, the following code will work if you want to give arch users more control over whether the usbfs is remounted (by specifying it in /etc/fstab):
# re-mount /proc , /sys and usbfs so they can be written to /etc/mtab
umount /proc/bus/usb
umount /proc && mount -t proc none /proc
[ "`grep sysfs /proc/filesystems`" ] && umount /sys && mount -t sysfs none /sys
[ "`grep usbfs /proc/filesystems`" ] && mount /proc/bus/usb 2> /dev/null
But I if you want to always remount usbfs that is fine with me. I need to keep usbfs mounted so that hotplugging will work properly for my external USB drive.
I also discovered that I do NOT need to specify the usb hook (or the uhci_hcd module) in /etc/mkinitcpio.conf when creating the initcpio image. I believe this is due to your addition of the "/sbin/modprobe usbcore >/dev/null 2>&1" statement in your /etc/rc.sysinit file.
So to keep my initcpio image to a minimum, I have been using the following in my /etc/mkinitcpio.conf file:
MODULES="piix ide_disk reiserfs"
HOOKS="base autodetect ide filesystems"
I apologize for misleading anyone reading this big report thread.
Again thanks for all your help and patience.
Rob