From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Galeon/1.3.17 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 3. Boot Actual Results: 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 Additional info: 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.. Doh! 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 case)
*** 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.