Bug 204396 - kernel does not see usb thumb drive during boot
kernel does not see usb thumb drive during boot
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
: 212886 238092 (view as bug list)
Depends On: 239204
Blocks: FC7Blocker
  Show dependency treegraph
 
Reported: 2006-08-28 16:53 EDT by Jason
Modified: 2008-08-23 23:55 EDT (History)
16 users (show)

See Also:
Fixed In Version: F7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-27 10:18:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg of boot with thumb drive plugged in (20.30 KB, text/plain)
2006-08-28 16:56 EDT, Jason
no flags Details
/etc/modprobe.conf (253 bytes, text/plain)
2006-09-29 10:15 EDT, Jason
no flags Details
pendrive appera in nautilus less than 1 secs. (7.17 KB, image/png)
2006-10-10 16:14 EDT, I. Piasecki
no flags Details
Workaround for 50-udev.rules (444 bytes, text/plain)
2006-10-14 04:13 EDT, Pete Zaitcev
no flags Details
Candidate patch #3 - Kernel-side fix with class (3.68 KB, patch)
2006-10-16 03:20 EDT, Pete Zaitcev
no flags Details | Diff
output for boot with fc5 and usb storage being auto-loaded (17.42 KB, text/plain)
2006-10-27 00:51 EDT, Patrick Mansfield
no flags Details
Candidate patch #4 - Same as above, slightly fixed (3.53 KB, patch)
2006-10-30 21:38 EST, Pete Zaitcev
no flags Details | Diff
Patch #5 (3.95 KB, patch)
2008-08-23 23:55 EDT, Pete Zaitcev
no flags Details | Diff

  None (edit)
Description Jason 2006-08-28 16:53:35 EDT
Description of problem:
I am running the Aug 28 rawhide.  I boot fedora with a kanguru 2GB flash memory
drive in a usb port and try to mount it after login.  The system says there is
no such mount point (/dev/sdc1).  I check /dev and sure enough no sdc*.  I pull
the drive, wait 10 seconds, plug it in and there it is.  /dev/sdc becomes
available.  So why can't I mount my thumb drive when the system boots?

Version-Release number of selected component (if applicable):
2.6.17-1.2586.fc6

How reproducible:
don't know.  This is the only kernel available. 

Steps to Reproduce:
1.  plug in a usb flash memory drive
2.  boot the system
3.  login and try to mount it
  
Actual results:


Expected results:


Additional info:
Comment 1 Jason 2006-08-28 16:56:03 EDT
Created attachment 135082 [details]
dmesg of boot with thumb drive plugged in
Comment 2 Jason 2006-08-29 17:12:57 EDT
still happens on 2.6.17-1.2597.fc6
Comment 3 Jason 2006-09-01 12:02:15 EDT
still no usb thumb drive in 2.6.17-1.2600.fc6
Comment 4 David Lawrence 2006-09-05 11:32:25 EDT
Reassigning to correct owner, kernel-maint.
Comment 5 Jason 2006-09-28 16:34:19 EDT
still no usb thumb drive in 2.6.18-1.2699.fc6
Comment 6 Dave Jones 2006-09-28 18:08:19 EDT
Pete, this looks fishy..

libusual: modprobe for usb-storage succeeded, but module is not present

any ideas ?
Comment 7 Pete Zaitcev 2006-09-28 18:21:51 EDT
It is impossible to run modprobe normally in initrd, because the modprobe
is shortcut by nash. This probably happens because of SCSI root, which
makes mkinitrd to load libusual by mistake.

As a workaround, I suggest to unplug all USB storage, rmmod usb-storage,
rmmod libusual, then re-run this:
  mkinitrd /boot/initrd-2.6.17-1.2586.fc6.img 2.6.17-1.2586.fc6
This ought to create an initrd image without USB modules.

