Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 402915 - sys-fs/udev-175-r1 doesn't create /dev/sg* device nodes for SCSI scanner
Summary: sys-fs/udev-175-r1 doesn't create /dev/sg* device nodes for SCSI scanner
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: udev maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-09 18:35 UTC by Stefan Foerster
Modified: 2013-03-16 13:21 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Foerster 2012-02-09 18:35:56 UTC
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
Comment 1 Rafał Mużyło 2012-02-09 19:33:39 UTC
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 ?
Comment 2 Stefan Foerster 2012-02-09 19:47:51 UTC
(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.
Comment 3 Rafał Mużyło 2012-02-09 19:59:12 UTC
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 ?
Comment 4 Stefan Foerster 2012-02-09 20:20:38 UTC
(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.
Comment 5 William Hubbs gentoo-dev 2012-02-20 01:02:33 UTC
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
Comment 6 Stefan Foerster 2012-02-20 17:18:10 UTC
(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.
Comment 7 Stefan Foerster 2012-02-20 17:22:26 UTC
I failed to install udev-181, as it requires kmod, which is blocked by module-init-tools.
Comment 8 Stefan Foerster 2013-03-14 14:45:22 UTC
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"
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2013-03-15 15:05:05 UTC
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
Comment 10 Samuli Suominen (RETIRED) gentoo-dev 2013-03-15 15:06:36 UTC
(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
Comment 11 Stefan Foerster 2013-03-16 13:10:07 UTC
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.
Comment 12 Samuli Suominen (RETIRED) gentoo-dev 2013-03-16 13:21:10 UTC
(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?)