Hi Tom, thanks for the info. My computer is i686, so i cannot test the package. If you post later the i686 version I will be glad to test it. Hector On 17 May 2011 14:47, Tom Gundersen wrote:

Hi Hector,

On Tue, May 17, 2011 at 1:19 PM, Hector Martinez-Seara wrote:

...

After the last kernel update (I guess)  I cannot boot my system if a external usb disk is present in /etc/fstab. I use default fstab  mount options for the disks and they have each a single 1GB ext4 partition. Note that the disk mount okay when mounted from the command line after booting. Two identical disks has been tested with the same result so is not a hardware problem. The disks tested are two Western digital 1TB Essential Edition 2.0 (Model: wd10000h1u).

In fact this problem was happening very seldom before (1 every 100 reboots) due to to the waking up time of the devices but now it is every boot (only once worked). My question is: Has any thing changed regarding the usb at boot time lately in the kernel? In fact, I have notice a considerable speed up in the booting sequence up to the point where the file system checking is done. Maybe the changes to speed up the booting process have something to do with the problem I'm having?

In my case it looks like nothing is been asked to my external drives when checking the filesystems at boot. Just after, the system fails claiming that it has not found the disks. In the past (two days ago), some activity in ligths and spining up sound was present when the system was checking the filesystems, but now everything is quiet.

It is anybody else having the same problem?

In the meanwhile, as I do not use this disk for booting I have add the nofail option to the fstab for the two disks. Now obviously everything works but the drives are not mounted. Does anybody know the best place to add the mount commands for the drives so they are always accessible for the users after boot?

There is currently a problem with the latest udev in that it does not settle properly (i.e., it does not wait for dirvers to be loaded before continuing). This most noticeable affects people using usb drives or kernels without devtmpfs.

Please try: http://www.pps.jussieu.fr/~teg/udev-168-2-x86_64.pkg.tar.xz to see if the problem is solved for you, and report back at https://bugs.archlinux.org/task/24288. (assuming you are on x86_64, I'll do i686 tonight).

That said, there is a fundamental problem with usb drives, so we cannot reliably mount them at boot (it probably will work in practice though). The problem is that there is no way to know when all usb devices have been enumerated (even if the drivers are loaded), so we don't know how long to wait before trying to mount them.

This is the kind of problems solved by systemd (in community), and it is out of scope for the standard sysvinit initscripts (unless there is a solution that I am not aware of).

Cheers,

Tom

-- Hector Martínez-Seara Monné mail: hseara@gmail.com Tel: +34656271145 Tel: +358442709253

On Tue, May 17, 2011 at 2:35 PM, Hector Martinez-Seara wrote:

Hi Tom, thanks for the info. My computer is i686, so i cannot test the package. If you post later the i686 version I will be glad to test it.

Package: http://www.pps.jussieu.fr/~teg/udev-168-2-i686.pkg.tar.xz. If someone can confirm that this fixes the problem, then I'll push it to testing. Cheers, Tom

On Tue, May 17, 2011 at 5:42 PM, Hector Martinez-Seara wrote:

Hi, I can confirm that the new packages solves the problem with the usb disks at boot time. No other side effects observed.

Thanks for the feedback! Cheers, Tom

On Tue, May 17, 2011 at 02:14:03PM -0300, Victor Silva wrote:

I'm facing the same issue ,for the momment I just unplug the usb storage at boot. I'm running x86_64. Is there already a solution for x86_64 architecture? Regards, Victor Please don't top-post. An x86_64 package was linked here (see below). It's available in the AUR already.

On 17 May 2011 14:47, Tom Gundersen wrote:

Please try: http://www.pps.jussieu.fr/~teg/udev-168-2-x86_64.pkg.tar.xz to see if the problem is solved for you, and report back at https://bugs.archlinux.org/task/24288. (assuming you are on x86_64, I'll do i686 tonight).

-- -- Kwpolska (http://kwpolska.co.cc) stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16 | Arch Linux x86_64, zsh, mutt, vim.

Hi, 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). Regarding testing. I don't want to use testing in this computer as it has some sensitive data. 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. 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. Hector On 6 June 2011 13:13, Tom Gundersen wrote:

On Mon, Jun 6, 2011 at 10:37 AM, Hector Martinez-Seara wrote:

...

t 4 days I've been again experiencing problems with my usb disks at boot. Right now it is not as bad as before,  it fails around 75% of the boots which is still unacceptable. The problem was totally solved with udev-168-2. But at some point, currently  udev-171-1,  the problem was back. Sorry I can not be more precise as I don't boot the system every day. Has been any changes again in this respect?

