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

[Tom Gundersen]

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wait_for_usb
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20110606/bba36e40/attachment.obj>