Red Hat Bugzilla – Bug 133841
sr_mod isnt "autoloaded"
Last modified: 2007-11-30 17:10:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
I got an old cdrom scsi device which still works very well.
But on FC3t2 the sr_mod module isnt automagically loaded :
after boot time, if i want to access to the cdrom device, i have to
manually run "modprobe sr_mod". Then udev is creating the symlink but
it still belongs to root and i have to chown it to be able to access
it as a simple mortal user.
How reproducible: Always
Steps to Reproduce:
1. Find an scsi cdrom device
2. Plug it
fstab is correct :
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
lsmod|grep sr_mod|wc -l -> 0
ls -l /dev/cdrom /dev/sr0 /dev/scd0 -> No such files or directories
I'm not sure this bug belongs to modutils. Could be kernel kmod bug or
udev's fault, I honestly dont know and i'm sorry if i had to pick one
at [almost] random.
Throwing at udev for now.
Normally, if you insmod a scsi host adaptor it causes several hotplug
events, which are handled also by the scsi.agent, which loads the
sr_mod or other scsi related modules.
But if the scsi hostadapter module is loaded in the initrd, there is
no scsi.agent and also no sr_mod... thus no device nodes are created..
We could replay some hotplug events on system start after initrd, to
get the full hotplug functionality. This is already done by udevstart,
but only for devices.
We can also just put sr_mod in the initrd along with sd_mod.
It's going to be the case with more than just scsi.agent, though, I'd
think. We probably really want to make sure that things get
generically done (although, yes, adding sr_mod will fix this specific
*** Bug 131762 has been marked as a duplicate of this bug. ***
We need a real hotplug-replay mechanism...
*** This bug has been marked as a duplicate of 130746 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.