On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara <hseara@xxxxxxxxx> wrote: > Which information exactly do you need? I can provide you any > information you may require if you explain me how to gather it (I'm > not as good as most of you). As far as I can tell, the problem is as described below (i.e., this is not a bug), so no need to look for more info. However, if you disagree with my analysis and think there really is a bug somewhere then I would need to know what version of what package (probably udev or initscripts) made the problem worse. To figure this out you would have to downgrade the package you think it is, verify that one version works fine and that the next does not (without changing anything else on your system). > Regarding testing. I don't want to use testing in this computer as it > has some sensitive data. That's ok. The packages will move to [core] soon. > Regarding non mounting at boot it is rather not a good option. First, > I like my disks to be check up periodically, this is fairly well done > at boot. Second, This is a file server besides a desktop, so not > always kde/gnome... are in use. I really think it is redundant to have > to use another tool than fstab to mount disks only for the seek of > speeding up the boot process. Hopefully there should be some daemon out there that does not require a gui, and can work with fstab (I haven't used such a thing before, but I'm sure they exist). As mentioned below "systemd" certainly would fix this issue, but that is a rather intrusive change, as it replaces your whole init system. > I really don't see the point of speeding the things up if they make > everything else unstable. I honestly think that we are trying to build > a house starting from the roof. First stability and then if possible > speed. I agree in principle that stability comes before speed. In this case however, it was never stable in the first place. It just so happened that it worked for you. The way it works at boot is that we wait for all disk devices (and other devices) to be enumerated before we start fsck'ing and mounting (this is the call to "udevadm settle" you can see in rc.sysinit). However, settle will not wait for your usb devices to become read. This is why: The problem is that we do not know how many usb devices you have attached to your computer, so we don't know how many to wait for before continuing (this is not the case for other kinds of devices like pci). Furthermore, we don't know how long it will take to enumerate all usb devices. In other words there is never a point in time when we know that "all usb devices are ready". Obviously, the slower your boot, the more likely you are to be "lucky" and have all your usb devices ready when you need them. While I don't want to randomly slow down boot for everyone on the off-chance that it might make some usb devices work more often, there is a way you can do this yourself: You can make rc.sysinit wait an arbitrary amount of time after udev has settled (how long to wait you should figure out by experimentation, I would suggest adding a few seconds to what you think is needed to make room for future boot speedups). If you put the attached (untested) file in /etc/rc.d/functions.d/ it should do the trick (for more details how this works look at the commens in /etc/rc.d/functions), though you might wan to adjust the sleep time. Lastly: initscripts fundamentally relies on your system being statically configured with no devices coming and going. USB is fundamentally dynamic, in that there is no difference between having a devices plugged before boot, or plugging it after your machine is up (except for timing). This cannot work well together. The only way to make this reliable is to have a daemon that can deal (fsck and mount) devices appearing at arbitrary points in time. systemd (from community) should do this well, though it is a relatively new project, so maybe you don't want to put it on your production systems quite yet (it is standard in Fedora 15 though, so it can't be that bad).
Attachment:
wait_for_usb
Description: Binary data
