I was obviously too brave when I unmasked udev-175-r1 and upgraded udev from 171-r5. Of course, I got punished for this... It turned out that the system no longer creates device nodes for my SCSI Scanner. Reproducible: Always Steps to Reproduce: 1. install udev-175-r1 2. attach SCSI scanner (in my case: Fujitsu M3093DGdm) 3. restart system 4. see that no device nodes /dev/sg* had been created Actual Results: no device nodes /dev/sg* are created Expected Results: # ls /dev/sg* /dev/sg0 /dev/sg1 /dev/sg2 /dev/sg3 /dev/sg4 This is the information I get from "scsiadd", regardless of the udev version. So from a hardware point of view there is no problem. It's just udev. -------------------- Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: SONY Model: DVD RW DRU-720A Rev: JY02 Type: CD-ROM ANSI SCSI revision: 05 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: Hitachi HUA72201 Rev: JP4O Type: Direct-Access ANSI SCSI revision: 05 Host: scsi2 Channel: 00 Id: 01 Lun: 00 Vendor: FUJITSU Model: M3093DGdm Rev: 02 Type: Scanner ANSI SCSI revision: 02 Host: scsi5 Channel: 00 Id: 00 Lun: 00 Vendor: SEAGATE Model: ST3146707LW Rev: 7804 Type: Direct-Access ANSI SCSI revision: 03 Host: scsi5 Channel: 00 Id: 01 Lun: 00 Vendor: SEAGATE Model: ST3146707LW Rev: 7804 Type: Direct-Access ANSI SCSI revision: 03
There's this commit to consider: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=09637f743414e2c36d6c5b032d77d76dbeb86b31 so the question is: "is sg module loaded ?". On a related note, are you sure it's sg* nodes that you need ?
(In reply to comment #1) > There's this commit to consider: > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=09637f743414e2c36d6c5b032d77d76dbeb86b31 > so the question is: "is sg module loaded ?". > > On a related note, are you sure it's sg* nodes that you need ? udev-175-r1: no, sg is not loaded udev-171-r5: yes, sg is loaded And yes, I need the sg module. What other module (and device node) should be used (created) instead for a SCSI scanner? There are currently not very good developments going on in udev - I have two other machines having problems with udev (two notebooks running Arch Linux with broken wifi due to udev updates). I really hope that older hardware will continue to be supported by Linux.
Well, while turning udev into a backend of systemd is indeed worrying, that seems to suggest there's no bug here, you just need to add the module to /etc/conf.d/modules. As for the other part, beats me, not like I have a scanner. Also, it's not really a hardware problem, is it ?
(In reply to comment #3) > Well, while turning udev into a backend of systemd is indeed worrying, that > seems to suggest there's no bug here, you just need to add the module to > /etc/conf.d/modules. > > As for the other part, beats me, not like I have a scanner. Also, it's not > really a hardware problem, is it ? Thanks for your quick reply. At the moment I will stick to udev-171, but also add the module to /etc/conf.d/modules. The scanner works perfectly under Linux. It's a cool piece of hardware that scans 100 pages in duplex mode within a few minutes.
I am closing this since you have added the module to /etc/conf.d/modules. When you upgrade to udev-181 it should be fixed. Please test when you do this and report back to the bug. Thanks, William
(In reply to comment #5) > I am closing this since you have added the module to > /etc/conf.d/modules. When you upgrade to udev-181 it should be fixed. > Please test when you do this and report back to the bug. > > Thanks, > > William I am not really happy with this solution. I have the following udev rules that quite elegantly set groups and permission rights for users. KERNEL=="sg[0-9]*", ATTRS{type}!="3|6|7", GROUP="disk", MODE="0666" KERNEL=="sg[0-9]*", ATTRS{type}=="7", GROUP="scanner", MODE="0666" I'll try and report back, but the device nodes created will most probably only allow access to root, so that I will not be able to use the scanner as user. I'll have to grant user rights and somehow have to set groups in rc.local. Not a good solution. I don't like all these recent changes in udev that broke three of my machines (the other two have wifi problems with suddenly 'broken' kernel modules) that have been running for years without any problems.
I failed to install udev-181, as it requires kmod, which is blocked by module-init-tools.
Just for the sake of completeness and for those who don't think that these devices are "obsolete": I currently use the following udev rule with udev-197 to keep my SCSI scanner working: SUBSYSTEM=="scsi_device", ATTRS{type}=="[235689]", TEST!="[module/sg]", RUN+="/sbin/modprobe -b sg" SUBSYSTEM=="scsi", KERNEL=="sg[0-9]*", ATTRS{type}=="5", GROUP="scanner"
Is sane-backends installed? It should come with a rule to set GROUP="scanner" where required It's the sane-backends ebuild that creates the group and owns the 41-sane.rules for udev In that case, this wouldn't be necessarily a bug in udev, rather bug in sane-backends rules
(In reply to comment #9) > Is sane-backends installed? It should come with a rule to set > GROUP="scanner" where required > It's the sane-backends ebuild that creates the group and owns the > 41-sane.rules for udev > In that case, this wouldn't be necessarily a bug in udev, rather bug in > sane-backends rules Meant to say /lib/udev/rules.d/41-libksane.rules
sane-backends are installed, of course. The file in udev.d is called "41-libsane.rules" not "41-libksane.rules". There is no rule in this file which would load the module sg.ko. Thus currently it is necessary to work with custom udev rules.
(In reply to comment #11) > sane-backends are installed, of course. right, is it even possible to use scanner without sane on linux? far as I know, it's not propably why the scanner group creation is in sane-backends, nowhere else and nobody have complained :) > The file in udev.d is called "41-libsane.rules" not "41-libksane.rules". right, sorry, KDE^W^W^Wtyping error > There is no rule in this file which would load the module sg.ko. Thus > currently it is necessary to work with custom udev rules. that doesn't sound right, how about creating a patch against 41-libsane.rules out from your custom patch? (propably needs to be made more specific to your device?)
