SEO

I am having trouble running cdrecord on CentOS 4.2.

The first problem is that it wants to use the /dev/sg* devices to control
the CD-ROM burner that is a PleXWriter 12/10/30S that is connected to the
system through a SCSI controller in my system. Now this has worked perfectly
well with Red Hat Linux 7.3 and Red Hat Linux 9. I have made no hardware
changes.

But with CentOS 4.2, there are no /dev/sg* entries in /dev.
So I created them with MAKEDEV, and then it would work (but not the same as
before). But if I reboot, those /dev entries disappear.

So what do I do to keep them there? There must be some setup file somewhere
that either regenerates the entire /dev directory, or thinks it is smart
enough to delete useless entries. What might it be?

Second, if I run cdrecord -scanbus, it shows only the ATA bus ide3 (I think
it is) where my regular CD-ROM player is located, and that one would be
useless for burning CD-ROMs. I can make it show the desired bus by doing

cdrecord dev=/dev/sgd -scanbus

but it then scans only that bus. On my Red Hat Enterprise Linux 3 system,

cdrecord -scanbus

shows both scsi controllers, and all the /dev/sg* devices are present.

So something is different. I assume this is a setup problem of some kind,
but what?

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 07:20:00 up 5 days, 17:50, 3 users, load average: 4.37, 4.25, 4.20

> But with CentOS 4.2, there are no /dev/sg* entries in /dev.
> So I created them with MAKEDEV, and then it would work (but not the same as
> before). But if I reboot, those /dev entries disappear.

Centos (and Fedora and RHEL) use udev to manage device nodes in /dev.
Don't use MAKEDEV; instead, take a look at the files in /etc/udev.d.
But before you do *that*, just try loading the 'sg' module, and you'll
probably find that you now have the necessary /dev/sg* device nodes
without any further intervention on your part.

It doesn't make sense to create the devices with MAKEDEV if the
appropriate kernel module isn't loaded.

-- Lars

--
Lars Kellogg-Stedman <8273grkci8q8kgt@jetable.net>
This email address will expire on 2005-11-23.

On Fri, 02 Dec 2005 at 12:44 GMT, Jean-David Beyer eloquently wrote:
> I am having trouble running cdrecord on CentOS 4.2.
>
> The first problem is that it wants to use the /dev/sg* devices to control
> the CD-ROM burner that is a PleXWriter 12/10/30S that is connected to the
> system through a SCSI controller in my system. Now this has worked perfectly
> well with Red Hat Linux 7.3 and Red Hat Linux 9. I have made no hardware
> changes.
>
> But with CentOS 4.2, there are no /dev/sg* entries in /dev.
> So I created them with MAKEDEV, and then it would work (but not the same as
> before). But if I reboot, those /dev entries disappear.
>
> So what do I do to keep them there? There must be some setup file somewhere
> that either regenerates the entire /dev directory, or thinks it is smart
> enough to delete useless entries. What might it be?
Seems it uses udev to set that up. Look into this. I seem
to remember a while that ppl with nVidia graf cards had to
go thru some hoops to get their cards to function properly.
You'll need to follow what they did I believe.

N.Emile...
--
Registered Linux User # 125653 (http://counter.li.org) | Please remove
Certified: 75% bastard, 42% of which is tard. | '.invalid'
http://www.thespark.com/bastardtest | to reply.
Switch to: http://www.speakeasy.net/refer/190653

Lars Kellogg-Stedman wrote:
>>But with CentOS 4.2, there are no /dev/sg* entries in /dev.
>>So I created them with MAKEDEV, and then it would work (but not the same as
>>before). But if I reboot, those /dev entries disappear.
>
>
> Centos (and Fedora and RHEL) use udev to manage device nodes in /dev.

Not in RHEL 3, but it seems to be true in RHEL 4.

> Don't use MAKEDEV; instead, take a look at the files in /etc/udev.d.

In CentOS 4.2 there is no such directory. There is a /etc/udev with this in it:

[/etc/udev]$ ls -lR
..:
total 40
drwxr-xr-x 2 root root 4096 Aug 21 20:41 devices
drwxr-xr-x 2 root root 4096 Oct 26 08:59 permissions.d
drwxr-xr-x 2 root root 4096 Oct 26 08:59 rules.d
drwxr-xr-x 2 root root 4096 Oct 26 08:59 scripts
-rw-r--r-- 1 root root 1128 Aug 21 20:41 udev.conf



../devices:
total 0



../permissions.d:
total 8
-rw-r--r-- 1 root root 3508 Aug 21 20:41 50-udev.permissions



../rules.d:
total 8
-rw-r--r-- 1 root root 3230 Aug 21 20:41 50-udev.rules



../scripts:
total 40
-rwxr-xr-x 1 root root 733 Aug 21 20:41 MAKEDEV.dev
-rwxr-xr-x 1 root root 662 Aug 21 20:41 check-cdrom.sh
-rwxr-xr-x 1 root root 599 Aug 21 20:41 hotplug.dev
-rwxr-xr-x 1 root root 216 Aug 21 20:41 ide-media.sh
-rwxr-xr-x 1 root root 978 Aug 21 20:41 pam_console.dev

> But before you do *that*, just try loading the 'sg' module, and you'll
> probably find that you now have the necessary /dev/sg* device nodes
> without any further intervention on your part.

Where is the right place to insert the _modprobe sg_? I.e., in what file? It
seems to me that there is a standard file to put that in, but I disremember
where it is.
>
> It doesn't make sense to create the devices with MAKEDEV if the
> appropriate kernel module isn't loaded.

Somehow, it does got loaded after I created the /dev/sg* entries with
MAKEDEV. It may be that, since I have two scsi controllers, something else
loads them. I will have to reboot that system to find out what else might
have loaded them. Doing that now...

OK, now there are no /dev/sg* and the sg module is not loaded.
I then loaded it by manually doing

/sbin/modprobe sg

This created /dev/sg[0-4], but no /dev/sg[a-e], but I think I will be able
to handle that.

OK all seems to work other than finding where to put the modprobe command.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 08:55:00 up 5 days, 19:25, 3 users, load average: 4.05, 4.10, 4.14

On Fri, 02 Dec 2005 13:44:15 +0100, Jean-David Beyer <jdbeyer@exit109.com> wrote:

> I am having trouble running cdrecord on CentOS 4.2.
>
> The first problem is that it wants to use the /dev/sg* devices to control
> the CD-ROM burner that is a PleXWriter 12/10/30S that is connected to the
> system through a SCSI controller in my system. Now this has worked perfectly
> well with Red Hat Linux 7.3 and Red Hat Linux 9. I have made no hardware
> changes.
>
> But with CentOS 4.2, there are no /dev/sg* entries in /dev.
> So I created them with MAKEDEV, and then it would work (but not the same as
> before). But if I reboot, those /dev entries disappear.
>
> So what do I do to keep them there? There must be some setup file somewhere
> that either regenerates the entire /dev directory, or thinks it is smart
> enough to delete useless entries. What might it be?
>
> Second, if I run cdrecord -scanbus, it shows only the ATA bus ide3 (I think
> it is) where my regular CD-ROM player is located, and that one would be
> useless for burning CD-ROMs. I can make it show the desired bus by doing
>
> cdrecord dev=/dev/sgd -scanbus
>
> but it then scans only that bus. On my Red Hat Enterprise Linux 3 system,
>
> cdrecord -scanbus
>
> shows both scsi controllers, and all the /dev/sg* devices are present.
>
> So something is different. I assume this is a setup problem of some kind,
> but what?


The major difference is the kernel. With 2.6, ide/ata works fine to burn cds.

/dev is now a ramfs. When you reboot, it's gone, that is right. It gets
rebuilt, partly from the initrd, and partly from the /etc/rc.d/rc.sysinit.
Then there are hotplug scripts that get run when the system discovers
new hardware. Look at man hotplug, to get started.

