On Monday, June 06, 2011 07:39:03 Hector Martinez-Seara wrote: > Thanks Tom for taking your time to answer, > I will follow your advises to try to stabilize my system. I will try > to downgrade my system also. If I see that this helps I will let you > know, just in case this is a bug an not a simple speeding problem. > Thanks again, > Hector > > On 6 June 2011 15:25, Tom Gundersen <teg@xxxxxxx> wrote: > > 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). There's no reason to ever, ever, put USB drives in the fstab. Look at the top of the fstab file, it reads "static file system information." Unless you're guaranteed to have your thumbdrive plugged into your computer 24/7 and never remove it, it doesn't really belong in there, use consolekit or whatever KDE SC or GNOME use. Use pmount, whatever. Otherwise you'll get problems like this one that you're having. I'm sure systemd could probably do this. But systemd is completely unnecessary if you just have things configured properly.