We have been speeding up boot with the recent udev releases, so any race conditions will be more pronounced than before. There might of course be a bug in udev which is not just a race, but then I would need more info (like which exact version breaks for you, and maybe have a try with [testing], as there is lots of news stuff there).

As I said before:

"That said, there is a fundamental problem with usb drives, so we cannot reliably mount them at boot (it probably will work in practice though). The problem is that there is no way to know when all usb devices have been enumerated (even if the drivers are loaded), so we don't know how long to wait before trying to mount them.

This is the kind of problems solved by systemd (in community), and it is out of scope for the standard sysvinit initscripts (unless there is a solution that I am not aware of)."

Another option, if usb is not actually needed for booting (as in your case) is to have some software do automounting when the device appears (KDE/GNOME can do this, I'm sure there are others too, but I'm not too familiar with it).

HTH,

Tom

-- Hector Martínez-Seara Monné mail: hseara@gmail.com Tel: +34656271145 Tel: +358442709253

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 wrote:

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

Hi, The case is that we use usb external drives for storing data. It is likely not the most efficient way but is very very cheap. And yes they are plug 24/7. Anyway I will look for some post booting deamon that cant take care of them. Any idea anyone where to look for? Hector On 6 June 2011 15:58, Yaro Kasear wrote:

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 wrote:

...

On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara 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.

-- Hector Martínez-Seara Monné mail: hseara@gmail.com Tel: +34656271145 Tel: +358442709253

On Mon, Jun 6, 2011 at 10:26 AM, Javier Vasquez wrote:

On Mon, Jun 6, 2011 at 7:02 AM, Hector Martinez-Seara wrote:

...

Hi, The case is that we use usb external drives for storing data. It is likely not the most efficient way but is very very cheap. And yes they are plug 24/7. Anyway I will look for some post booting deamon that cant take care of them. Any idea anyone where to look for? Hector

Autofs is what I use, you can use the UUIDs to mount specific partitions at your will...

yeah systemd does all this for me now, but before that i used autofs *alot* ... not only for this sort of thing but also FUSE stuff like sshfs/etc. it works well, though the config syntax can get a bit daunting. you can even use a multi-map to create more autofs mounts on the fly, and ultimately have a whole tree of auto-cleaned mounts. ... eg: ---------------------------------------------------------------------------- /app/tree /port-scm/inst-sync -fstype=autofs,-browse :file:/none \ /port-scm/root-srv -fstype=autofs,-browse :file:/none \ /port-scm/root-sync -fstype=autofs,-browse :file:/none \ /port-scm/user-srv -fstype=autofs,-browse :file:/none \ /port-scm/user-sync -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-bin -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-dev -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-etc -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-lib -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-run -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-tmp -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-usr-share -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-var-cache -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-var-lib -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-var-log -fstype=autofs,-browse :file:/none \ /virt-mnt/inst-var-tmp -fstype=autofs,-browse :file:/none \ /virt-mnt/root-bin -fstype=autofs,-browse :file:/none \ /virt-mnt/root-dev -fstype=autofs,-browse :file:/none \ /virt-mnt/root-etc -fstype=autofs,-browse :file:/none \ /virt-mnt/root-lib -fstype=autofs,-browse :file:/none \ /virt-mnt/root-run -fstype=autofs,-browse :file:/none \ /virt-mnt/root-tmp -fstype=autofs,-browse :file:/none \ /virt-mnt/root-usr-share -fstype=autofs,-browse :file:/none \ /virt-mnt/root-var-cache -fstype=autofs,-browse :file:/none \ /virt-mnt/root-var-lib -fstype=autofs,-browse :file:/none \ /virt-mnt/root-var-log -fstype=autofs,-browse :file:/none \ /virt-mnt/root-var-tmp -fstype=autofs,-browse :file:/none \ /virt-mnt/user-bin -fstype=autofs,-browse :file:/none \ /virt-mnt/user-dev -fstype=autofs,-browse :file:/none \ /virt-mnt/user-etc -fstype=autofs,-browse :file:/none \ /virt-mnt/user-lib -fstype=autofs,-browse :file:/none \ /virt-mnt/user-run -fstype=autofs,-browse :file:/none \ /virt-mnt/user-tmp -fstype=autofs,-browse :file:/none \ /virt-mnt/user-usr-share -fstype=autofs,-browse :file:/none \ /virt-mnt/user-var-cache -fstype=autofs,-browse :file:/none \ /virt-mnt/user-var-lib -fstype=autofs,-browse :file:/none \ /virt-mnt/user-var-log -fstype=autofs,-browse :file:/none \ /virt-mnt/user-var-tmp -fstype=autofs,-browse :file:/none \ /virt-srv/core-misc -fstype=autofs,-browse :file:/none \ /virt-srv/node-misc -fstype=autofs,-browse :file:/none \ /virt-srv/user-misc -fstype=autofs,-browse :file:/none \ /virt-srv/util-misc -fstype=autofs,-browse :file:/none ---------------------------------------------------------------------------- ... i know thats a lot, but when someone accessed `/app/tree` for the first time that whole entire hierarchy would be mounted under it. autofs will auto-create/remove intermediate directories. other autofs *would* have been defined (all the `:file:/none` stuff) but i ended up moving to ayatemd exclusively because it %#$@-ing awesome and can do much much *much* more, in a clean and straightforward way. ... so you could always try installing/using that too :-) C Anthony