But I would not start trying to bring back the old behaviour. That would
be some kind of last-ditch effort. I would try to figure out how things
are supposed to be with the new distribution.

Let cdrecord have a chance to show what it can do with the ata interface.

-Enrique

Enrique Perez-Terron wrote:
> On Fri, 02 Dec 2005 13:44:15 +0100, Jean-David Beyer
> <jdbeyer@exit109.com> wrote:
>
>> I am having trouble running cdrecord on CentOS 4.2.
>>
>> The first problem is that it wants to use the /dev/sg* devices to
>> control the CD-ROM burner that is a PleXWriter 12/10/30S that is
>> connected to the system through a SCSI controller in my system. Now
>> this has worked perfectly well with Red Hat Linux 7.3 and Red Hat Linux
>> 9. I have made no hardware changes.
>>
>> But with CentOS 4.2, there are no /dev/sg* entries in /dev. So I
>> created them with MAKEDEV, and then it would work (but not the same as
>> before). But if I reboot, those /dev entries disappear.
>>
>> So what do I do to keep them there? There must be some setup file
>> somewhere that either regenerates the entire /dev directory, or thinks
>> it is smart enough to delete useless entries. What might it be?
>>
>> Second, if I run cdrecord -scanbus, it shows only the ATA bus ide3 (I
>> think it is) where my regular CD-ROM player is located, and that one
>> would be useless for burning CD-ROMs. I can make it show the desired
>> bus by doing
>>
>> cdrecord dev=/dev/sgd -scanbus
>>
>> but it then scans only that bus. On my Red Hat Enterprise Linux 3
>> system,
>>
>> cdrecord -scanbus
>>
>> shows both scsi controllers, and all the /dev/sg* devices are present.
>>
>> So something is different. I assume this is a setup problem of some
>> kind, but what?
>
>
> The major difference is the kernel. With 2.6, ide/ata works fine to burn
> cds.
>
> /dev is now a ramfs. When you reboot, it's gone, that is right. It gets
> rebuilt, partly from the initrd, and partly from the
> /etc/rc.d/rc.sysinit. Then there are hotplug scripts that get run when
> the system discovers new hardware. Look at man hotplug, to get started.

Lars Kellogg-Stedman, earlier in this thread, suggested just loading the sg
driver (presumably at boot time), and this cured the important part of the
problem (other than I do not know what the approved file to put the
/sbin/modprobe command in. Anywhere, such as /etc/rc.d/rc.local, would do,
but there is probably an approved way to do this, and I no longer remember
it). It generated only the /dev/sg[0-4] devices, not the /dev/sg[a-e] ones,
but I can deal with that.
>
> But I would not start trying to bring back the old behaviour. That would
> be some kind of last-ditch effort. I would try to figure out how things
> are supposed to be with the new distribution.

One big annoyance is that my old /etc/cdrecord.conf contained the operative
line that looks like this:

plextor= 1,4,0 -1 -1 burnfree

This does not work anymore. I had to change it to look like this:

plextor= /dev/sg3 -1 -1 burnfree

and that is not in the spirit of things.
>
> Let cdrecord have a chance to show what it can do with the ata interface.
>
How is it going to do that when the cd-rom burner _really is a scsi device_,
a PleXWriter 12/10/30S on a Symbios SYM20810 PCI to Fast SCSI Host Adapter?
As a practical matter, what it shows it can do is try to drive my ATA cd-rom
read-only drive on ide3, and that will not do at all.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 11:45:00 up 5 days, 22:15, 4 users, load average: 4.34, 4.29, 4.27

On Fri, 02 Dec 2005 18:10:53 +0100, Jean-David Beyer <jdbeyer@exit109.com> wrote:

