Description of problem: I use a Acer D257 netbook. This requires kmod-staging to load the rts_pstor driver needed to support the multi-reader on the side (I use it for SD cards). Under Fedora 16, with kmod-staging, inserting an SD card would result in an SD icon on the desktop. Under Fedora 17, this no longer happens, and I have to mount the SD card manually from a terminal. Version-Release number of selected component (if applicable): Linux dejah 3.3.7-1.fc17.x86_64 #1 SMP Mon May 21 22:32:19 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Up to date as of June 4, 2012. How reproducible: Always Steps to Reproduce: 1. sudo yum install kmod-staging. Reboot the machine 2. Insert SD card 3. Actual results: Doesn't show up on desktop Expected results: Expect an SD icon on the desktop Additional info: May be related to XFCE4 -- I haven't tried GNOME as this machine only has 1GB of memory. The machine was upgraded from Fedora 16 to 17 using "preupgrade". This was sucessful (the media mount point went from /media to /run/media/fred)
Inserted USB devices do appear on the desktop. This appears limited to the SD card reader.
So, this seems like possibly a udisks2 thing where it's not seeing the SD reader as a removable device. Moving over there for comment.
Please attach (as text/plain files) 1. the output of 'udisksctl dump' 2. the output of 'udevadm info --export-db' (as root) (this is from http://www.freedesktop.org/wiki/Software/udisks )
Created attachment 589531 [details] udiskctl/udevadm before and after insertion of SD, dmesg on insertion 5 files appended, plain text: udisksctl dump - before SD insertion udevadm info --export-db - before SD insertion dmesg - on SD insertion udisksctl dump - after SD insertion udevadm info --export-db - after SD insertion Search for '==>' for divider
This is the relevant section P: /devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0/block/sdb N: sdb S: disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0 E: DEVLINKS=/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0 E: DEVNAME=/dev/sdb E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0/block/sdb E: DEVTYPE=disk E: ID_BUS=scsi E: ID_DRIVE_FLASH_SD=1 E: ID_MODEL=xD_SD_M.S. E: ID_MODEL_ENC=xD\x2fSD\x2fM.S.\x20\x20\x20\x20\x20\x20 E: ID_PATH=pci-0000:03:00.0-scsi-0:0:0:0 E: ID_PATH_TAG=pci-0000_03_00_0-scsi-0_0_0_0 E: ID_REVISION=1.00 E: ID_SCSI=1 E: ID_TYPE=disk E: ID_VENDOR=Generic- E: ID_VENDOR_ENC=Generic- E: MAJOR=8 E: MINOR=16 E: MPATH_SBIN_PATH=/sbin E: SUBSYSTEM=block E: TAGS=:systemd: E: UDISKS_PRESENTATION_NOPOLICY=0 E: USEC_INITIALIZED=23898156 The problem is that ID_SERIAL (or ID_WWN_WITH_EXTENSION) is not set. Without any kind unique identifier, udisks will treat the block device as just a block device and not a drive. In particular, this means it won't get automounted. Try setting ID_SERIAL by creating a file /etc/udev/rules.d/10-temp-bz828492.rules with the following line: SUBSYSTEMS=="block", ENV{ID_MODEL}=="xD_SD_M.S.", ENV{ID_SERIAL}="1234" Then replug the device (it should automount this time). Then attach output of 'udisksctl dump' and 'udevadm info --export-db' and we can start figuring out to automatically have ID_SERIAL be set...
davidz Ok, I tried it. As I understand, SUBSYSTEM==... and SUBSYSTEMS=... are pretty much the same: I tried both. Still, it didn't show up, and ID_SERIAL is still missing. Which means something else (possibly stranger?) is happening. I am going to turn on debugging. /etc/udev/udev.conf: udev_log="info" and will try it again. But, I need to get back to some "real work" now. Can't resume until this evening. fredw
You can also try this line DRIVERS=="rts_pstor", ENV{ID_SERIAL}="1234"
Created attachment 589594 [details] udev insertion log It's an itch, and I must scratch. It appears that the new rule wasn't followed, but /usr/lib/udev/rules.d/60-persistent-storage.rules:42 was. The new rule is in /etc/udev/rules.d [fred@dejah rules.d]$ cat /etc/udev/rules.d/10-temp-bz828492.rules # Bug 828492 # # Force ID_SERIAL for card reader # SUBSYSTEMS=="block", ENV{ID_MODEL}=="xD_SD_M.S.", ENV{ID_SERIAL}="1234" [fred@dejah rules.d]$ but, for some reason, didn't get taken?
(In reply to comment #8) > Created attachment 589594 [details] > udev insertion log > > It's an itch, and I must scratch. > > It appears that the new rule wasn't followed, but > > /usr/lib/udev/rules.d/60-persistent-storage.rules:42 > > was. > > The new rule is in /etc/udev/rules.d > > [fred@dejah rules.d]$ cat /etc/udev/rules.d/10-temp-bz828492.rules > # Bug 828492 > # > # Force ID_SERIAL for card reader > # > SUBSYSTEMS=="block", ENV{ID_MODEL}=="xD_SD_M.S.", ENV{ID_SERIAL}="1234" > [fred@dejah rules.d]$ > > but, for some reason, didn't get taken? Oh, sorry, my bad - ID_MODEL is set in 60-persistent-storage.rules so you need to put it in a file with a name that sorts after that. Try 99-temp-bz828492.rules instead!
And, it appears to be the output of /usr/lib/udev/scsi_id. Running this on /dev/sda (internal drive), and /dev/sdb (plug-in SD card) yeilds: [root@dejah ~]# /usr/lib/udev/scsi_id --export --whitelisted -d /dev/sda ID_SCSI=1 ID_VENDOR=ATA ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20 ID_MODEL=WDC_WD2500BPVT-2 ID_MODEL_ENC=WDC\x20WD2500BPVT-2 ID_REVISION=01.0 ID_TYPE=disk ID_SERIAL=350014ee6ac68e89e ID_SERIAL_SHORT=50014ee6ac68e89e ID_WWN=0x50014ee6ac68e89e ID_WWN_WITH_EXTENSION=0x50014ee6ac68e89e ID_SCSI_SERIAL= WD-WXC1A91H2095 [root@dejah ~]# /usr/lib/udev/scsi_id --export --whitelisted -d /dev/sdb ID_SCSI=1 ID_VENDOR=Generic- ID_VENDOR_ENC=Generic- ID_MODEL=xD_SD_M.S. ID_MODEL_ENC=xD\x2fSD\x2fM.S.\x20\x20\x20\x20\x20\x20 ID_REVISION=1.00 ID_TYPE=disk [root@dejah ~]# And, as we can see, ID_SERIAL is present for /dev/sda, and not present for /dev/sdb. (Still not sure why the over-ride udev rule didn't work, though).
(In reply to comment #9) > Oh, sorry, my bad - ID_MODEL is set in 60-persistent-storage.rules so you > need to put it in a file with a name that sorts after that. Try > 99-temp-bz828492.rules instead! You may also need to run 'systemctl restart udev.service' after editing rules (I think this is a bug, udev is supposed to reload rules files automatically).
(In reply to comment #11) > (In reply to comment #9) > > Oh, sorry, my bad - ID_MODEL is set in 60-persistent-storage.rules so you > > need to put it in a file with a name that sorts after that. Try > > 99-temp-bz828492.rules instead! > > You may also need to run 'systemctl restart udev.service' after editing > rules (I think this is a bug, udev is supposed to reload rules files > automatically). Renamed rule to 99-temp-bz828492.rules, and "sudo systemctl restart udev.service", and the devices shows up! So, success for me, but it still leaves the underlying issue -- whatever happened to ID_SERIAL? Is the /var/log/messages sufficient for you? Or do you need me to supply more information? Thanks and, At your service fredw
Glad to hear it works with ID_SERIAL being set. Please attach the output of udevadm info --attribute-walk -n /dev/sdb and we'll see if we can cook up a generic rule for rts_pstor ...
Created attachment 589613 [details] udevadm info --attribute-walk -n /dev/sdb Results Results of running udevadm info --attribute-walk -n /dev/sdb Note that I did this twice -- once with a sony memory stick pro, and once with an sd card (just in case of differences). Attached, find the output for the sony memory stick. Diffs to the sd card are (and, as far as I an tell, appear not relevant, but "just in case"): [root@dejah /]# diff -l sony-ms sd 2012-06-05 14:44 diff -l sony-ms sd Page 1 1c1 < custom logging function 0x7f5a83ce7880 registered --- > custom logging function 0x7f72a9ae8880 registered 5,17c5,17 < device 0x7f5a85ecefd0 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0/block/sdb' < device 0x7f5a85eade20 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0' < device 0x7f5a85eade20 has devpath '/devices/virtual/bdi/8:16' < device 0x7f5a85eade20 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0' < device 0x7f5a85ed91f0 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0/scsi_generic/sg1' < device 0x7f5a85ed91f0 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0' < device 0x7f5a85ed7a70 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4' < device 0x7f5a85ee2fd0 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0' < device 0x7f5a85ee3400 has devpath '/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:17/device:18' < device 0x7f5a85ee3400 has devpath '/devices/pci0000:00/0000:00:1c.2' < device 0x7f5a85ece890 has devpath '/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:17' < device 0x7f5a85ece890 has devpath '/devices/pci0000:00' < device 0x7f5a85ed3180 has devpath '/devices/LNXSYSTM:00/device:00/PNP0A08:00' --- > device 0x7f72ab458fd0 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0/block/sdb' > device 0x7f72ab437e20 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0' > device 0x7f72ab437e20 has devpath '/devices/virtual/bdi/8:16' > device 0x7f72ab437e20 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0' > device 0x7f72ab4631f0 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0/4:0:0:0/scsi_generic/sg1' > device 0x7f72ab4631f0 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4/target4:0:0' > device 0x7f72ab461a70 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host4' > device 0x7f72ab46cfd0 has devpath '/devices/pci0000:00/0000:00:1c.2/0000:03:00.0' > device 0x7f72ab46d400 has devpath '/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:17/device:18' > device 0x7f72ab46d400 has devpath '/devices/pci0000:00/0000:00:1c.2' > device 0x7f72ab458890 has devpath '/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:17' > device 0x7f72ab458890 has devpath '/devices/pci0000:00' > device 0x7f72ab45d180 has devpath '/devices/LNXSYSTM:00/device:00/PNP0A08:00' 33c33 < ATTR{size}=="985088" --- > ATTR{size}=="3878912" 37c37 < ATTR{stat}==" 815 1777 6183 572 0 0 0 0 0 568 569" --- > ATTR{stat}==" 1063 2343 8194 727 0 0 0 0 0 723 724" 56,58c56,58 < ATTRS{iorequest_cnt}=="0xb79" < ATTRS{iodone_cnt}=="0xb79" < ATTRS{ioerr_cnt}=="0x68" --- > ATTRS{iorequest_cnt}=="0xcd0" > ATTRS{iodone_cnt}=="0xcd0" > ATTRS{ioerr_cnt}=="0x85"
OK, I've added a patch upstream to cope with such devices: http://cgit.freedesktop.org/udisks/commit/?id=93e82ba32dd51d3b8d786060c4bbe44e62a85bb5 I'll put this in an update, please test it. Stay tuned.
Also, please remember to remove any temporary udev rules before testing! Thanks!
udisks2-1.94.0-6.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/udisks2-1.94.0-6.fc17
Also, remember to reboot or do 'systemctl restart udisks2.service' after installing the update.
David Update installed, rules reverted, and it works! Thanks Muchly! fredw
Package udisks2-1.94.0-6.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing udisks2-1.94.0-6.fc17' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8899/udisks2-1.94.0-6.fc17 then log in and leave karma (feedback).
udisks2-1.94.0-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/udisks2-1.94.0-7.fc17
udisks2-1.94.0-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.