Description of problem: Since having upgraded to F16 from F14, I am drowning in messages similar to the one below on the console (corrupting any console output) [ 1400.353433] sd 4:0:0:0: [sdb] Asking for cache data failed [ 1400.356601] sd 4:0:0:0: [sdb] Assuming drive cache: write through accompanied by a message similar to the one in /var/log/messages (gradually filling it up) [ 1400.351374] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 1400.353433] sd 4:0:0:0: [sdb] Asking for cache data failed [ 1400.356601] sd 4:0:0:0: [sdb] Assuming drive cache: write through This machine (a netbook) only has one hard disk. sdb seems to refer to the builtin usb card reader. Version-Release number of selected component (if applicable): kernel-PAE-3.1.5-6.fc16.i686 How reproducible: 100% Expected results: The kernel not to raise these warnings/errors, but to work flawlessly (Older kernels did). I am inclined to believe the kernel is not handling this sdb device properly.
please attach the dmesg output from a fresh boot. need to see exactly which device we're working with here.
Created attachment 549125 [details] dmesg of the system exposing this issue
reported to upstream maintainer. thanks.
(In reply to comment #3) > reported to upstream maintainer. thanks. Welcome. Any upstream BZ/PR? Any patch proposals, workarounds to try?
I've been getting the same messages during boot on my laptop ever since "upgrading" from F14 to F16 and the boot process hangs right there. The only way I can use my laptop is to boot with the last 2.X kernel from F14, which works fine. No matter what 3.X kernel I try, this happens. My laptop only has one internal HDD, and I never have a CD or flash drive mounted during boot if that helps. If there's a way for me to get some data about a failed boot, please let me know and I'll do what's needed.
More info. Ever since the "upgrade," the CD/DVD on my laptop has been unusable. If I into a 3.x kernel with it empty, I get the endless [sdb] errors and putting a known-good CD in the drive first doesn't change anything.
I'm seeing this also on a laptop with builtin card reader. Every 50 seconds or so: kernel: [ 312.932881] sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled kernel: [ 312.935878] sd 6:0:0:0: [sdb] Asking for cache data failed kernel: [ 312.935888] sd 6:0:0:0: [sdb] Assuming drive cache: write through But if I remove the plastic fake SD card which fits in the slot to prevent dust, etc: kernel: [ 317.199029] usb 2-1.6: USB disconnect, device number 4 Then the kernel messages stop. On reinsertion of the fake card: kernel: [ 556.312591] usb 2-1.6: New USB device found, idVendor=0bda, idProduct=0138 kernel: [ 556.312601] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: [ 556.312608] usb 2-1.6: Product: USB2.0-CRW kernel: [ 556.312612] usb 2-1.6: Manufacturer: Generic kernel: [ 556.312616] usb 2-1.6: SerialNumber: 20090516388200000 kernel: [ 556.494090] scsi7 : usb-storage 2-1.6:1.0 mtp-probe: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6" mtp-probe: bus: 2, device: 5 was not an MTP device kernel: [ 557.517025] scsi 7:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS kernel: [ 557.519450] sd 7:0:0:0: Attached scsi generic sg2 type 0 kernel: [ 564.710556] sd 7:0:0:0: [sdb] Attached SCSI removable disk kernel: [ 608.214558] sd 7:0:0:0: [sdb] Test WP failed, assume Write Enabled kernel: [ 608.217681] sd 7:0:0:0: [sdb] Asking for cache data failed kernel: [ 608.217691] sd 7:0:0:0: [sdb] Assuming drive cache: write through and so on...
So, what component does poke sdb? I have the same problem on a small server with a built-in SD reader. I killed smartd and cupsd (with colord). Only systemd, udev, and networking servers remai.
Has any found a workaround for this. I am on fedora 16 and have the latest updates and i get this message. It does not boot to the graphical interface but continues to give me this error.
This problem appeared on my Gentoo after I upgraded udev (to version 182) and enabled DEVTMPFS in kernel (3.2.11) because this udev has started to require it. Since this change I get these three messages in kernel log each 52 seconds. The block device is USB memory card reader (0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader) without a medium.
The kernel messages correlate with following kernel/udev events: KERNEL[684.511147] change /devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block) ACTION=change DEVNAME=/dev/sdb DEVPATH=/devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb DEVTYPE=disk DISK_MEDIA_CHANGE=1 MAJOR=8 MINOR=16 SEQNUM=725 SUBSYSTEM=block UDEV [684.602048] change /devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block) ACTION=change DEVLINKS=/dev/disk/by-id/usb-Generic-_Multi-Card_20071114173400000-0:0 /dev/disk/by-path/pci-0000:00:0e.5-usb-0:1:1.0-scsi-0:0:0:0 DEVNAME=/dev/sdb DEVPATH=/devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb DEVTYPE=disk DISK_MEDIA_CHANGE=1 ID_BUS=usb ID_INSTANCE=0:0 ID_MODEL=Multi-Card ID_MODEL_ENC=Multi-Card\x20\x20\x20\x20\x20\x20 ID_MODEL_ID=0158 ID_PATH=pci-0000:00:0e.5-usb-0:1:1.0-scsi-0:0:0:0 ID_PATH_TAG=pci-0000_00_0e_5-usb-0_1_1_0-scsi-0_0_0_0 ID_REVISION=1.00 ID_SERIAL=Generic-_Multi-Card_20071114173400000-0:0 ID_SERIAL_SHORT=20071114173400000 ID_TYPE=disk ID_USB_DRIVER=ums-realtek ID_USB_INTERFACES=:080650: ID_USB_INTERFACE_NUM=00 ID_VENDOR=Generic- ID_VENDOR_ENC=Generic- ID_VENDOR_ID=0bda MAJOR=8 MINOR=16 SEQNUM=725 SUBSYSTEM=block USEC_INITIALIZED=10909217 KERNEL[687.073016] change /devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block) ACTION=change DEVNAME=/dev/sdb DEVPATH=/devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb DEVTYPE=disk DISK_MEDIA_CHANGE=1 MAJOR=8 MINOR=16 SEQNUM=726 SUBSYSTEM=block UDEV [687.089178] change /devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block) ACTION=change DEVLINKS=/dev/disk/by-id/usb-Generic-_Multi-Card_20071114173400000-0:0 /dev/disk/by-path/pci-0000:00:0e.5-usb-0:1:1.0-scsi-0:0:0:0 DEVNAME=/dev/sdb DEVPATH=/devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb DEVTYPE=disk DISK_MEDIA_CHANGE=1 ID_BUS=usb ID_INSTANCE=0:0 ID_MODEL=Multi-Card ID_MODEL_ENC=Multi-Card\x20\x20\x20\x20\x20\x20 ID_MODEL_ID=0158 ID_PATH=pci-0000:00:0e.5-usb-0:1:1.0-scsi-0:0:0:0 ID_PATH_TAG=pci-0000_00_0e_5-usb-0_1_1_0-scsi-0_0_0_0 ID_REVISION=1.00 ID_SERIAL=Generic-_Multi-Card_20071114173400000-0:0 ID_SERIAL_SHORT=20071114173400000 ID_TYPE=disk ID_USB_DRIVER=ums-realtek ID_USB_INTERFACES=:080650: ID_USB_INTERFACE_NUM=00 ID_VENDOR=Generic- ID_VENDOR_ENC=Generic- ID_VENDOR_ID=0bda MAJOR=8 MINOR=16 SEQNUM=726 SUBSYSTEM=block USEC_INITIALIZED=10909217 Both media-change events generated by kernel appears during one cycle. Once I need to use the reader, I found kernel does not signal insertion of a medium, I had to manually rescan partion table with blockdev --rereadpt. These spurious periodic media events could be a work-around implemented in kernel for the special hardware.
FWIW, https://bugzilla.kernel.org/show_bug.cgi?id=43191 seems to be the upstream bug.
I tried to boot my laptop into a 3.X kernel with a card in the reader. It got as far as recreating volatile files and directories, sat there for about ten minutes or so and rebooted. I then tried booting it (with the card still in place) into my trusty old 2.X kernel and It Just Worked. I can't speak for anybody else, but having a card in the reader not only doesn't work around the problem, it causes more problems earlier in the boot process. And, I'll admit, the idea of having to keep a memory card in the slot just to get your computer to boot would Just Be Wrong.
Same issue in Fedora 17; these messages, regarding USB card reader, appear with and without card. The only way to stop them is remove usb modules: # modprobe -r ums_realtek ums_realtek and usb-storage are interdependent.
I just tried booting my laptop with a F17 Live USB key. It worked, just fine, TYVM. Clearly, there's some interaction between the 3.X kernels and somethng else I have installed. Looks like the best way to fix this is back up anything I want to keep from my laptop (Not much, because it's not my main machine.) and do a complete nuke/pave/reinstall from scratch with F17.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still an issue with the 3.9 kernels in F19?
(In reply to comment #17) > Is this still an issue with the 3.9 kernels in F19? Yes, this bug is still present in both F18 (Real install on HD) and F19 (LiveInstall on USB-stick). With F19, there is one visible change. The "Test WP" message is gone. The log messages now look like this: [ 479.347586] sd 5:0:0:0: [sdb] Asking for cache data failed [ 479.347992] sd 5:0:0:0: [sdb] Assuming drive cache: write through
Forgot to mention the kernel versions being involved: F19: kernel-3.9.0-0.rc4.git0.1.fc19.i686 F18: kernel-PAE-3.8.5-201.fc18.i686
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
(In reply to Josh Boyer from comment #20) > Fedora 19 has now been rebased to 3.11.1-200.fc19. Bug as described in comment#0 is still present with 3.11.1-200.fc19.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
My laptop is running Fedora 20, and I just updated the kernel to 3.12.6-300.fc20.i686+PAE. Checking, /var/log/messages still contains a number of complaints about the cache data on [sdb] even though I only have one hard drive and there is no flash drive, CD/DVD or memory card inserted, although it doesn't prevent me from booting. I may be simply blinder than normal, but I don't see where I can change the version from 19 to 20, so I'd appreciate it if somebody else does this for me.
(In reply to Joe Zeff from comment #23) Bug is still present for me with both f19 and f20 (multiboot config).
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
(In reply to Justin M. Forbes from comment #25) > *********** MASS BUG UPDATE ************** > Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel > update and let us know if you issue has been resolved or if it is still > present with the newer kernel. No improvement with kernel-PAE-3.13.3-201.fc20.i686. Same issue as in 2011.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
(In reply to Justin M. Forbes from comment #27) > *********** MASS BUG UPDATE ************** > Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel > update (or newer) and let us know if you issue has been resolved or if it is > still present with the newer kernel. No improvement with kernel-PAE-3.14.4-200.fc20.i686. Same issue as in 2011.
Yeah! Petr, I own you a beer! In my case, this definitely is Linux Kernel 43191. Googling around for this bug has led me to find passing "ss_en=0" to the ums_realtek kernel module works-around (fixes ?) this issue. E.g. Add a file /etc/modprobe.d/ums-realtek.conf with this contents: options ums_realtek ss_en=0
(In reply to Ralf Corsepius from comment #29) > Yeah! Petr, I own you a beer! > > In my case, this definitely is Linux Kernel 43191. > > Googling around for this bug has led me to find passing "ss_en=0" to > the ums_realtek kernel module > works-around (fixes ?) this issue. > > E.g. Add a file > /etc/modprobe.d/ums-realtek.conf > with this contents: > options ums_realtek ss_en=0 Ralph, thanks for the excellent comment. Any news on the success (or not) of using ss_en=0? Anybody, if I see these messages and am without ss_en=0, does this just result in log noise or does it cause ill behavior besides? I'm getting these messages, but on stateless deployments that boot from a SD card so I can't really test without a respin.
(In reply to John Florian from comment #30) > Ralph, thanks for the excellent comment. Any news on the success (or not) > of using ss_en=0? AFAICT, in recent kernels (Don't know since when; I am on Fedora 20), ss_en=0 is not required anymore. > Anybody, if I see these messages and am without ss_en=0, does this just > result in log noise or does it cause ill behavior besides? The log noise isn't "that harmless". It had caused /var/log/messages rsp. journals to grow beyond reasons and caused different kinds of hick-ups on slow, small RAM systems (I am suspecting it to be co-responsible for hard machine lock ups, I once was facing with journalctl).
(In reply to Ralf Corsepius from comment #31) > (In reply to John Florian from comment #30) > > > Ralph, thanks for the excellent comment. Any news on the success (or not) > > of using ss_en=0? > AFAICT, in recent kernels (Don't know since when; I am on Fedora 20), > ss_en=0 is not required anymore. Good to know. I see the problem on my F18-based spins but not on the F20-based one nearing deployment. These two specific cases (18=bad/20=good) are both on Asus EeeBox B202 hardware, but there are many production variants of this "model" (grrrrr). Knowing you haven't seen on F20 is very helpful. > > Anybody, if I see these messages and am without ss_en=0, does this just > > result in log noise or does it cause ill behavior besides? > The log noise isn't "that harmless". It had caused /var/log/messages rsp. > journals to grow beyond reasons and caused different kinds of hick-ups on > slow, small RAM systems (I am suspecting it to be co-responsible for hard > machine lock ups, I once was facing with journalctl). Hmmm... that worries me. My B202 deployments have been mostly good but more likely than other models to exhibit troublesome behavior. I should have systemd-journald conf'd where log growth isn't an issue, but ... I actually might be able to aid my F18-based deployments after all, despite what logic and reason would have my presume. I was able to rmmod usb_realtek, make the config you offered and modprobe it back in. I had been seeing the noise about every 50s and it's now been quiet for 5m. How I was able to make the change, I don't understand. The config file only hit tmpfs (because of the statelessness), but the tools I needed to do so once rmmod'd would have had to come off SD ... or from caching of the Live squashfs.img.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
After "modprobe ums_realtek" (w/o any options) the following gets printed, but the repeating messages are gone with 3.17.2-200.fc20.i686: kernel: [162938.337569] ums-realtek 1-5:1.0: USB Mass Storage device detected kernel: [162938.347415] scsi host4: usb-storage 1-5:1.0 kernel: [162938.352902] usbcore: registered new interface driver ums-realtek kernel: ums-realtek 1-5:1.0: USB Mass Storage device detected kernel: scsi host4: usb-storage 1-5:1.0 kernel: usbcore: registered new interface driver ums-realtek kernel: [162939.357790] scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS kernel: scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS kernel: [162939.367789] sd 4:0:0:0: Attached scsi generic sg1 type 0 kernel: [162939.377269] sd 4:0:0:0: [sdb] Attached SCSI removable disk kernel: sd 4:0:0:0: Attached scsi generic sg1 type 0 kernel: sd 4:0:0:0: [sdb] Attached SCSI removable disk
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.18.7-100.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
I think this bug is back in "new clothes": ... Mar 22 19:42:14 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found Mar 22 19:42:14 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found Mar 22 19:42:14 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found Mar 22 19:41:23 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found Mar 22 19:41:23 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found Mar 22 19:41:23 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found ... Same HW as before, same symptoms, different error messages. The internet is full of people complaining about it and of kernel-maintainers and systemd maintainer mutually denying responsibility.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.19.5-100.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
My laptop is no longer doing this. I do, however get several kerneloops at boot that can't be reported because the kernel is tainted. (Flags:GW) Checking, /proc/sys/kernel/tainted reports 0. I don't know what this means, except that the earlier bug is no longer active. I'm using F 20 right now, soon to upgrade to 21.
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.
As Ralf Corsepius already mentioned, this is still happening in Fedora 21, although with a new error message: len# modprobe ums-realtek Jul 29 11:06:01 len kernel: ums-realtek 1-5:1.0: USB Mass Storage device detected Jul 29 11:06:01 len kernel: scsi host4: usb-storage 1-5:1.0 Jul 29 11:06:01 len kernel: usbcore: registered new interface driver ums-realtek Jul 29 11:06:02 len kernel: scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS Jul 29 11:06:02 len kernel: sd 4:0:0:0: [sdb] Attached SCSI removable disk Jul 29 11:06:02 len kernel: sd 4:0:0:0: Attached scsi generic sg1 type 0 Jul 29 11:06:02 len systemd-udevd[251]: error: /dev/sdb: No medium found Jul 29 11:06:03 len systemd-udevd[251]: error: /dev/sdb: No medium found === And then, every 50 seconds: Jul 29 11:06:52 len systemd-udevd[251]: error: /dev/sdb: No medium found Jul 29 11:06:53 len systemd-udevd[251]: error: /dev/sdb: No medium found Jul 29 11:06:53 len systemd-udevd[251]: error: /dev/sdb: No medium found Jul 29 11:07:44 len systemd-udevd[251]: error: /dev/sdb: No medium found Jul 29 11:07:44 len systemd-udevd[251]: error: /dev/sdb: No medium found Jul 29 11:07:44 len systemd-udevd[251]: error: /dev/sdb: No medium found Unloading (and blacklisting) ums_realtek make the error go away.
Reopening. It also happens with f22: ... Jul 30 06:06:55 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found Jul 30 06:06:55 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found Jul 30 06:06:55 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found Jul 30 06:06:03 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found Jul 30 06:06:03 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found Jul 30 06:06:03 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found Jul 30 06:05:12 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found Jul 30 06:05:12 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found # uname -a Linux gunvald1 4.1.2-200.fc22.i686+PAE #1 SMP Wed Jul 15 20:30:12 UTC 2015 i686 i686 i386 GNU/Linux
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 '21'. 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 21 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 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.
I can't reproduce this with F23 any more: $ uname -r 4.2.6-300.fc23.i686+PAE $ modprobe ums-realtek $ dmesg [...] [919349.437171] ums-realtek 1-5:1.0: USB Mass Storage device detected [919349.467214] scsi host6: usb-storage 1-5:1.0 [919349.469002] usbcore: registered new interface driver ums-realtek [919350.470825] scsi 6:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS [919350.477418] sd 6:0:0:0: Attached scsi generic sg1 type 0 [919350.486544] sd 6:0:0:0: [sdb] Attached SCSI removable disk => No more (periodic) error messages, great!