> Enrique Perez-Terron wrote:
>> On Fri, 02 Dec 2005 13:44:15 +0100, Jean-David Beyer
>> <jdbeyer@exit109.com> wrote:
>>
>>> I am having trouble running cdrecord on CentOS 4.2.
>>>
>>> The first problem is that it wants to use the /dev/sg* devices to
>>> control the CD-ROM burner that is a PleXWriter 12/10/30S that is
[..]
>> Let cdrecord have a chance to show what it can do with the ata interface.
>>
> How is it going to do that when the cd-rom burner _really is a scsi device_,
> a PleXWriter 12/10/30S on a Symbios SYM20810 PCI to Fast SCSI Host Adapter?
> As a practical matter, what it shows it can do is try to drive my ATA cd-rom
> read-only drive on ide3, and that will not do at all.

Ouch, my bad. I confused two things you said and came two think that the ide3
drive was the device you were talking about.

It seems like the suggeston to load the sg module was much closer.
However, the canonical way to configure that...

I tried to make sense of the udev documentation a few weeks ago, but I
ran out of steam. Trying again, and a bit confused about what I really
remember, or just though ought to be...

Check the file /proc/sys/kernel/hotplug. On my system it contains
"/sbin/udevsend". When there are hotplug events (like device discoveries)
the kernel runs this program with some info about the event in environment
variables.

For devices that are discovered early during the kernel initialization,
at a time when userland may not yet be available... I don't remember clearly,
can anyone tell, is there something in /etc/rc.d/rc.sysinit for this?

Hm, looking through rc.sysinit, it does not seem so. It looks like there
is an undocumented program "kmodule" in the initscripts package (is this
redhat/fedora specific?) that finds the names somehow of scsi adapters,
ide devices... and calls modprobe a couple of times. It seems like these
modprobe calls leads to the hotplug events that triggers the rest:

/sbin/udevsend starts /sbin/udevd, a daemon, unless it already runs.
Then it sends it a message. /sbin/udevd somehow reorders events that
arrive close in time, and starts the program /sbin/udev with each.

/sbin/udev reads the files in /etc/udev/rules.d These contain "rules"
consisting of attribute name-value pairs called "keys" in the manpage.
The manpage fails to tell which pairs are inputs and which are outputs.
However, when a rule is found whose input keys match the actual attributes
of the event (as delivered in the environment? the manpage does not say),
the output keys control actions by the udev. The actions are basicly RUN=...
to run a program, NAME=... to create a device file in /dev with OWNER=,
GROUP=, MODE= output attributes; create SYMLINK=s in /dev...

To learn about what input attributes can be used to write your own rules for
the scsi cd burner, peruse the directories in /sys (provided your system
mounts a sysfs filesystem there). For example, I have a Lexmark printer and
scanner, and tried this:

$ cd /sys/devices
$ (find . type f | xargs grep -i lexmark) 2>/dev/null
./pci0000:00/0000:00:14.2/usb1/1-1/1-1.2/product:Lexmark All-in-One
./pci0000:00/0000:00:14.2/usb1/1-1/1-1.2/manufacturer:Lexmark
./pci0000:00/0000:00:14.2/usb1/1-1/1-1.1/manufacturer:Lexmark

$ udevinfo -p /sys/devices/pci0000:00/0000:00:14.2/usb1/1-1/1-1.2 -a

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 class device '/sys/devices/pci0000:00/0000:00:14.2/usb1/1-1/1-1.2':
SUBSYSTEM=="unknown"
SYSFS{bConfigurationValue}=="1"
SYSFS{bDeviceClass}=="00"
SYSFS{bDeviceProtocol}=="00"
SYSFS{bDeviceSubClass}=="00"
SYSFS{bMaxPacketSize0}=="8"
SYSFS{bMaxPower}==" 4mA"
SYSFS{bNumConfigurations}=="1"
SYSFS{bNumInterfaces}==" 1"
SYSFS{bcdDevice}=="0100"
SYSFS{bmAttributes}=="c0"
SYSFS{configuration}==""
SYSFS{devnum}=="4"
SYSFS{idProduct}=="0069"
SYSFS{idVendor}=="043d"
SYSFS{manufacturer}=="Lexmark"
SYSFS{maxchild}=="0"
SYSFS{product}=="Lexmark All-in-One"
SYSFS{speed}=="12"
SYSFS{version}==" 1.10"