Thank you all for your suggestions, Hector On 6 June 2011 22:05, C Anthony Risinger wrote:

On Mon, Jun 6, 2011 at 2:00 PM, C Anthony Risinger wrote:

...

On Mon, Jun 6, 2011 at 10:26 AM, Javier Vasquez wrote:

...

On Mon, Jun 6, 2011 at 7:02 AM, Hector Martinez-Seara wrote:

...

Hi, The case is that we use usb external drives for storing data. It is likely not the most efficient way but is very very cheap. And yes they are plug 24/7. Anyway I will look for some post booting deamon that cant take care of them. Any idea anyone where to look for? Hector

Autofs is what I use, you can use the UUIDs to mount specific partitions at your will...

yeah systemd does all this for me now, but before that i used autofs *alot* ... not only for this sort of thing but also FUSE stuff like sshfs/etc.

it works well, though the config syntax can get a bit daunting.  you can even use a multi-map to create more autofs mounts on the fly, and ultimately have a whole tree of auto-cleaned mounts.

... eg:

---------------------------------------------------------------------------- /app/tree  /port-scm/inst-sync    -fstype=autofs,-browse    :file:/none \            /port-scm/root-srv    -fstype=autofs,-browse    :file:/none \            /port-scm/root-sync    -fstype=autofs,-browse    :file:/none \            /port-scm/user-srv    -fstype=autofs,-browse    :file:/none \            /port-scm/user-sync    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-bin    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-dev    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-etc    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-lib    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-run    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-tmp    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-usr-share    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-var-cache    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-var-lib    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-var-log    -fstype=autofs,-browse    :file:/none \            /virt-mnt/inst-var-tmp    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-bin    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-dev    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-etc    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-lib    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-run    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-tmp    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-usr-share    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-var-cache    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-var-lib    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-var-log    -fstype=autofs,-browse    :file:/none \            /virt-mnt/root-var-tmp    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-bin    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-dev    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-etc    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-lib    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-run    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-tmp    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-usr-share    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-var-cache    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-var-lib    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-var-log    -fstype=autofs,-browse    :file:/none \            /virt-mnt/user-var-tmp    -fstype=autofs,-browse    :file:/none \            /virt-srv/core-misc    -fstype=autofs,-browse    :file:/none \            /virt-srv/node-misc    -fstype=autofs,-browse    :file:/none \            /virt-srv/user-misc    -fstype=autofs,-browse    :file:/none \            /virt-srv/util-misc    -fstype=autofs,-browse    :file:/none ----------------------------------------------------------------------------

... i know thats a lot, but when someone accessed `/app/tree` for the first time that whole entire hierarchy would be mounted under it. autofs will auto-create/remove intermediate directories.  other autofs *would* have been defined (all the `:file:/none` stuff) but i ended up moving to ayatemd exclusively because it %#$@-ing awesome and can do much much *much* more, in a clean and straightforward way.

... so you could always try installing/using that too :-)

ERATTA

... and by `ayatemd` i of course meant systemd :-)

curse my resistance to actually type after 15 years of computer exposure!  i can't stand keyboards ... this is the future:

http://geekhack.org/showwiki.php?title=Island:10077

... except wireless, lightweight, and maybe even non-physical via Kinect-like technology ;-)

C Anthony

-- Hector Martínez-Seara Monné mail: hseara@gmail.com Tel: +34656271145 Tel: +358442709253

On Mon, Jun 6, 2011 at 11:39 AM, Mauro Santos wrote:

On 06-06-2011 13:58, Yaro Kasear wrote:

...

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.

What if you are booting from usb into a system with gui capabilities and all rescue/work/whatever tools you might need?

In this case, the fstab entries would look more like they would "normally", and less like they would for an external hardrive, the fstab on the machine you're booting from wouldn't be read at all.