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:
Created attachment 135082 [details] dmesg of boot with thumb drive plugged in
still happens on 2.6.17-1.2597.fc6
still no usb thumb drive in 2.6.17-1.2600.fc6
Reassigning to correct owner, kernel-maint.
still no usb thumb drive in 2.6.18-1.2699.fc6
Pete, this looks fishy.. libusual: modprobe for usb-storage succeeded, but module is not present any ideas ?
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.
Also, please attach /etc/modprobe.conf. It can confuse mkinitrd.
Created attachment 137394 [details] /etc/modprobe.conf
still no usb thumbdrive with kernel-2.6.18-1.2747.fc6.
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.
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.
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
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)
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.
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.
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 :-)
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?
Created attachment 139553 [details] output for boot with fc5 and usb storage being auto-loaded
Created attachment 139793 [details] Candidate patch #4 - Same as above, slightly fixed - Bit mask was incorrect for FL_FAILED - Removed P3 printks
Does the fix from comment #15 work for all USB storage devices handled by libusual?
According to Comment #11 this bug looks really similar to bug 213156, can someone take a look at it and confirm my suspicion ?
After recent package upgrade this problem seems to be fixed.
(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.
Well, of course I meant: alias scsi_hostadapter1 usb-storage (and I also forgot to add myself to the CC list...)
[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).
+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.
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.
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.
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.
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.
huh? disable?
That's right, no more ub. Harald, is it a problem for you?
No, as long as the appropriate modules get loaded by any mechanism, I have no problem with that.
Has this fix been applied? I'm still experiencing the problem on the most recent Rawhide kernels (everything since test1)
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
yes.. not in initrd
I can confirm this with the latest rawhide kernel to date.
This bug needs to get fixed for Fedora 7. Who got the ball?
*** Bug 238092 has been marked as a duplicate of this bug. ***
Please read 239204
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.
ok, I'll drop ub for f7.
Is this fixed in F7?
*** Bug 212886 has been marked as a duplicate of this bug. ***
Created attachment 314872 [details] Patch #5 Set USU_MOD_FL_FAILED regardless of success of request_module.