Man 8 udev should tell the rest.

This is purely a guess on my part: install a call to modprobe anywhere you like,
e.g., in /etc/rc.d/rc.local, but use the udev machinery to set up the /dev nodes.
If on Fedora/Redhat, there is a file /etc/sysconfig/modules where you could name
the module, instead of using rc.local.

I am not sure I would bother to do it the "politially correct" way.

-Enrique

"Jean-David Beyer" <jdbeyer@exit109.com> wrote in message
news:11p0gd31fm8cq8f@corp.supernews.com...
>I am having trouble running cdrecord on CentOS 4.2.
>
> The first problem is that it wants to use the /dev/sg* devices to control
> the CD-ROM burner that is a PleXWriter 12/10/30S that is connected to the
> system through a SCSI controller in my system. Now this has worked
> perfectly
> well with Red Hat Linux 7.3 and Red Hat Linux 9. I have made no hardware
> changes.

I used one last with with FC4. If CentOS 4.x is not too different, you can
simply ignore the moaning in the cdrecord documentation about having to use
ide-scsi and /dev/s* devices, and test by using a good friendly tool like
"k3b" to detect and test your CD burner. The author of the cdrecord devices
used the ide-scsi module to get the IDE based burners to look like SCSI
devices because of the better functionality of those drives and those
drivers. Despite his religious objections, this hasn't been necessary for
some time (at least since the first 2.6 kernel I used, possibly longer) and
you can simply tell cdrecord and the DVD burning devices to use the /dev/hd*
device. I've written to him: he refused to alter that part of the cdrecord
documents.

> But with CentOS 4.2, there are no /dev/sg* entries in /dev.
> So I created them with MAKEDEV, and then it would work (but not the same
> as
> before). But if I reboot, those /dev entries disappear.

As people said, /dev/ entries are now created with the udev tools at boot
time. But you don't need these, I think. Test with k3b.

Enrique Perez-Terron wrote:
> On Fri, 02 Dec 2005 18:10:53 +0100, Jean-David Beyer
> <jdbeyer@exit109.com> wrote:
>
>> Enrique Perez-Terron wrote:
>>
>>> On Fri, 02 Dec 2005 13:44:15 +0100, Jean-David Beyer
>>> <jdbeyer@exit109.com> wrote:
>>>
>>>> I am having trouble running cdrecord on CentOS 4.2.
>>>>
>>>> The first problem is that it wants to use the /dev/sg* devices to
>>>> control the CD-ROM burner that is a PleXWriter 12/10/30S that is
>
> [..]
>
>>> Let cdrecord have a chance to show what it can do with the ata
>>> interface.
>>>
>> How is it going to do that when the cd-rom burner _really is a scsi
>> device_, a PleXWriter 12/10/30S on a Symbios SYM20810 PCI to Fast SCSI
>> Host Adapter? As a practical matter, what it shows it can do is try to
>> drive my ATA cd-rom read-only drive on ide3, and that will not do at
>> all.
>
>
> Ouch, my bad. I confused two things you said and came two think that the
> ide3 drive was the device you were talking about.
>
> It seems like the suggeston to load the sg module was much closer.
> However, the canonical way to configure that...
>
> I tried to make sense of the udev documentation a few weeks ago, but I
> ran out of steam. Trying again, and a bit confused about what I really
> remember, or just though ought to be...
>
> Check the file /proc/sys/kernel/hotplug. On my system it contains
> "/sbin/udevsend".

On my system (CentOS 4.2), it is:

/sbin/hotplug

There is a man page for hotplug.
It refers me to /etc/hotplug and in there is a file scsi.agent that contains:

