Created attachment 908742 [details] journalctl dump: WD Elements 3.0 USB drive not working with F20 Description of problem: F20 and the external 1TB WD Elements USB3.0 does not work. ID 1058:1078 Western Digital Technologies, Inc. Version-Release number of selected component (if applicable): Linux version 3.14.4-200.fc20.x86_64 (mockbuild@bkernel02) (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #1 SMP Tue May 13 13:51:08 UTC 2014 How reproducible: When the external HD is hot-plug it, F20 recognize it. Only to kill it at a later point. Steps to Reproduce: 1. Have the F20 booted all the way and running normally (able to reproduce on F20 live USB, also on other laptop). 2. Plug in the external WD Elements drive in USB2.0 / USB3.0 port 3. Wait and watch dmesg / journalctl reset and kill device(?) after a time out -> see logs Actual results: dmesg logging snippit [54004.640104] usb 1-1: new high-speed USB device number 19 using ehci-pci [54004.758439] usb 1-1: New USB device found, idVendor=1058, idProduct=1078 [54004.758449] usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [54004.758454] usb 1-1: Product: Elements 1078 [54004.758458] usb 1-1: Manufacturer: Western Digital [54004.758463] usb 1-1: SerialNumber: 575832314143333837363037 [54004.760028] usb-storage 1-1:1.0: USB Mass Storage device detected [54004.762631] scsi9 : usb-storage 1-1:1.0 [54014.784209] scsi 9:0:0:0: Direct-Access WD Elements 1078 1056 PQ: 0 ANSI: 6 [54014.789774] sd 9:0:0:0: Attached scsi generic sg2 type 0 [54014.790818] sd 9:0:0:0: [sdb] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB) [54014.792520] sd 9:0:0:0: [sdb] Write Protect is off [54014.792531] sd 9:0:0:0: [sdb] Mode Sense: 53 00 10 08 [54014.793936] sd 9:0:0:0: [sdb] No Caching mode page found [54014.793945] sd 9:0:0:0: [sdb] Assuming drive cache: write through [54014.798444] sd 9:0:0:0: [sdb] No Caching mode page found [54014.798457] sd 9:0:0:0: [sdb] Assuming drive cache: write through [54014.985607] sdb: sdb1 [54014.990310] sd 9:0:0:0: [sdb] No Caching mode page found [54014.990322] sd 9:0:0:0: [sdb] Assuming drive cache: write through [54014.990330] sd 9:0:0:0: [sdb] Attached SCSI disk [54048.848137] usb 1-1: reset high-speed USB device number 19 using ehci-pci journalctl logging snippit Jun 14 09:31:39 lappie kernel: usb 1-1: new high-speed USB device number 19 using ehci-pci Jun 14 09:31:39 lappie kernel: usb 1-1: New USB device found, idVendor=1058, idProduct=1078 Jun 14 09:31:39 lappie kernel: usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Jun 14 09:31:39 lappie kernel: usb 1-1: Product: Elements 1078 Jun 14 09:31:39 lappie kernel: usb 1-1: Manufacturer: Western Digital Jun 14 09:31:39 lappie kernel: usb 1-1: SerialNumber: 575832314143333837363037 Jun 14 09:31:39 lappie kernel: usb-storage 1-1:1.0: USB Mass Storage device detected Jun 14 09:31:39 lappie kernel: scsi9 : usb-storage 1-1:1.0 Jun 14 09:31:40 lappie mtp-probe[5426]: checking bus 1, device 19: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-1" Jun 14 09:31:40 lappie mtp-probe[5426]: bus: 1, device: 19 was not an MTP device Jun 14 09:31:49 lappie kernel: scsi 9:0:0:0: Direct-Access WD Elements 1078 1056 PQ: 0 ANSI: 6 Jun 14 09:31:49 lappie kernel: sd 9:0:0:0: Attached scsi generic sg2 type 0 Jun 14 09:31:49 lappie kernel: sd 9:0:0:0: [sdb] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB) Jun 14 09:31:49 lappie kernel: sd 9:0:0:0: [sdb] Write Protect is off Jun 14 09:31:49 lappie kernel: sd 9:0:0:0: [sdb] Mode Sense: 53 00 10 08 Jun 14 09:31:49 lappie kernel: sd 9:0:0:0: [sdb] No Caching mode page found Jun 14 09:31:49 lappie kernel: sd 9:0:0:0: [sdb] Assuming drive cache: write through Jun 14 09:31:49 lappie kernel: sd 9:0:0:0: [sdb] No Caching mode page found Jun 14 09:31:49 lappie kernel: sd 9:0:0:0: [sdb] Assuming drive cache: write through Jun 14 09:31:50 lappie kernel: sdb: sdb1 Jun 14 09:31:50 lappie kernel: sd 9:0:0:0: [sdb] No Caching mode page found Jun 14 09:31:50 lappie kernel: sd 9:0:0:0: [sdb] Assuming drive cache: write through Jun 14 09:31:50 lappie kernel: sd 9:0:0:0: [sdb] Attached SCSI disk Jun 14 09:32:20 lappie run-parts[5445]: (/etc/cron.daily) finished mlocate Jun 14 09:32:20 lappie run-parts[5447]: (/etc/cron.daily) starting prelink Jun 14 09:32:21 lappie run-parts[5457]: (/etc/cron.daily) finished prelink Jun 14 09:32:21 lappie anacron[5064]: Job `cron.daily' terminated Jun 14 09:32:21 lappie anacron[5064]: Normal exit (1 job run) Jun 14 09:32:22 lappie systemd-udevd[485]: worker [5429] /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host9/target9:0:0/9:0:0:0/block/sdb/sdb1 tim Jun 14 09:32:22 lappie systemd-udevd[485]: seq 4647 '/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host9/target9:0:0/9:0:0:0/block/sdb/sdb1' killed Jun 14 09:32:23 lappie kernel: usb 1-1: reset high-speed USB device number 19 using ehci-pci Jun 14 09:32:23 lappie systemd-udevd[485]: worker [5429] terminated by signal 9 (Killed) attached screenshot, taken at a earlier time. Expected results: A working external HD, that is stable usable. Additional info: Current work around 1. don't use the drive 2. boot F20 with external drive plugged in already (not sure about the stability on this since I fall back on the first work around). To exclude any HW related issue: 1. different USB ports with F20 -> doesn't work 2. externally powered the USB drive using F20 -> doesn't work 3. different OS's same test-laptops: Win7, OpenSUSE 12 -> no problem 4. different computers and devices without Fedora including: Mac, Raspberrypi, OpenPandora -> no problem
(In reply to weimanchim from comment #0) > F20 and the external 1TB WD Elements USB3.0 does not work. > ID 1058:1078 Western Digital Technologies, Inc. > I confirm the bug. WD 500GB but same identity Bus 003 Device 004: ID 1058:1078 Western Digital Technologies, Inc.
Same issue here, with a WD Elements 1TB, on Fedora 20 with kernel 3.15.6-200.fc20.x86_64. The HDD is working perfectly on the same laptop in windows 7. dmesg output: [ 998.632215] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd [ 998.643446] usb 4-2: New USB device found, idVendor=1058, idProduct=1078 [ 998.643457] usb 4-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [ 998.643462] usb 4-2: Product: Elements 1078 [ 998.643467] usb 4-2: Manufacturer: Western Digital [ 998.643483] usb 4-2: SerialNumber: 575843314132345332353536 [ 998.709466] usb-storage 4-2:1.0: USB Mass Storage device detected [ 998.710566] scsi6 : usb-storage 4-2:1.0 [ 998.710999] usbcore: registered new interface driver usb-storage [ 998.717530] usbcore: registered new interface driver uas [ 999.712220] scsi 6:0:0:0: Direct-Access WD Elements 1078 1065 PQ: 0 ANSI: 6 [ 999.714227] sd 6:0:0:0: Attached scsi generic sg1 type 0 [ 999.717388] sd 6:0:0:0: [sdb] Spinning up disk... [ 1000.718209] ......ready [ 1005.728641] sd 6:0:0:0: [sdb] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB) [ 1005.729021] sd 6:0:0:0: [sdb] Write Protect is off [ 1005.729032] sd 6:0:0:0: [sdb] Mode Sense: 53 00 10 08 [ 1005.729391] sd 6:0:0:0: [sdb] No Caching mode page found [ 1005.729398] sd 6:0:0:0: [sdb] Assuming drive cache: write through [ 1005.889155] sdb: sdb1 [ 1005.892297] sd 6:0:0:0: [sdb] Attached SCSI disk [ 1036.510661] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd journalctl output: Jul 31 23:10:00 dellmdriu kernel: usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd Jul 31 23:10:00 dellmdriu kernel: usb 4-2: New USB device found, idVendor=1058, idProduct=1078 Jul 31 23:10:00 dellmdriu kernel: usb 4-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Jul 31 23:10:00 dellmdriu kernel: usb 4-2: Product: Elements 1078 Jul 31 23:10:00 dellmdriu kernel: usb 4-2: Manufacturer: Western Digital Jul 31 23:10:00 dellmdriu kernel: usb 4-2: SerialNumber: 575843314132345332353536 Jul 31 23:10:00 dellmdriu mtp-probe[4145]: checking bus 4, device 2: "/sys/devices/pci0000:00/0000:00:14.0/usb4/4-2" Jul 31 23:10:00 dellmdriu mtp-probe[4145]: bus: 4, device: 2 was not an MTP device Jul 31 23:10:00 dellmdriu kernel: usb-storage 4-2:1.0: USB Mass Storage device detected Jul 31 23:10:00 dellmdriu kernel: scsi6 : usb-storage 4-2:1.0 Jul 31 23:10:00 dellmdriu kernel: usbcore: registered new interface driver usb-storage Jul 31 23:10:00 dellmdriu kernel: usbcore: registered new interface driver uas Jul 31 23:10:01 dellmdriu kernel: scsi 6:0:0:0: Direct-Access WD Elements 1078 1065 PQ: 0 ANSI: 6 Jul 31 23:10:01 dellmdriu kernel: sd 6:0:0:0: Attached scsi generic sg1 type 0 Jul 31 23:10:01 dellmdriu kernel: sd 6:0:0:0: [sdb] Spinning up disk... Jul 31 23:10:07 dellmdriu kernel: ......ready Jul 31 23:10:07 dellmdriu kernel: sd 6:0:0:0: [sdb] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB) Jul 31 23:10:07 dellmdriu kernel: sd 6:0:0:0: [sdb] Write Protect is off Jul 31 23:10:07 dellmdriu kernel: sd 6:0:0:0: [sdb] Mode Sense: 53 00 10 08 Jul 31 23:10:07 dellmdriu kernel: sd 6:0:0:0: [sdb] No Caching mode page found Jul 31 23:10:07 dellmdriu kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through Jul 31 23:10:07 dellmdriu kernel: sdb: sdb1 Jul 31 23:10:07 dellmdriu kernel: sd 6:0:0:0: [sdb] Attached SCSI disk Jul 31 23:10:38 dellmdriu systemd-udevd[521]: worker [4208] /devices/pci0000:00/0000:00:14.0/usb4/4-2/4-2:1.0/host6/target6:0:0/6:0:0:0/block/sdb/sdb1 timeout; kill it Jul 31 23:10:38 dellmdriu systemd-udevd[521]: seq 2548 '/devices/pci0000:00/0000:00:14.0/usb4/4-2/4-2:1.0/host6/target6:0:0/6:0:0:0/block/sdb/sdb1' killed Jul 31 23:10:38 dellmdriu kernel: usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd
There seems to exist a similar bug in Ubuntu https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1280881
I also tried in a different laptop (having only USB2 ports) with fedora 20 and an older kernel (3.12.8-300) and the HD worked. Then, after an update to latest kernel (3.15.6-200), the same issue compared. Hence, the issue seems not to be hardware related (at least from the laptop side).
@Marco How well did it work with kernel 3.12.8-300? I've noticed that I was able to mount and use the HD when booting the computer with HD already plugging in the USB. All I remember is that it didn't work with 3.13xxx
Pardon, I did a mistake. The drive was working (this means that it was recognized and not killed, but not auto mounted) because I booted with the drive already connected. Now I tried again with the 3.12.8-300, and the issue is still there (recognized but then killed).
This is my first bug report. Any idea how we can speed up the diagnoses and fix of this issue? I'm willing to help, but haven't got a clue where to start. My current work around is to use win7 ... *sight
No idea about how to speed up the fix process. In the meanwhile, a possible workaround may be to manually mount the drive, which is doable, as it is pointed out in the Ubuntu bug I liked above.
Reading in more detail the Ubuntu bug, I am experiencing the very same additional issues: 1. While the device /dev/sdb1 (for the only partition on the drive) is created, it is given permissions 600 and belongs to group root, whereas for other drives the device is given permissions 660 and belongs to group disk. 2. The usual symlinks to the device are not created in /dev/disk/by-uuid/ or /dev/disk/by-label/. 3. 'udevadm info /dev/sdb1' gives very perfunctory output for this drive, compared to the copious output for other drives. 4. 'udisksctl info -b /dev/sdb1' responds 'Error looking up object for device /dev/sdb1'.
confirming also for WD 1TB drive: Bus 002 Device 006: ID 1058:0830 Western Digital Technologies, Inc. hotplug does not work, but booting with the drive plugged in does. I can also confirm that this stopped working after an upgrade, though I don't know if it's an issue of the USB3 driver in the kernel, or a udev one.
Same issue also for newer versions of the kernel. $ uname -r 3.16.2-200.fc20.x86_64
Good news: I tried the hard disk with the alpha release of Fedora 21 (workstation) and it is perfectly working. However, still not working on Fedora 20 with kernel 3.16.2-201.fc20.x86_64.
I confirm it works with Fedora *20* and kernel-3.17.0-0.rc5.git2.2.fc22.1.x86_64 (from the fedora-rawhide-kernel-nodebug repo: for those who want to try it, it is quite stable http://fedoraproject.org/wiki/RawhideKernelNodebug)
this bug needs to be re-assigned to another component in bugzilla, either systemd (which now provides udev) or the kernel.
It looks like the drive is taking more than 30 s to initialize. We increased the timeout to 180 s in newer versions. I guess this should be backported. Otherwise it might be just a hardware issue.
This might be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1091513 in which case the problem is the "blkid" filesystem probe (see comment 8)
systemd-208-25.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/systemd-208-25.fc20
systemd-208-26.fc20,kmod-15-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/systemd-208-26.fc20,kmod-15-2.fc20
Package systemd-208-26.fc20, kmod-15-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-208-26.fc20 kmod-15-2.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-14032/systemd-208-26.fc20,kmod-15-2.fc20 then log in and leave karma (feedback).
systemd-208-25.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
On Fedora 20 with kernel 3.16.6-203.fc20.x86_64, the package systemd-208-26.fc20, kmod-15-2.fc20 is a partial fix, since the drive is recognized and not killed, but it is not automounted. At the moment the drive appears on nautilus, can be mounted there and correctly works. But still no automounting.
(In reply to Marco Driusso from comment #21) > On Fedora 20 with kernel 3.16.6-203.fc20.x86_64, the package > systemd-208-26.fc20, kmod-15-2.fc20 is a partial fix, since the drive is > recognized and not killed, but it is not automounted. At the moment the > drive appears on nautilus, can be mounted there and correctly works. But > still no automounting. Can you attach 'jouranlctl -b', 'lsblk' output?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #22) > Can you attach 'jouranlctl -b', 'lsblk' output? Here you are: - Output of jouranlctl -b (as you can see, at 15:10:16 I connected the drive, and at 15:11:37 I mounted it manually from nautilus): Nov 02 15:10:12 dellmdriu gnome-session[2990]: wrapper@/usr/share/gjs-1.0/lang.js:213 Nov 02 15:10:16 dellmdriu kernel: usb 4-2: new SuperSpeed USB device number 7 using xhci_hcd Nov 02 15:10:16 dellmdriu kernel: usb 4-2: New USB device found, idVendor=1058, idProduct=1078 Nov 02 15:10:16 dellmdriu kernel: usb 4-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Nov 02 15:10:16 dellmdriu kernel: usb 4-2: Product: Elements 1078 Nov 02 15:10:16 dellmdriu kernel: usb 4-2: Manufacturer: Western Digital Nov 02 15:10:16 dellmdriu kernel: usb 4-2: SerialNumber: 575843314132345332353536 Nov 02 15:10:16 dellmdriu kernel: usb-storage 4-2:1.0: USB Mass Storage device detected Nov 02 15:10:16 dellmdriu kernel: scsi11 : usb-storage 4-2:1.0 Nov 02 15:10:16 dellmdriu mtp-probe[14347]: checking bus 4, device 7: "/sys/devices/pci0000:00/0000:00:14.0/usb4/4-2" Nov 02 15:10:16 dellmdriu mtp-probe[14347]: bus: 4, device: 7 was not an MTP device Nov 02 15:10:17 dellmdriu kernel: scsi 11:0:0:0: Direct-Access WD Elements 1078 1065 PQ: 0 ANSI: 6 Nov 02 15:10:17 dellmdriu kernel: sd 11:0:0:0: Attached scsi generic sg1 type 0 Nov 02 15:10:17 dellmdriu kernel: sd 11:0:0:0: [sdb] Spinning up disk... Nov 02 15:10:23 dellmdriu kernel: ......ready Nov 02 15:10:23 dellmdriu kernel: sd 11:0:0:0: [sdb] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB) Nov 02 15:10:23 dellmdriu kernel: sd 11:0:0:0: [sdb] Write Protect is off Nov 02 15:10:23 dellmdriu kernel: sd 11:0:0:0: [sdb] Mode Sense: 53 00 10 08 Nov 02 15:10:23 dellmdriu kernel: sd 11:0:0:0: [sdb] No Caching mode page found Nov 02 15:10:23 dellmdriu kernel: sd 11:0:0:0: [sdb] Assuming drive cache: write through Nov 02 15:10:23 dellmdriu kernel: sdb: sdb1 Nov 02 15:10:23 dellmdriu kernel: sd 11:0:0:0: [sdb] Attached SCSI disk Nov 02 15:10:54 dellmdriu kernel: usb 4-2: reset SuperSpeed USB device number 7 using xhci_hcd Nov 02 15:10:54 dellmdriu kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e4cf8b40 Nov 02 15:10:54 dellmdriu kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e4cf8b88 Nov 02 15:10:54 dellmdriu systemd-udevd[14365]: timeout 'udisks-part-id /dev/sdb1' Nov 02 15:11:32 dellmdriu dbus-daemon[918]: dbus[918]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' Nov 02 15:11:32 dellmdriu dbus[918]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' Nov 02 15:11:32 dellmdriu systemd[1]: Starting Hostname Service... Nov 02 15:11:32 dellmdriu dbus-daemon[918]: dbus[918]: [system] Successfully activated service 'org.freedesktop.hostname1' Nov 02 15:11:32 dellmdriu dbus[918]: [system] Successfully activated service 'org.freedesktop.hostname1' Nov 02 15:11:32 dellmdriu systemd[1]: Started Hostname Service. Nov 02 15:11:37 dellmdriu ntfs-3g[14401]: Version 2014.2.15 integrated FUSE 27 Nov 02 15:11:37 dellmdriu ntfs-3g[14401]: Mounted /dev/sdb1 (Read-Write, label "MARCO_HD", NTFS 3.1) Nov 02 15:11:37 dellmdriu ntfs-3g[14401]: Cmdline options: rw,nodev,nosuid,uid=1000,gid=1000,dmask=0077,fmask=0177,uhelper=udisks2 Nov 02 15:11:37 dellmdriu ntfs-3g[14401]: Mount options: rw,nodev,nosuid,uhelper=udisks2,allow_other,nonempty,relatime,default_permissions,fsname=/dev/sdb1,blkdev,blksize=4096 Nov 02 15:11:37 dellmdriu ntfs-3g[14401]: Global ownership and permissions enforced, configuration type 1 Nov 02 15:11:37 dellmdriu udisksd[3215]: Mounted /dev/sdb1 at /run/media/mdriusso/MARCO_HD on behalf of uid 1000 Nov 02 15:11:49 dellmdriu gnome-session[2990]: Window manager warning: last_focus_time (17904050) is greater than comparison timestamp (17904048). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around... Nov 02 15:11:49 dellmdriu gnome-session[2990]: Window manager warning: Log level 16: STACK_OP_RAISE_ABOVE: sibling window 0x1800fc5 not in stack Nov 02 15:11:49 dellmdriu gnome-session[2990]: Window manager warning: Log level 16: STACK_OP_LOWER_BELOW: sibling window 0x1800fc5 not in stack Nov 02 15:11:58 dellmdriu gnome-session[2990]: (gnome-shell:3233): Gjs-WARNING **: JS ERROR: TypeError: this._titleLabel.clutter_text is null Nov 02 15:11:58 dellmdriu gnome-session[2990]: Notification<.update@/usr/share/gnome-shell/js/ui/messageTray.js:649 - Output of lsblk: (when the drive is connected but not mounted) $ lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 931.5G 0 disk └─sdb1 8:17 0 931.5G 0 part (after manually mounting it through nautilus) $ lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 931.5G 0 disk └─sdb1 8:17 0 931.5G 0 part /run/media/mdriusso/MARCO_HD
Are you sure that you're running with the updated udev? Did you reboot or restart systemd-udevd? Nov 02 15:10:16 dellmdriu kernel: usb 4-2: new SuperSpeed USB device number 7 using xhci_hcd ... Nov 02 15:10:23 dellmdriu kernel: ......ready ... Nov 02 15:10:54 dellmdriu systemd-udevd[14365]: timeout 'udisks-part-id /dev/sdb1'
(In reply to Zbigniew Jędrzejewski-Szmek from comment #24) > Are you sure that you're running with the updated udev? Did you reboot or > restart systemd-udevd? Yes I am running with systemd-208-26.fc20, and yes I rebooted before trying. $ yum info systemd Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit Installed Packages Name : systemd Arch : x86_64 Version : 208 Release : 26.fc20 Size : 12 M Repo : installed From repo : updates-testing Summary : A System and Service Manager
Moreover (I don't know if this is somehow related), I can not power down the drive in the way I usually do with other drives, i.e. `udisks --detach /dev/sdb`. Indeed, as soon as I run `udisks --detach /dev/sdb`, the drive switches off for a moment, but then immediately restarts, as if it had just been connected.
systemd-208-26.fc20, kmod-15-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Same problem with F21 on a Gateway vanilla LKX6810 with Intel Quad cpu. Would recognize presence of "My Passport" when plugged in but not mount or open it. Had 2 TB main HD with F21. Problem occurred when I added a second internal HD (was the prior boot drive with F20 installed on it.) Files would not mount or open the second HD either. When I removed the second HD the problem with the WD My Passport went away. It now mounts automatically and opens flawlessly. Hope this helps someone.
In my case (Dell Latitude 6430u), the update to Fedora 21 using fedup (now the kernel is the 3.17.7-300.fc21.x86_64) fixed the issue. The drive is recognized and automatically mounted by nautilus.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.