Where are all these USB Drive problems coming from?

Hi. I’m using OpenSuse 13.1 (KDE 4) (Evergreen) on my main desktop. Since I installed 13.1 about a year ago, it has had a Seagate 4 TB USB drive to allow me to make backups of my data. A month or so ago I installed another 4 TB drive internally in the desktop. It’s in gpt mode and shows up just fine in dolphin and the YAST partitioner. My USB drive, however is not showing up in dolphin, or the Yast partitioner. It does show up, as /dev/sdd, and the partition as /dev/sdd1 when I use GParted to examine my drives. It shows the uSB drive as gpt, with 255 heads, 63 sectors, and 486401 cylinders.

I’ve been trying to figure out exactly what the problem is, so I’ve been scouring the forum and Google.

1st possibility is that something is wrong with the kernel. I originally installed 13.1 with the 3.11 kernel, and it has been updated to 13.12.

Some threads have referred to some usb items being blacklisted in /etc/modprobe.d. I have tried looking in blacklist.conf and tried some of the suggests to comment out blacklist uas but that made no difference either.
Here is the blacklist.conf text:


                        #
# $Id$
#
# Listing a module here prevents modprobe from loading it via modalias (only
# aliases from /lib/modules/*/modules.alias). You may still load it explicitely.
# We blacklist some modules becaus they may harm on certain devices or they
# prevent other modules from grabbing the device.
#
# Syntax:  blacklist <driver name>
# See 'man modprobe'.
#

# uhci ... usb-uhci handles the same pci class
blacklist uhci
# usbcore ... module is loaded implicitly, ignore it otherwise
blacklist usbcore

# tulip ... de4x5, xircom_tulip_cb, dmfe (...) handle same devices
blacklist de4x5
# At least 2.4.3 and later xircom_tulip doesn't have that conflict
# xircom_tulip_cb
blacklist dmfe

# list all framebuffer drivers, some of them tend to crash during boot
# they are either compiled into the kernel, or vesafb is active
# X works fine without them, rcfbset can load them if really required
#  sed -e '/\/drivers\/video\/.*\.\(o\|ko\)$/{s@^.*/@@;s@\..*$@@;p};d'
blacklist aty128fb
blacklist atyfb
blacklist clgenfb
blacklist cyber2000fb
# cyblafb, bug 466280
blacklist cyblafb
blacklist encode-big5
blacklist encode-gb
blacklist encode-gbk
blacklist encode-jis
blacklist encode-kscm
blacklist fbcon-afb
blacklist fbcon-cfb2
blacklist fbcon-cfb4
blacklist fbcon-hga
blacklist fbcon-ilbm
blacklist fbcon-iplan2p2
blacklist fbcon-iplan2p4
blacklist fbcon-iplan2p8
blacklist fbcon-mac
blacklist fbcon-mfb
blacklist fbcon-vga
blacklist fbcon-vga-planes
blacklist fbgen
blacklist g450_pll
blacklist hgafb
blacklist i2c-matroxfb
blacklist i810fb
blacklist intelfbdrv
blacklist intelfbhw
blacklist matroxfb_accel
blacklist matroxfb_base
blacklist matroxfb_crtc2
blacklist matroxfb_DAC1064
blacklist matroxfb_g450
blacklist matroxfb_maven
blacklist matroxfb_misc
blacklist matroxfb_proc
blacklist matroxfb_Ti3026
blacklist mdacon
blacklist neofb
blacklist pm2fb
blacklist pm3fb
blacklist radeonfb
blacklist rivafb
blacklist sisfb
blacklist sstfb
blacklist tdfxfb
blacklist tridentfb
blacklist unikey
blacklist vga16fb
blacklist vgastate
blacklist vmware
# for kyrofb see Bug 35810
blacklist kyrofb
# list was not complete (bug 106715)
blacklist arcfb
blacklist backlight
blacklist lcd
blacklist cirrusfb
blacklist gx1fb
blacklist intelfb
blacklist macmodes
blacklist nvidiafb
blacklist s1d13xxxfb
blacklist savagefb
# additional modules since SLE11, bug 468964
blacklist arkfb
blacklist carminefb
blacklist gxfb
blacklist hecubafb
blacklist lxfb
blacklist s3fb
blacklist sm501fb
blacklist viafb
blacklist vmlfb
blacklist vt8623fb
#bug 846218
blacklist udlfb

