Arch Linux

OOPS. The last line in my original bug report should read:

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.

Here is an update. udev 089 in arch just appears to be very flaky. Somtimes udev creates the /dev/cdrom and /dev/cdrw symlinks and sometimes it does not. I hate intermittent bugs! They are so hard to track down. But it looks like others are having the same problem. See http://bbs.archlinux.org/viewtopic.php?t=20433

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

cdromsymlinks.conf is not used anymore since ages

BUS=="scsi", KERNEL=="sg[0-9]*", SYSFS{type}=="5", RUN+="/lib/udev/cdsymlinks.sh"
does it help if you change this to KERNEL=="scd[0-9]*"
and also on the remove line

Thanks. I assume you want me to add this rule in my 10-local.rules file. I will give that a shot when I get home tonight but as I pointed out earlier, it does not look like my 10-local.rules file is being parsed. If it were, the /dev/cdwriter symlink would have been created (like it used to be).

i.e. udev should be looking at all the files in the /etc/udev/rules.d directory.

Rob

sorry no change this in udev.rules and please remove any of your own probably broken rules.

Thanks. I will change udev.rules. I have not added any of my own rules to udev.rules. I have only added one custom rule in a different file -- 10-local.rules to create my own persistent symlink. Creating the 10-local.rules file for your own rules is the preferred way to add your own custom rules as per the udev docs. My custom rule in 10-local.rules worked great in previous versions of udev in arch.

Rob

You don'T need to tell me how udev works ;)
please disable your probably broken rules, that the standard rules can work.

I did mean to infer that you don't know udev. I know you do. And I am sure you know it much better than me. But I was under the impression that you thought I modified the rules in udev.rules. I have not. My own one line custom rule was in 10-local.rules. I deleted the file.

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.

Here is 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"

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

ok just to summarize the links are now created correct, now you have only the problem that they are not removed right?
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"

Actually there are three new problems that I have encountered with the latest version of udev:

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

please try new udev 089-3

I just upgraded to udev 089-3 and reboted. I am experiencing the same problems.

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

ahh perhaps this will help then:
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"

Thanks. I changed the rule as you nopted above. Now the kernel name is not changed to scd0 but a symlink is created instead. But I am still seeing the same behaviour.

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

P.S. I am not sure whether this is helpful. But I also have noticed that cold-plugging of the CDRW burner no longer works. I must unplug and plug the CDRW back into the computer after each reboot. Not a big deal just a little annoying.

Rob

Good News. My simple rule now works. Since your new rule no longer changes the kernel name, I had to change mu simple rule in 10-local.rules as follows:

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 finally had time to do some serious debugging. I solved the problem with the cd symlinks not disapperaing when the CDRW burner was unplugged.

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

Below is some info that I obtained via the udev mailing list. I thought you might find it interesting. The exchange contains some info to improve on the udev rules in arch.

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

You probably already figured this out. But the remove rule in the EMAIL exchange on the udev mailing list should have been written:

ACTION=="remove", BUS=="block", KERNEL=="sr[0-9]*", RUN+="/lib/udev/cdsymlinks.sh"

does udev-090-1 in testing work on your system?

Yes, hotplugging under udev-090-1 does work. But coldplugging of the external CDRW Burner does not work. Not a big deal for me since I can just unplug and plug back in the external CDRW drive after each reboot. I wish I knew why coldplugging does not work. I am a baffled.

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

udevsettle is a small program that is used in start_udev now, it replaces the waiting loops there.
i can change the rule as you want

Thanks. I will take a look at start_udev when I get home tonight. Perhaps a tweak will solve the coldplugging problem.

Rob

I just upgraded to the latest kernel 2.6.16.9-1. Coldplugging of the external CDRW drive still does not work. But if I run /etc/start_udev manually after I boot up, the CDRW drive is properly detected and the /dev/ nodes are created. This is new and welcome development! (With the older kernel, I had to physically disconnect the drive and reconnect it to create a hot plugging event).

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

that is really interesting, somehow your drive is ignored first, it's a usb drive perhaps it's just a timing issue.

hmm if you are really brave, you could try if it's a kernel issue,
http://www.archlinux.org/~tpowa/ contains .17-rc2 kernel

I am not that brave yet (smile).

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

I could not find any answers to my coldplugging problem on the udev mailing list. I still suspect that it is a udev problem. In the meantime, I will just live with it. I could always put another /sbin/udevtrigger later on in the arch bootup script.

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

