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). > -- Hector Martínez-Seara Monné mail: hseara@xxxxxxxxx Tel: +34656271145 Tel: +358442709253
