Bug 225135

Created attachment 107800 [details]
dmesg output

Attached is the dmesg output for the CF Memory USB Stick.

is this the dmesg output from the failing case?
If not, please attach one from the failing case. The dmesg above shows that the kernel recognized everything correctly.

This is the dmesg for the failure case. The kernel notices the usb stick, but it is not mounted to /media/usb_stick or anything.
I'll be updating to the release version tomorrow and will be rechecking.

I've updated to the released version, but still the same behavior. Kernel recognizes the usb stick, but auto mounting does not work.

Created attachment 108970 [details]
dmesg output for release version

I had similar behavior on my RC1 x86_64 machine. The USB drive would be recognize, but not auto-mount. I traced it down to HALD not loading (and in fact crashing, hald never was able to load). Unfortunately, 10.2 FINAL is uninstallable on my system so I'm unable to provide additional data right now.

Must be something hal or whatever related.
I assume mounting /dev/sdf1 (according to your last dmesg output) manually works ok?

Regarding #7: manually mounting works without problems

I reinstalled with the GM to get a "clean" configuration. I was able to find out where the auto-mount got broken.
After a fresh install auto-mounting worked like a charm. However it stopped as soon as I activated pam_mount for my encrypted partition.

In other words, as soon as pam_mount is activated, auto-mount stops to work.

I have exactly the same problem! I'm using pam_mount and luks to mount my encrypted partition on login, and usb-sticks are not mounted automatically. So I think, the problem can be reproduced.

