[arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab

[Hector Martinez-Seara]

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 at jklm.no> wrote:
> On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara <hseara at gmail.com> 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 at gmail.com
Tel: +34656271145
Tel: +358442709253