I have a system which boots off SATA, so I'll try to tinker with this,
see if I can reproduce it.
Comment 8 Pete Zaitcev 2006-09-28 18:23:05 EDT
Also, please attach /etc/modprobe.conf. It can confuse mkinitrd.
Comment 9 Jason 2006-09-29 10:15:28 EDT
Created attachment 137394 [details]
/etc/modprobe.conf
Comment 10 Jason 2006-10-09 19:20:53 EDT
still no usb thumbdrive with kernel-2.6.18-1.2747.fc6.
Comment 11 Matthias Saou 2006-10-10 04:46:23 EDT
I can confirm I see this to with the latest Rawhide on an x86_64 : If I boot
with my external 200GB USB hard drive powered on, it doesn't appear, nor does
the computer's internal USB card reader. If I power it off then back on, both
the external drive and the multiple card reader slots appear in nautilus'
"Computer" window.
Comment 12 I. Piasecki 2006-10-10 15:52:42 EDT
I use x86_64 on AMD64 and no usbpendrive on my gnome desktop, when sticked it in
usb port, but in nautilus i can see over ca. 0.5 sec icon of my beloved pendrive
.... and it dissapeard.
Comment 13 I. Piasecki 2006-10-10 16:14:01 EDT
Created attachment 138188 [details]
pendrive appera in nautilus less than 1 secs.

i use kernel: 2.6.18-1.2741 but prepare for 2.6.18-1.2747
Comment 14 Pete Zaitcev 2006-10-13 03:25:34 EDT
I reproduced the problem locally and the following is happening:

- At kernel init time, static libusual is probed and it registers a driver
- When USB HCDs are loaded, khubd probes USB buses; this does kevent_add(ADD)
  and loops matching drivers, then calling driver's probe routines
- The libusual is probed and correctly refuses the probe, so the result is
  indistinguishable from not having a driver in the initrd
- When udev starts, it does not force any kind of re-probing of any buses.
  Instead, it fetches events which kevent_add posted, then runs
   modprobe usb:vXXXXpYYYY.....
  The alias resolves to libusual
- The modprobe fails to load anything, because libusual is static

So, I did not think this through well enough. I expected the replay to
load correct drivers, which it attempts to do, but fails.

I was wrong in the comment #7, the workaround is to include usb-storage
with the following
 cd /boot
 mv initrd-2.6.18-1.2693.fc6.img initrd-2.6.18-1.2693.fc6.img.save
 mkinitrd --with=usb-storage initrd-2.6.18-1.2693.fc6.img 2.6.18-1.2693.fc6
(with the appropriate kernel version used accordingly)
Comment 15 Pete Zaitcev 2006-10-14 04:13:00 EDT
Created attachment 138493 [details]
Workaround for 50-udev.rules

This workaround does not require to rebuild initrd, so newly installed
kernels would work automatically too.
Comment 16 Pete Zaitcev 2006-10-16 03:20:05 EDT
Created attachment 138555 [details]
Candidate patch #3 - Kernel-side fix with class

This patch uses the fact that udevtrigger in udev-095 scans classes and
posts add events. We create a dummy class, which uses the uevent as an
indication that normal userland is in force. When called, we retry
request_module.

Any and all problems can be fixed in kernel, the question is only if
it makes sense.
Comment 17 Matthias Saou 2006-10-16 08:40:27 EDT
Adding usb-storage to the initrd seems like the wrong thing to do, since we are
not trying to boot off usb, right? As for the udev rule vs. the kernel patch...
well... you'll know best I hope :-)
Comment 18 Patrick Mansfield 2006-10-27 00:48:24 EDT
That all makes sense, but it works fine for me on current FC5 with kernel
2.6.18-1.2200.fc5 (I have not had time to try FC6 anywhere).

I am not booting off a scsi disk, and root is on ext3 partition (no lvm/dm is used).

I like the udev rule.

Can't you always base whether or not ub or usb-storage is loaded on a user space
rule and/or config file (not sure what you do without udev in initrd for root fs
on USB), and get rid of the request_module and bias code in libusual? Or does
libusual then go away?
Comment 19 Patrick Mansfield 2006-10-27 00:51:53 EDT
Created attachment 139553 [details]
output for  boot with fc5 and usb storage being auto-loaded
Comment 20 Pete Zaitcev 2006-10-30 21:38:59 EST
Created attachment 139793 [details]
Candidate patch #4 - Same as above, slightly fixed