(In reply to comment #0)
I have been studying the behavior of USB and seen the following:
10.0 USB works fine, all devices
10.1 USB works fine, all devices

10.2 USB works like this:

I can automount or mount manually some devices,
a USB stick and a camera can be mounted and opened.
The camera as camera or as a USB drive.

A USB card reader (tried 5 different cards) can not be mounted
a USB hard drive can not be mounted.

When plugged in the devices that can not be mounted, they only give errors to /var/log/messages.

Dec 13 21:43:16 cire102 kernel: usb 3-1: reset high speed USB
device using ehci_hcd and address 27
Dec 13 21:43:17 cire102 kernel: sd 13:0:0:3: SCSI error: return
code = 0x00070000
Dec 13 21:43:17 cire102 kernel: end_request: I/O error, dev sdg,
sector 0
Dec 13 21:43:17 cire102 kernel: Buffer I/O error on device sdg,
logical block 0

Sample of dmesg:

SCSI device sdg: 2038784 512-byte hdwr sectors (1044 MB)
sd 13:0:0:3: SCSI error: return code = 0x00070000
sd 13:0:0:3: SCSI error: return code = 0x00070000
sd 13:0:0:3: SCSI error: return code = 0x00070000

I can reproduce this behavior exactly, identically on all of my machines.
They are all different, having different mobos, different processors, different amount and quality of memory, USB1, USB2 (native and via PCI card)

The only common thing is:
USB works in 10.0 on all machines.
USB does not work on any of them in 10.2.

10.1 has been tried on two of them and it works.

(In reply to comment #11)

I made similar experiences with one of my devices:

I have several USB devices which worked fine under several Suse version including 10.2. The one I'm having trouble with is a Freecom Classic HD USB 2 with a fat32 partition. It worked fine up to Suse 9.3. (I'm not sure if used it under a 10.0 system)

Under 10.1 it showed the following behavior:
When plugged in the drive spun up, spun down, up again, and so on ... This phenomenon repeated a random number X times until it was correctly mounted. A typical X was between 3 and 20.

Under 10.2:
Same behavior but X -> infinity, which means it is never recognized by the system.

The same drive works flawlessly with Kubuntu 6.06 and Windows XP on the same system and on other systems. I can confirm the system independency since I observed it (under Suse 10.1 and 10.2) on completely different machines as well.

See attachments:
- messages (Suse 10.2 final)
- dmesg output (Suse 10.2 final)
- messages (successful: Kubuntu 6.06)

Created attachment 109986 [details]
dmesg output / suse 10.2 final

Created attachment 109987 [details]
messages / kubuntu 6.06 (successful)

Created attachment 109988 [details]
messages / suse 10.2 final

(In reply to comment #0)
> Hello,
> I cannot get USB hotplugging to work.
<snip>

I saw in alt.os.linux that also slackware 11, linux 2.6.18.2 has same kind of problems.

Looks like the kernel is the common factor?

(In reply to comment #8)
> [...]
> In other words, as soon as pam_mount is activated, auto-mount stops to work.

How looks your pam_mount configuration?
Please attach the configuration of pam_mount. 
(Feel free to remove/hide sensitive information)


(In reply to comment #11)
> (In reply to comment #0)
> I have been studying the behavior of USB and seen the following:
> 10.0 USB works fine, all devices
> 10.1 USB works fine, all devices
> 
> 10.2 USB works like this:
> 
> I can automount or mount manually some devices,
> a USB stick and a camera can be mounted and opened.
> The camera as camera or as a USB drive.
> 
> A USB card reader (tried 5 different cards) can not be mounted
> a USB hard drive can not be mounted.
> [...]
Matti, i guess previous bug comments more related to a problem of pam_mount. If your problem is independent of the use of pam_mount, please open a new bug with detailed information about the devices. So we don't mix up this two different issues.

I've attached my pam_mount configuration.
Attached are files:
/etc/pam.d/login
/etc/pam.d/xdm
/etc/security/pam_mount.conf

Created attachment 110201 [details]
/etc/pam.d/login

Created attachment 110202 [details]
/etc/pam.d/xdm

Created attachment 110203 [details]
pam_mount.conf

From your dmesg the kernel immediately resets the device and an error happens during the reset, killing the device from the kernel's viewpoint. However, no reason is in the logs. This needs a kernel log with

USB Mass Storage verbose debug
USB verbose debug messages

(In reply to comment #17)
> Matti, i guess previous bug comments more related to a problem of pam_mount. If
> your problem is independent of the use of pam_mount, please open a new bug with
> detailed information about the devices. So we don't mix up this two different
> issues.

You are right. Mine and probably Mattis problem is a different issue. I've been given a hint in a forum on how to solve this problem:
There is the following parameter wich is by default set to "1":
/sys/module/usb_storage/parameters/delay_use
I've been adviced to increase this value. With my drive "10" seems to be an appropriate value:
echo 10 > /sys/module/usb_storage/parameters/delay_use
This parameter can also be set in /etc/modprobe.conf.local:
options usb_storage delay_use=10

(I'm posting this here so Matti will receive a mail)

Finally we found the problem..... There seems to be a _kind of_ race condition in HAL.  The decrypting and mounting with the pam_mount script "/sbin/mount.crypt" triggers the race. HAL stops sending DBUS signals after this...

The race can be triggered with the pam_mount script:

mount -t crypt /dev/sda1 /mnt

This calls cryptsetup and mount:

cryptsetup luksOpen /dev/sda1 _dev_sda1;
# sleep 1
mount /dev/mapper/_dev_sda1 /mnt

The sleep of one second between this two steps would avoid the race some how...

CC'ing Danny.

Danny, regarding to the post of Matthias it seems to be that HAL is maybe only influenced by the usb_storge module...

@kay: any ideas what we can/should do or where the problem is?

HAL-mounting just doesn't support a pam_mount setup, or any other automount software. You may have to teach pam_mount to get out of the way of HAL and catch only very specific devices. You can't expect HAL-mounting to work, while any another piece of software tries to mount the same device.

(Did I miss something? The information in  this bug is a bit confusing.)

(In reply to comment #23)
> (In reply to comment #17)
> echo 10 > /sys/module/usb_storage/parameters/delay_use

I'm having the same problems with USB, Suse 10.1

I tried your fix but same problem.

Also, when the system starts with a USB device plugged in, it says that I need to restart dbus.    Restarting it doesn't help.   It also throws a "segmentation fault" error.

From Usenet, alt.os.linux.suse, someone supplied me with a fix to the problem:

http://groups.google.com/group/alt.os.linux.suse/browse_thread/thread/aabc2f99768aa62c/5e58a7d66bf4bcba?lnk=gst&q=dbus&rnum=1&hl=en#

<quote>
The cause for this segmentation fault is not dbus, but config file: /
etc/dbus-1/system.d/avahi-dbus.conf
If you move that file out of that folder, dbus will start work again! 
Just do
# mv /etc/dbus-1/system.d/avahi-dbus.conf /tmp/avahi-dbus.conf
# /etc/init.d/dbus start
</quote>

(In reply to comment #30)
Please don't mess/hijack a bug for 10.2 with stuff from 10.1 (which has absolutly nothing to do with this bug - at least because this are complete different versions of HAL and this all have nothing to do with a segfaulting D-Bus)!

This is fixed now in 10.3 ... not sure if we can backport it to 10.2

Could you summarise the fix please.

I think something a basic as this , I would say almost essential on a desktop system, these days will get more serious attention. A fix is needed to 10.2 .

I think Suse needs to take stock of where things are going. After the 10.1/remaster fiasco which still came out with missing kinternet - another fundemental basic - now we have 10.2 without USB , 10.3 stil at beta.

When did opensuse last have a fully working stable release?

It appears that there is a head long rush to bring out newer releases without ever fixing a stable offering.

Where can I voice such concerns about general direction?

TIA. 

Sorry, but this is not simply correct. USB is perfect working in 10.2 there is no fiasco with 10.2. HAL only does not work in some really special cases, which are not the default behavior.

You should unserstand that we all work on more than one bug and do what we can to provide support and produce a great product. Such discussion is unfair, useless, doesn't change anything and ignore the reality.

It also wrong that we bring out newer releases without fixing the already relased products. In this bug its simply fixed in Factory/10.3 (which is not released as a stable product atm!) because we updated HAL to a new version and as I said this is not easy to backport (because the new version is not only a small step with minor changes!), but we already determine/analyse if it is possible. Until we have a result stop this kind of discussion in bugzilla or provide a patch.

Please read what I posted. I refered to 10.1 as a fiasco not 10.2. You may not like the term but having to release a remastered version because of major breakage in yast/yum (IIRC) indicates things are getting pushed out of the door before they are finished. 

I suspect this is the fault of management putting unrealistic/rigid timescales on releases rather than being the fault of hard pushed devs. That is why I asked where I should raise these concerns. You did not reply.

I dont see anything obscure about a usb stick failing to automount , it seems pretty basic to me. I wanted to install suse for a freind but it will be useless to him without USB. I stepped back to 10.1 but the FR translation was so flakey I had to reject that possibility as well (even during install there were paragraphs of mixed English and French the main interface was equally schizophrenic) . 

I'm now looking into other distros for him.

I'm glad you were able to fix it for 10.3 but this bug was opened on 10.2 and I have exactly the same problem on 10.2 so if you dont have the time to backport you could at least post details as I requested.

You try to fend off the critisism with the old "stop critisising or provide a patch" ploy but fail to provide the information you have found out about the bug and how you fixed it on 10.3 so you're not likely to get a patch.

I summarise : please provide what you have on the bug and where can I raise my concerns about the quality of suse releases.

Thanks for your time in replying.

(In reply to comment #35)
> I dont see anything obscure about a usb stick failing to automount , it seems
> pretty basic to me. I wanted to install suse for a freind but it will be
> useless to him without USB.

You are only affected if you are making use of pam_mount and mounting an USB storage while login. This is not the case of the default "automount" way, which is done by HAL-mounter. So this is a really rare usecase, thats why this problem was not discovered in time. The only common (and non-trival) usecase where you got hit by this problem is:

An encrypted partition on an USB storage device which got mounted by pam_mount during logging.

Please correct me if i am wrong, but this is not a very basic task.

Simple automounting of USB sticks is well tested and not affected.

I am sorry about the inconvenience (and the delay of the reply).

many thanks for the reply and the clarification of the title of this bug.

It seems I was somewhat mislead by the title into thinking there was more general breakage in USB automounting.

As you will note from my earlier comments my confidence in suse has taken a dent for other recent errors like the missing kinternet and remastered issues.

I have also noted very poor error trapping in the install process. One gets the impression that it is assumed all will go well and if a fault does occur there is no recovery path. 

This does need looking at IMHO, but that's an issue for another bug.

Thanks for your reply.

Jaques, it's not as simple as you describe in comment #35.  When I released 10.1, we had no critical open bugs against the update stack and therefore released.  If there would have been critical bugs filed, we would have delayed again until those were fixed.

Looking back I can only say that the test coverage for 10.1 was too low - and we're working on that.  With openSUSE 10.3 Alpha3 you will be able to test the update stack even during installation ;-).

In general feel free to contact me either privately or on the opensuse mailing lists about any openSUSE distribution concerns.

Thanks coming back on my comments AJ. I will get back to you with some specifics when I get some free time since there are a number of important issues here.

backported patch for 10.2 ... part of submitted update for 10.2 (SWAMPID 9851)

released