# ISDN modules are load from /lib/udev/isdn.sh
blacklist fcusb
blacklist fcusb2
blacklist fxusb
blacklist fxusb_CZ
blacklist fcdslusb
blacklist fcdslusb2
blacklist fcdslusba
blacklist fcdslslusb
blacklist fcdslslusb2
blacklist e2220pc
blacklist e5520pc
blacklist bfusb
blacklist b1isa
blacklist b1pci
blacklist b1pcmcia
blacklist c4
blacklist t1isa
blacklist t1pci
blacklist divas
blacklist act2000
blacklist hfc_usb
blacklist hisax
blacklist hisax_fcpcipnp
blacklist hisax_st5481
blacklist hysdn
blacklist icn
blacklist pcbit
blacklist sc
blacklist tpam
blacklist fcpci
blacklist fcclassic
blacklist fcdsl
blacklist fcdsl2
# mISDN modules
blacklist hfcsusb
blacklist hfcpci
blacklist hfcmulti
blacklist l1oip
blacklist mISDN_dsp
blacklist mISDN_core

# OSS PCI sound modules
blacklist ad1889
blacklist ali5455
blacklist btaudio
blacklist cmpci
blacklist cs4281
blacklist emu10k1
blacklist es1370
blacklist es1371
blacklist esssolo1
blacklist forte
blacklist i810_audio
blacklist maestro
blacklist maestro3
blacklist nm256_audio
blacklist opl3sa2                 # Bug 219758
blacklist rme96xx
blacklist sonicvibes
blacklist trident
blacklist via82cxxx_audio
blacklist ymfpci

# If you really need firewire direct networking, then remove this entry
blacklist eth1394

# this is a debugging module which should only be loaded manually
blacklist evbug

# These mtd drivers should be loaded manually.
blacklist scb2_flash
blacklist ich2rom
blacklist pci
blacklist l440gx
blacklist amd76xrom

# job of rcdvb
blacklist snd_bt87x
blacklist snd-bt87x

# HP Touch Screen usb input driver. breaks all other mouse input devices
blacklist tsdev

# https://bugzilla.novell.com/show_bug.cgi?id=115132
blacklist slamr
blacklist slusb

# This module seems to be good for nothing. See bug 129301.
blacklist dpt_i2o

# This driver is obsolete and should never be loaded as default.
# See https://bugzilla.novell.com/show_bug.cgi?id=146728
blacklist eepro100

# This driver is obsolete and should never be loaded as default.
# See https://bugzilla.novell.com/show_bug.cgi?id=146930
blacklist sk98lin

# This driver is rarely needed and causes trouble when scanning devices.
# See: https://bugzilla.novell.com/show_bug.cgi?id=144623
blacklist stradis

# These devices have bt878 chip without PCI Subsystem ID. Without that info bttv
# does not know how to treat them properly. Therefore we disable autoloading of
# modules for these devices.
# See https://bugzilla.novell.com/show_bug.cgi?id=149588
# To enable your device create a hardware configuration file for your device.
# See man hwup for details.
# You will probably have to specify an option to identify your card. Have a
# look in /usr/src/linux/Documentation/video4linux/CARDLIST.bttv.
alias pci:v0000109Ed0000036Esv00000000sd00000000bc04sc00i00 bttv_skip_it
alias pci:v0000109Ed00000878sv00000000sd00000000bc04sc80i00 bttv_skip_it
install bttv_skip_it echo "module alias skipped (bt878 chip without PCI Subsystem ID)"