#!/bin/sh
#
# SCSI hotplug agent for 2.5 kernels
#
# ACTION=add
# DEVPATH=devices/scsi0/0:0:0:0
#

cd /etc/hotplug
.. ./hotplug.functions

case $ACTION in

add)
# 2.5.50 kernel bug: this happens sometimes
if [ ! -d /sys/$DEVPATH ]; then
mesg "bogus sysfs DEVPATH=$DEVPATH"
exit 1
fi

TYPE_ATTR=/sys$DEVPATH/type

# Possibly sleep here to try and avoid races with scsi attributes and block
# devices
count=10
while [ ! -f $TYPE_ATTR -a $count -gt 0 ]
do
# We seem to always hit this now, so don't output any message.
debug_mesg "waiting for $TYPE_ATTR"
sleep 1
count=$(($count-1))
done

if [ ! -f $TYPE_ATTR ]
then
mesg "Attribute $TYPE_ATTR does not exist"
exit 1
fi

TYPE=$(cat $TYPE_ATTR)
case "$TYPE" in
# 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
0) TYPE=disk ; MODULE=sd_mod ;;
# FIXME some tapes use 'osst' not 'st'
1) TYPE=tape ; MODULE=st ;;
2) TYPE=printer ; MODULE=sg ;;
3) TYPE=processor ; MODULE=sg ;;
4) TYPE=worm ; MODULE=sr_mod ;;
5) TYPE=cdrom ; MODULE=sr_mod ;;
6) TYPE=scanner ; MODULE=sg ;;
7) TYPE=mod ; MODULE=sd_mod ;;
8) TYPE=changer ; MODULE=sg ;;
9) TYPE=comm ; MODULE=sg ;;
14) TYPE=enclosure ; MODULE=sg ;;
esac
if [ "$MODULE" != "" ]; then
mesg "$TYPE at $DEVPATH"
modprobe $MODULE
else
debug_mesg "how to add device type=$TYPE at $DEVPATH ??"
fi
;;

*)
debug_mesg SCSI $ACTION event not supported
exit 1
;;

esac

Now if I knew what number code I would get, or what $TYPE_ATTR I would get
for my cd-rom burner, I could just put a line in there that said, e.g.,

10) TYPE=cdromburner ; MODULE=sg ;;

in there.

> When there are hotplug events (like device
> discoveries) the kernel runs this program with some info about the event
> in environment variables.
>
> For devices that are discovered early during the kernel initialization,
> at a time when userland may not yet be available... I don't remember
> clearly, can anyone tell, is there something in /etc/rc.d/rc.sysinit for
> this?
>
> Hm, looking through rc.sysinit, it does not seem so. It looks like there
> is an undocumented program "kmodule" in the initscripts package (is this
> redhat/fedora specific?) that finds the names somehow of scsi adapters,
> ide devices... and calls modprobe a couple of times. It seems like these
> modprobe calls leads to the hotplug events that triggers the rest:
>
> /sbin/udevsend starts /sbin/udevd, a daemon, unless it already runs. Then
> it sends it a message. /sbin/udevd somehow reorders events that arrive
> close in time, and starts the program /sbin/udev with each.

