Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
Hi, for the last 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? Hector PD: I use the old thread so I don't have to explain again the problem which is below detailed. On 17 May 2011 14:19, Hector Martinez-Seara hse...@gmail.com wrote: Hi, 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: wd1h1u). 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? Thanks in advance, Hector -- Hector Martínez-Seara Monné mail: hse...@gmail.com Tel: +34656271145 Tel: +358442709253 -- Hector Martínez-Seara Monné mail: hse...@gmail.com Tel: +34656271145 Tel: +358442709253
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Mon, Jun 6, 2011 at 10:37 AM, Hector Martinez-Seara hse...@gmail.com 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
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
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 t...@jklm.no wrote: On Mon, Jun 6, 2011 at 10:37 AM, Hector Martinez-Seara hse...@gmail.com 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: hse...@gmail.com Tel: +34656271145 Tel: +358442709253
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara hse...@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). wait_for_usb Description: Binary data
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
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 t...@jklm.no wrote: On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara hse...@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: hse...@gmail.com Tel: +34656271145 Tel: +358442709253
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
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 t...@jklm.no wrote: On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara hse...@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). 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
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
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 y...@marupa.net 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 t...@jklm.no wrote: On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara hse...@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). There's no reason to ever, ever, put USB drives in the fstab. Look at the top of the
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Mon, Jun 6, 2011 at 7:02 AM, Hector Martinez-Seara hse...@gmail.com 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... Thanks, -- Javier.
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
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? -- Mauro Santos
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Mon, Jun 6, 2011 at 11:39 AM, Mauro Santos registo.maill...@gmail.comwrote: 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.
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Mon, Jun 6, 2011 at 10:26 AM, Javier Vasquez j.e.vasque...@gmail.com wrote: On Mon, Jun 6, 2011 at 7:02 AM, Hector Martinez-Seara hse...@gmail.com 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
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Mon, Jun 6, 2011 at 2:00 PM, C Anthony Risinger anth...@xtfx.me wrote: On Mon, Jun 6, 2011 at 10:26 AM, Javier Vasquez j.e.vasque...@gmail.com wrote: On Mon, Jun 6, 2011 at 7:02 AM, Hector Martinez-Seara hse...@gmail.com 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:
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
Thank you all for your suggestions, Hector On 6 June 2011 22:05, C Anthony Risinger anth...@xtfx.me wrote: On Mon, Jun 6, 2011 at 2:00 PM, C Anthony Risinger anth...@xtfx.me wrote: On Mon, Jun 6, 2011 at 10:26 AM, Javier Vasquez j.e.vasque...@gmail.com wrote: On Mon, Jun 6, 2011 at 7:02 AM, Hector Martinez-Seara hse...@gmail.com 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
[arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
Hi, 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: wd1h1u). 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? Thanks in advance, Hector -- Hector Martínez-Seara Monné mail: hse...@gmail.com Tel: +34656271145 Tel: +358442709253
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
Hi Hector, On Tue, May 17, 2011 at 1:19 PM, Hector Martinez-Seara hse...@gmail.com 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: wd1h1u). 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
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
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 t...@jklm.no wrote: Hi Hector, On Tue, May 17, 2011 at 1:19 PM, Hector Martinez-Seara hse...@gmail.com 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: wd1h1u). 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: hse...@gmail.com Tel: +34656271145 Tel: +358442709253
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Tue, May 17, 2011 at 2:35 PM, Hector Martinez-Seara hse...@gmail.com wrote: or 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. Ok. I ran out of diskspace, that's the reason for the delay, but building again now. Will let you know when it's up. Cheers, Tom
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Tue, May 17, 2011 at 2:35 PM, Hector Martinez-Seara hse...@gmail.com 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
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
Hi, I can confirm that the new packages solves the problem with the usb disks at boot time. No other side effects observed. Thanks a lot, Hector On 17 May 2011 16:14, Tom Gundersen t...@jklm.no wrote: On Tue, May 17, 2011 at 2:35 PM, Hector Martinez-Seara hse...@gmail.com 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 -- Hector Martínez-Seara Monné mail: hse...@gmail.com Tel: +34656271145 Tel: +358442709253
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Tue, May 17, 2011 at 5:42 PM, Hector Martinez-Seara hse...@gmail.com 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
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
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 2011/5/17 Tom Gundersen t...@jklm.no On Tue, May 17, 2011 at 5:42 PM, Hector Martinez-Seara hse...@gmail.com 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
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
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 t...@jklm.no 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. pgpn41h5aZYT9.pgp Description: PGP signature
Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab
On Tue, May 17, 2011 at 7:14 PM, Victor Silva vfbsi...@gmail.com 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? udev-168-2 is in testing for both architectures. Cheers, Tom