- Bit mask was incorrect for FL_FAILED
- Removed P3 printks
Comment 21 Harald Hoyer 2006-11-02 04:05:24 EST
Does the fix from comment #15 work for all USB storage devices handled by libusual?
Comment 22 Vladimir Kotal 2006-11-02 19:10:45 EST
According to Comment #11 this bug looks really similar to bug 213156, can
someone take a look at it and confirm my suspicion ?
Comment 23 Vladimir Kotal 2006-11-19 06:52:20 EST
After recent package upgrade this problem seems to be fixed.
Comment 24 Piergiorgio Sartor 2006-12-10 07:03:59 EST
(In reply to comment #17)
> Adding usb-storage to the initrd seems like the wrong thing to do, since we are
> not trying to boot off usb, right? As for the udev rule vs. the kernel patch...
> well... you'll know best I hope :-)

I went into the same issue with a SCSI based PC, which has an cold plugged USB
storage device.
My solution was to add to /etc/modprobe.conf the line:

alias scsi_controller1 usb-storage

and the rebuild the initrd, without any special parameters.
Note that the first SCSI controller in /etc/modprobe.conf is the one
automatically defined during install time (I guess aha... something).

This solution was needed since the USB storage partitions must be available at
normal mount time, i.e. they are mounted from /etc/fstab and not from gnome-mount.

The question is: does the udev or kenel solution guarantee that usb-storage.ko
is loaded (and settles) in time for the the /etc/fstab mount?

Because an other (working) system, with different hardware, but same external
storage (and not /etc/modprobe.conf modifications), does not seem to have well
defined timings. It seems to me udev loads usb-storage.ko and this,
asynchronously, probes the USB subsystem and attaches the proper drives, i.e. it
will not necessarily finish before /etc/fstab is used to mount all the partitions.
I did not look deep into this (no time, sorry), so maybe my assumption (about
timinings) is wrong. If not, please consider this case before any patches,
updates or whatever are released.

Thanks.
Comment 25 Piergiorgio Sartor 2006-12-11 16:59:31 EST
Well, of course I meant:

alias scsi_hostadapter1 usb-storage

(and I also forgot to add myself to the CC list...)
Comment 26 Pete Zaitcev 2006-12-21 02:35:17 EST
[Adding Jon to cc: so he knows what's coming.]

Patrick is quite right in comment #18, a user-mode solution would be preferred.
But it's much more involved than anyone could imagine (well, anyone outside of
Jon Masters, Rusty, DaveJ, and other people who touched module-init-tools).

The key problem is, modprobe does not allow alias recursion. But when kernel
calls udev with usb:vXXXXpYYYY..., this goes through the alias path and uses
up the alias count. Therefore, if I write "alias libusual usb-storage" in
/etc/modprobe.conf, it does not work because one match has happened already.

I talked to Rusty about it two years ago, he was not completely averse to
adding recursive or iterative aliasing to modprobe. But adding it seemed
harder to me than throwing together libusual.

Since Greg K-H rejected my patch to add a class to libusual, I am going to
look at modprobe (and removing request_module from libusual completely).
Comment 27 Harald Hoyer 2006-12-21 03:53:58 EST
+ACTION=="add", SUBSYSTEM=="usb",
ENV{MODALIAS}=="usb:v*p*d*dc*dsc*dp*ic08isc*ip*", RUN+="/sbin/modprobe usb-storage"

is as good as adding a modalias to usb-storage. So? Udev or module? In fact,
this would be the only module, where the modalias is hardcoded in udev instead
of the kernel module.
Comment 28 Pete Zaitcev 2006-12-21 04:38:50 EST
Harald, I only proposed this as a quick workaround for affected users,
for a couple of reasons.

#1 - It locks usb-storage, so you can't change it to ub. If we do that,
might as well disable ub altogether.

#2 - It is conceptually wrong, because it encodes the knowledge of
the alias resolution (e.g. now the 50.udev magically "knows" that
ic08 == usb-storage). This is something modules.alias has to specify,
and not any other files.

So, please don't add it to udev.
Comment 29 Jon Masters 2006-12-21 13:41:27 EST
Thanks for the heads up. Let's get recursive alias support into
module-init-tools then. Yes, it'll be a pain in the <something> but you're not
likely to be the only person with this kind of problem :-)