# For some bridges both intel-agp and i82875p_edac are loaded. If i82875p_edac
# is loaded first it will grab the device. Then intel-agp doesn't work.
# Therefore we disable automatic loading of 82875p_edac. (Bug 213840)
blacklist i82875p_edac
#
# Blacklist the IBM s390 module for I/O dynamic configuration support
# Bug bnc#478601
blacklist chsc_sch
# uas has been confirmed to be hopelessly broken
# Bug bnc#770301
blacklist uas  

I even went as far as picking up another seagate USB drive ( a 5TB, formatted ntfs) and trying it. it works fine in a windows 7 box, but is invisible under opensuse 13.1

I must confess, I don’t have a lot of hair left (to pull out) and I need my backup drive. And when I plug in a USB thumb drive opensuse recognizes it right away. Try to plug in a USB drive and nothing happens.

I suppose I could try to reinstall OpenSuse 13.1 with the original kernel, but it will get overwritten as soon as I do updates.

Suggestions on how to solve this conundrum gratefully received.

After posting my plaintive message asking where all these USB drive problems are coming from, I re read some previous posts and noticed something i hadn’t seen before. So to fix it, I did the following:

As root, edited the /etc/modprobe.d/blacklist.conf file, and commented out the blacklist uas line, so that now it read # blacklist uas. I saved to the file.

Next, I opened a terminal window and typed mkinitrd.

Then I re-booted.

Like magic, my drive appeared.

All I want to know now, is why the blacklist.conf had blacklist uas added in the first place, and why whoever added it seems to have ignored the grief this would cause ordinary users.

Bob

Am Fri, 17 Jun 2016 21:16:01 GMT
schrieb robertsmits <robertsmits@no-mx.forums.microfocus.com>:

> All I want to know now, is why the blacklist.conf had blacklist uas

https://lists.opensuse.org/opensuse-kernel/2016-05/msg00002.html


Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

[QUOTE=Akoellh;2782621]Am Fri, 17 Jun 2016 21:16:01 GMT
schrieb robertsmits <robertsmits@no-mx.forums.microfocus.com>:

> All I want to know now, is why the blacklist.conf had blacklist uas

https://lists.opensuse.org/opensuse-kernel/2016-05/msg00002.html
/QUOTE]

I’m very glad that there is a way to fix the problem, but I wish there was a way to notify users that they might have a problem after a kernel update, and relate what is happening. Surely the use of usb storage drives is growing and large drives over 2 TB are getting more and more common. People may conclude their drive has failed and unnecessarily purchase another one, for example. Or waste days of time trying to fix the problem, as well as filling up the forums with related problems that are to users, difficult to figure out and describe.

Perhaps when such a major effect is caused by this kind of change is introduced, perhaps a post in the How-to/FAQ forum?

I’m very glad that there is a way to fix the problem, but I wish there was a way to notify users that they might have a problem after a kernel update, and relate what is happening

It pays to check the mailing lists and bug reports IMHO.

Very few affected now I guess. Not many using such an old kernel. It’s been fine since 3.15 apparently, and hasn’t been blacklisted for some time. For example, openSUSE 13.2 and Leap don’t have this module blacklisted.

Surely the use of usb storage drives is growing and large drives over 2 TB are getting more and more common. People may conclude their drive has failed and unnecessarily purchase another one, for example. Or waste days of time trying to fix the problem, as well as filling up the forums with related problems that are to users, difficult to figure out and describe.

Yep, and that’s why UAS kernel support has been provided for a while now. Sometimes it is necessary to upgrade kernels, even when using legacy (or LT) distro versions so that newer hardware is supported.

Perhaps when such a major effect is caused by this kind of change is introduced, perhaps a post in the How-to/FAQ forum?

Feel free to participate in doing that yourself when you feel the need to broadcast such information.

Old kernel? It’s the current kernel for Evergreen :slight_smile:

Yep, that is the case, but 3.12.x is not a recent kernel.