try changing line 94 and 95 in udev.rules to kernel== instead of kernel=

The missing symlinks came back once I upgraded to udev 091-2.

Rob

could you try if this start_udev brings back your coldplugging?
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/*checkout*/base/udev/start_udev?rev=1.11&cvsroot=Current
thanks
greetings
tpowa

I tried the /etc/start_udev from the link above. It did not make any difference but it did take a lot longer to run. Coldplugging does not work but if I manually run /etc/start_udev after I bootup, the /dev/ nodes for the CDRW Burner are created. With the previous udev versions (and the previous /etc/start_udev), the same thing happened. To get the /dev nodes created for the external CDRW drive, I had to either hotplug the CDRW Drive or I had to manually run /etc/start_udev or simply run /sbin/udevtrigger after I boot up. Very strange.

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

could you try if new udev and mkinitcpio solve your issue?

Sure, I will give it a try. I am on vacation now. I won't be near my Arch computer until near the end of the month. So please be patient.

status ?

I just update the Frugalware-cuuent. Teh latest kernal and udev have not fixed the problem. Cold plugging of the CDRW is still broken but hotplugging works. Very Strange. I am at a loss why this is happening.

But when I do hotplug the CDRW, the symlinks are being created properly.

Rob

ehm, this is archlinux not frugalware :/ why didn't you reported this to frugalware ?
so tpowa something is wrong on startup if guess ?

Sorry for the confusion. I run both Arch and Frugalware. The problem I am having is with my computer running Arch Linux. I am running Arch current with latest kernal and udev and cold plugging of the CDRW is not working but hotplugging does work.

Rob

Hmm.. I can get Arch to create the /dev nodes and the symlink for my external CDRW if I do one of the following:

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

have you also tried udev093 there the firmware loading has changed and afaik you need a firmware for your cd.

I just did a pacman -Syu today. It would appear that the 2.6.17 kernel and/or udev 094 has also broken USB hotplugging on my computer. Coldplugging is also still not working.

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

the firmware loader has changed in udev 094, so please keep that in ind if you changed standard udev.rules file

Thanks for the info. What has changed? In the past, during hotplugging, udev would call a script that used the fxload firmware loader.

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

Here is a better log of the problem. It looks like I am getting a USB Device Descriptor error now.

[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

I have found the bug but don't know the solution.

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

Hmm. It looks like the latest arch kernel 2.6.17 has dropped usbfs.

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

Hmm. It looks like arch-current is no longer mounting usbfs. (Perhaps, usbfs is part of devfs?)

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

I finally got some more background on usbfs. usbfs is NOT part of devfs. So I assume that usbfs will still be supoorte in arch Linux.

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

Sorry for all the posts. But now I know why coldplugging for my external USB CD-RW never worked under arch.

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

please tell me what to add and i'll try it next week when i have time to integrate it in init process.

I will do some debugging. It looks like the init scripts must have changed just recently since the following line in my /etc/fstab no longer works:

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

I have finished making the necessart changes to the /etc/rc.sysinit script. I have been beta testing the software for the past couple of days and so far it works flawlessly.

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

It looks like I can attach files to this bug tracker. Here is my complete revised /etc/rc.sysinit.

Rob

Here is another version of /etc/rc.sysinit. This code is cleaner, easier to follow and easier to maintain. I don't know why I didn't think of this approach earlier.

Rob

One small change to /etc/sysinit. I added the -n option to the first mount command that mounts usbfs in the very early initrd / initcpio stage of the boot process. The -n option prevents info from being added to /etc/mtab. You really don't need the -n option but all the other early mount commands use it. So I addded it to be consistent. (It was in my first version of /etc/sysinit but I forget it when I cleaned up the code).

Rob

It just updated my computer with a pacman -Syu. Arch's initscripts were just updated today.

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

could you please try this rc.sysinit?
and then probably this must only be added to base hook in mkinitcpio to get it working in initramfs.

Your rc.sysinit works great!

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

does this now solve hot and colplugging?

Yes, any of the rc.sysinit files posted here solve BOTH cold plugging and hot plugging problems with older USB devices that need fxload to load firmware into the USB device.

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

I see the initscripts were updated in arch. The new initscripts work great. Coldplugging and Hotplugging of my old USB external drive (that needs fxload to load firmwware) works perfectly.

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