So, Pete, you looking at the patch or do you want me to have a look over the
holidays once I'm done with my veggie turkey alternatives? :-)

Jon.
Comment 30 Pete Zaitcev 2006-12-21 14:11:18 EST
Jon, I created this situation in the first place, so I am going to write
the fix. And I'm sure you have things to do.
Comment 31 Pete Zaitcev 2006-12-29 02:44:02 EST
I was mistaken about modprobe and alias resolution. Changing that would not
fix the main problem, which is, in short, the entries in module.alias being
absent for USB storage devices.

I came to think that the only solution is to disable ub and libusual.
Comment 32 Harald Hoyer 2007-01-10 06:18:18 EST
huh? disable?
Comment 33 Pete Zaitcev 2007-01-10 13:59:08 EST
That's right, no more ub. Harald, is it a problem for you?
Comment 34 Harald Hoyer 2007-01-11 07:41:45 EST
No, as long as the appropriate modules get loaded by any mechanism, I have no
problem with that.
Comment 35 Michel Alexandre Salim 2007-02-17 20:03:27 EST
Has this fix been applied? I'm still experiencing the problem on the most recent
Rawhide kernels (everything since test1)
Comment 36 Michel Alexandre Salim 2007-02-20 13:24:58 EST
Relevant lines from dmesg; it seems that libusual is indeed trying to load
usb-storage, but could not find it (not in initrd?) -- right now I'm resorting
to manually loading usb-storage

usb 3-3.4: new high speed USB device using ehci_hcd and address 6
usb 3-3.4: configuration #1 chosen from 1 choice
libusual: modprobe for usb-storage succeeded, but module is not present
input: Western Digital External HDD as /class/input/input5
input: USB HID v1.11 Device [Western Digital External HDD] on usb-0000:00:13.2-3
.4
Comment 37 Harald Hoyer 2007-02-22 06:53:42 EST
yes.. not in initrd
Comment 38 Stewart Adam 2007-04-01 23:03:28 EDT
I can confirm this with the latest rawhide kernel to date.
Comment 39 David Zeuthen 2007-05-02 11:54:51 EDT
This bug needs to get fixed for Fedora 7. Who got the ball?
Comment 40 David Zeuthen 2007-05-02 11:55:21 EDT
*** Bug 238092 has been marked as a duplicate of this bug. ***
Comment 41 Leslie Satenstein 2007-05-07 18:06:19 EDT
Please read 239204

Comment 42 Pete Zaitcev 2007-05-09 20:59:47 EDT
David, regarding the ball:

I understand that Dave Jones & Chuck Ebbert were reluctant to remove ub,
because in some cases it works (e.g. lots of dirty writeout and VM lockup).
In the same time, they did not want to carry the patch from comment #20
without an upstream committment. So they left this open in hopes that
I would cook up some compromise, but it's not happening.

I would be happy with either solution immediately, but going forward it's
probably better to drop ub and fix usb-storage problems as they come.
Comment 43 Dave Jones 2007-05-18 12:21:19 EDT
ok, I'll drop ub for f7.
Comment 44 Rahul Sundaram 2007-06-04 10:37:44 EDT
Is this fixed in F7?
Comment 45 Jon Stanley 2007-12-31 01:44:17 EST
*** Bug 212886 has been marked as a duplicate of this bug. ***
Comment 46 Pete Zaitcev 2008-08-23 23:55:21 EDT
Created attachment 314872 [details]
Patch #5

Set USU_MOD_FL_FAILED regardless of success of request_module.

Note You need to log in before you can comment on or make changes to this bug.