At the present moment, udevd is running (according to pstree).
>
> /sbin/udev reads the files in /etc/udev/rules.d These contain "rules"
> consisting of attribute name-value pairs called "keys" in the manpage.
> The manpage fails to tell which pairs are inputs and which are outputs.
> However, when a rule is found whose input keys match the actual
> attributes of the event (as delivered in the environment? the manpage
> does not say), the output keys control actions by the udev. The actions
> are basicly RUN=... to run a program, NAME=... to create a device file in
> /dev with OWNER=, GROUP=, MODE= output attributes; create SYMLINK=s in
> /dev...
>
> To learn about what input attributes can be used to write your own rules
> for the scsi cd burner, peruse the directories in /sys (provided your
> system mounts a sysfs filesystem there). For example, I have a Lexmark
> printer and scanner, and tried this:
>
> $ cd /sys/devices
> $ (find . type f | xargs grep -i lexmark) 2>/dev/null
> ./pci0000:00/0000:00:14.2/usb1/1-1/1-1.2/product:Lexmark All-in-One
> ./pci0000:00/0000:00:14.2/usb1/1-1/1-1.2/manufacturer:Lexmark
> ./pci0000:00/0000:00:14.2/usb1/1-1/1-1.1/manufacturer:Lexmark
>
> $ udevinfo -p /sys/devices/pci0000:00/0000:00:14.2/usb1/1-1/1-1.2 -a
>
> 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 class device
> '/sys/devices/pci0000:00/0000:00:14.2/usb1/1-1/1-1.2':
> SUBSYSTEM=="unknown" SYSFS{bConfigurationValue}=="1"
> SYSFS{bDeviceClass}=="00" SYSFS{bDeviceProtocol}=="00"
> SYSFS{bDeviceSubClass}=="00" SYSFS{bMaxPacketSize0}=="8"
> SYSFS{bMaxPower}==" 4mA" SYSFS{bNumConfigurations}=="1"
> SYSFS{bNumInterfaces}==" 1" SYSFS{bcdDevice}=="0100"
> SYSFS{bmAttributes}=="c0" SYSFS{configuration}=="" SYSFS{devnum}=="4"
> SYSFS{idProduct}=="0069" SYSFS{idVendor}=="043d"
> SYSFS{manufacturer}=="Lexmark" SYSFS{maxchild}=="0"
> SYSFS{product}=="Lexmark All-in-One" SYSFS{speed}=="12" SYSFS{version}=="
> 1.10"
>
> Man 8 udev should tell the rest.
>
> This is purely a guess on my part: install a call to modprobe anywhere
> you like, e.g., in /etc/rc.d/rc.local, but use the udev machinery to set
> up the /dev nodes.

I do not have to set up the /dev nodes. As soon as I load the sg module,
with

/sbin/modprobe sg

the /dev nodes are created.

> If on Fedora/Redhat, there is a file
> /etc/sysconfig/modules where you could name the module, instead of using
> rc.local.

There is no /etc/sysconfig/modules file in CentOS 4.2.
I do not want to use rc.local.
I have stuck
>
> I am not sure I would bother to do it the "politially correct" way.
>


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 20:50:00 up 6 days, 7:20, 4 users, load average: 4.42, 4.35, 4.25

On Sat, 03 Dec 2005 03:30:56 +0100, Jean-David Beyer <jdbeyer@exit109.com> wrote:

> Enrique Perez-Terron wrote:
[...]
>> Check the file /proc/sys/kernel/hotplug. On my system it contains
>> "/sbin/udevsend".
>
> On my system (CentOS 4.2), it is:
>
> /sbin/hotplug
>
> There is a man page for hotplug.
> It refers me to /etc/hotplug and in there is a file scsi.agent that contains:
>
> #!/bin/sh
> #
> # SCSI hotplug agent for 2.5 kernels
> #
> # ACTION=add
> # DEVPATH=devices/scsi0/0:0:0:0
> #
>
> cd /etc/hotplug
> . ./hotplug.functions
>
> case $ACTION in
>
> add)
> # 2.5.50 kernel bug: this happens sometimes
> if [ ! -d /sys/$DEVPATH ]; then
> mesg "bogus sysfs DEVPATH=$DEVPATH"
> exit 1
> fi
>
> TYPE_ATTR=/sys$DEVPATH/type
>
> # Possibly sleep here to try and avoid races with scsi attributes and block
> # devices
> count=10
> while [ ! -f $TYPE_ATTR -a $count -gt 0 ]
> do
> # We seem to always hit this now, so don't output any message.
> debug_mesg "waiting for $TYPE_ATTR"
> sleep 1
> count=$(($count-1))
> done
>
> if [ ! -f $TYPE_ATTR ]
> then
> mesg "Attribute $TYPE_ATTR does not exist"
> exit 1
> fi
>
> TYPE=$(cat $TYPE_ATTR)
> case "$TYPE" in
> # 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
> 0) TYPE=disk ; MODULE=sd_mod ;;
> # FIXME some tapes use 'osst' not 'st'
> 1) TYPE=tape ; MODULE=st ;;
> 2) TYPE=printer ; MODULE=sg ;;
> 3) TYPE=processor ; MODULE=sg ;;
> 4) TYPE=worm ; MODULE=sr_mod ;;
> 5) TYPE=cdrom ; MODULE=sr_mod ;;
> 6) TYPE=scanner ; MODULE=sg ;;
> 7) TYPE=mod ; MODULE=sd_mod ;;
> 8) TYPE=changer ; MODULE=sg ;;
> 9) TYPE=comm ; MODULE=sg ;;
> 14) TYPE=enclosure ; MODULE=sg ;;
> esac
> if [ "$MODULE" != "" ]; then
> mesg "$TYPE at $DEVPATH"
> modprobe $MODULE
> else
> debug_mesg "how to add device type=$TYPE at $DEVPATH ??"
> fi
> ;;
>
> *)
> debug_mesg SCSI $ACTION event not supported
> exit 1
> ;;
>
> esac
>
> Now if I knew what number code I would get, or what $TYPE_ATTR I would get
> for my cd-rom burner, I could just put a line in there that said, e.g.,
>
> 10) TYPE=cdromburner ; MODULE=sg ;;
>
> in there.

But isn't the file /sys/devices/whatever.../type present on your system?

I think it should be possible to do lspci, and use the output to exclude
most of the irrelevant parts of the /sys/devices file tree. There should
be just one or a handfull directories left to investigate manually.

The first question is if this script is already being called with your
device, but the script does not do the right thing at that point, or
is the hotplug system just not seing the cd burner, PleXWriter, or is it
seeing it before /sbin/hotplug is installed and the udev systems starrted.

In the first case, you could perhaps instrument the script with some
logging, have it show for each invocation what environment variables
it is being called with, and what actions it is taking.

In the latter case, one needs to investigate the existing infrastructure
for simulating hotplug events for devices that are discovered early.

[...]
>> /sbin/udevsend starts /sbin/udevd, a daemon, unless it already runs. Then
>> it sends it a message. /sbin/udevd somehow reorders events that arrive
>> close in time, and starts the program /sbin/udev with each.
>
> At the present moment, udevd is running (according to pstree).

OK, interesting. Would be nice to know what the difference really is,
between /sbin/hotplug and /sbin/udevsend.

[...]
>> This is purely a guess on my part: install a call to modprobe anywhere
>> you like, e.g., in /etc/rc.d/rc.local, but use the udev machinery to set
>> up the /dev nodes.
>
> I do not have to set up the /dev nodes. As soon as I load the sg module,
> with
>
> /sbin/modprobe sg
>
> the /dev nodes are created.

Ah, so some hotplug events are generated by the module once it gets loaded,
and your existing infrastructure knows already how to deal with that.

What is missing is something to trigger the loading of this module.
I suppose the "Symbios SYM20810 PCI to Fast SCSI Host Adapter" does appear
in lspci, and has some directory nodes in the /sys/devices tree. Something
there should be the trigger for the missing thing.

What does this part of the device tree look like? Are any attached devices
visible before you load the sg driver? What driver does scsi host adapter
use? If the attached device is not visible, the presence (or the discovery)
of the host adapter should trigger a program or sequence of events that
lead to the discovery and enumeration of the attached devices. The missing
piece of logic must somehow attach to that.

In the end this will lead to an amendment of the distro scripts that could
be contributed. That is the point I see in not just sticking modprobe
commands in rc.local, to generate something that fits in the general
framework, is maintainable, and will load the correct modules on any
computer, not just your.

-Enrique