I found that for NFS a workaround is to use the nfs option "bg".
This is consistent with the explanation Allan gave.
** Summary changed:
- mountall eats 100% cpu with nfs in fstab
+ mountall eats 100% cpu in fstab
--
mountall eats 100% cpu in fstab
https://bugs.launchpad.net/bugs/574044
You re
pbaco, thanks for the confirmation. I hope somebody on the mountall
project sees this bug soon.
As a workaround, try moving "nobootwait" to the end of your option list,
and removing "optional" entirely. If you only use one option that
mountall wants to strip and you put that option at the end, you
I have exactly the same problem here, as described by Allan.
(Config: fresh lucid amd64 install)
I added a line in my fstab to mount a portable USB hard disk (ext3) on a
specific dir when inserted:
UUID= /media/neo ext3
nobootwait,optional,user,rw,suid,dev,exec,auto,async,rel
I have figured out this bug. It has nothing to do with nfs. The
"mountall" program is entering an infinite loop in the "cut_options"
function because of a logic error in the string processing.
The cut_options function exists to strip mountall-only options
(showthrough, optional, bootwait, nobootwa
b.t.w. the second mountall -v hangs and eats 100% of another cpu core
too.
--
mountall eats 100% cpu with nfs in fstab
https://bugs.launchpad.net/bugs/574044
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ub
** Attachment added: "my fstab"
http://launchpadlibrarian.net/47378925/fstab
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/47374693/Dependencies.txt
** Attachment added: "ProcMaps.txt"
http://launchpadlibrarian.net/47374694/ProcMaps.txt
** Attachment added: "Pro
