The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: nfs-utils (Ubuntu Precise)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
quantal has seen the end of its life and is no longer receiving any
updates. Marking the quantal task for this ticket as Won't Fix.
** Changed in: nfs-utils (Ubuntu Quantal)
Status: Triaged = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
raring has seen the end of its life and is no longer receiving any
updates. Marking the raring task for this ticket as Won't Fix.
** Changed in: nfs-utils (Ubuntu Raring)
Status: Triaged = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Branch linked: lp:~ubuntu-branches/ubuntu/saucy/nfs-utils/saucy-
proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/537133
Title:
mountall issues with NFS root filesystem
To manage
This is, in a nutshell, the setup I'm using for testing:
# installing a minimal chroot containing nfs-common
debootstrap --include=nfs-common $RELEASE /srv/nfsroot/$RELEASE
echo $RELEASE-nfsroot /srv/nfsroot/$RELEASE/etc/hostname
echo iface eth0 inet manual
On Tue, Sep 10, 2013 at 11:56:53PM -, Ryan Tandy wrote:
On quantal and raring, with 'ro' in the kernel command line, mountall
never spawns 'mount /' (although it does send the mounting event; I
suppose that's the part where it's waiting for statd?)
Right, that could be.
I don't see any
** Changed in: nfs-utils (Ubuntu Quantal)
Status: New = Triaged
** Changed in: nfs-utils (Ubuntu Raring)
Status: New = Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/537133
Thanks, that helped a lot. I was able to track this down to a
combination of statd (which I already suspected) and idmapd (which I
should have remembered from recent changes to the upstart jobs, but had
forgotten about).
Changing statd to start on virtual-filesystems, and changing idmapd to
not
This bug was fixed in the package nfs-utils - 1:1.2.8-2ubuntu2
---
nfs-utils (1:1.2.8-2ubuntu2) saucy; urgency=low
* Start statd on virtual-filesystems instead of on local-filesystems;
this works and avoids a deadlock in the nfsroot case. Also, adjust
idmapd to not block
** Branch linked: lp:ubuntu/nfs-utils
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/537133
Title:
mountall issues with NFS root filesystem
To manage notifications about this bug go to:
On Wed, Sep 11, 2013 at 2:57 PM, Steve Langasek
steve.langa...@canonical.com wrote:
and it's been suggested that nfsroot doesn't actually work on nfsv4
As the one who suggested that, I'll elaborate slightly: klibc's
nfsmount only supports nfs v2 and v3 (true in git as of this writing),
and
** Changed in: mountall (Ubuntu Quantal)
Status: Incomplete = Triaged
** Changed in: mountall (Ubuntu Precise)
Status: Triaged = Fix Released
** Changed in: mountall (Ubuntu Quantal)
Status: Triaged = Fix Released
** Also affects: nfs-utils (Ubuntu)
Importance: Undecided
I'm joining this discussion late (I'm not really affected as my diskless
clients are all ro+aufs), so please let me know what I'm doing wrong in
my testing and which other information I can provide.
The improvement in quantal and raring compared to precise is limited. It
doesn't hang any more,
Still waiting for feedback on whether this works in 12.10 and later
after running sudo sed -i -e's/local-filesystems/virtual-filesystems/'
/etc/init/statd.conf. Anyone using nfsroot who would be willing to test
this?
If that does fix it, I can upload the fix for statd to 13.10 so we can
have
Can anyone confirm whether this bug is still present in 12.10? I think
this may be addressed by the reworking or asynchronous mounting that was
done in mountal 2.42. If so, the mountall part of this bug should be
resolved once that change is backported (to 12.04).
I think the 'nolock' side of
(And by 'does the right thing', I mean lets the mount succeed without
having to set 'nolock')
** Changed in: mountall (Ubuntu Quantal)
Status: New = Incomplete
** Changed in: mountall (Ubuntu Raring)
Status: In Progress = Incomplete
** Changed in: portmap (Ubuntu Precise)
From what I read this should be fixed already, but I see this problem
even in the latest version (12.04).
I have a 64-bits server (12.04 LTS) and I'm trying to boot a diskless system as
a client (64-bit 12.04).
After init-bottom it just hangs there.
I notice the exact same behavior even when I
From what I read this should be fixed already,
Nothing in the bug status says that. This is an open bug against the
mountall package.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/537133
Title:
https://launchpadlibrarian.net/40758849/mountall.c.is_root.patch and
https://launchpadlibrarian.net/51866427/mountall_2.15_child-watch-list-
race-condition-fix.patch have been proposed as patches but subsequent
discussion indicates some further work on them is needed.
Could someone post an
Once that's done, please subscribe 'ubuntu-sponsors' to ensure the patch
gets uploaded to oneiric, and SRUs filed as appropriate.
** Changed in: mountall (Ubuntu)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I have analysed the problem again and found the following sequence of
events:
* root fs (nfs) is detected as local (see tag_mount)
* resulting in 1 local fs, a dozen of virtual fs and NO remote fs remaining
* / is going to be remounted, because it is already mounted, but read-only (see
Maybe I'm missing something here. What you have described is certainly a
bug and should be fixed. But why is the nfs root being mounted read-only
to begin with? An on-disk root is mounted read-only so that if it's
dirty fsck can clean it up. But that makes no sense for an nfs root.
--
mountall
Am 01.12.2010 21:23, schrieb Jim Rees:
But why is the nfs root being mounted read-only
to begin with? An on-disk root is mounted read-only so that if it's
dirty fsck can clean it up. But that makes no sense for an nfs root.
I once also filed a bug, because Ubuntu does not respect the digit
I once also filed a bug, because Ubuntu does not respect the digit in
column 6 of /etc/fstab. In Ubuntu you can set it to 0, but this is
ignored and fsck'd anyhow. The reply on this was: it has ever been that
way in Ubuntu, / filesystem is checked anyway. So this beheaviour is
Ubuntu-specific and
My NFS export is configured to only allow read access.
My /etc/exports on the server is:
/nfsroot 10.10.10.0/24(ro,no_root_squash,async)
I configured it that way because it is only a temporary system booted on
multiple computers at the same time.
I just use root=/dev/nfs
One thing I forgot to say: The nfs root is Ubuntu Lucid 10.04.1 LTS
(using mountall 2.15.3)
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
The fstab hack makes sense. I hadn't thought of that.
I wonder what would happen if you used
nfsroot=10.10.10.254:/nfsroot,rw as your kernel option, and rw in
fstab. Would the root then be initially mounted rw, and the remount
skipped? The doc says you can put nfs options after the comma, doesn't
Yes, that also works.
With nfsroot=10.10.10.254:/nfsroot,rw as kernel option it doesn't matter what
/etc/fstab contains. (works also without any / entry)
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a
That's a bit odd. I would expect if you had rw in your kernel options,
and ro in your fstab, that it would do the remount. But in any case I
think the kernel should mount the nfsroot rw unless you give ro in the
kernel options.
I'm going to bring this up on the nfs mailing list (I'm an nfs
** Also affects: mountall (Ubuntu Maverick)
Importance: Undecided
Status: New
** Also affects: portmap (Ubuntu Maverick)
Importance: Undecided
Status: New
** Changed in: mountall (Ubuntu Maverick)
Status: New = Confirmed
** Changed in: mountall (Ubuntu Maverick)
David Gnedt: Thanks for your patch! I had to think moderately hard
about whether nih_main_loop_exit always gets called eventually. I think
there is one case where it does not get called. Consider this sequence
of events:
* All filesystems but one get successfully mounted, with a remote mount
Thank you for this analysis. I am glad there is some activity for fixing
this bug.
I have tried myself to find the sequence of events resulting in a hung
mountall but couldn't find the exact cause within reasonable time, so I
wrote this simple workaround and hoped someone with more knowledge
Does anyone know if the fix is in 10.10? Do you still have to disable
statd?
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Thanks for your mountall patch David, I've been struggling with this
for the past two weeks!
I've now got a working 64-bit Ubuntu 10.04 LTS NFSROOT from a debootrap
with your help!
Tony.
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug
using mountall 2.16~lxp1, as well as disabling statd and adding nolock
to the mount options worked for me.
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Thank you David! Your ppa-package works on my systems (amd64). I hope
your patch will be integrated into the offical Ubuntu repositories very
soon!
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of
David Gnedt - your fix works! Thanx!
I tried your ppa mountall 386 package and together with the turn off statd in
/etc/default/nfs-common and nolock add to fstab root options, it seems to work
for me also (Also thanx to Jim Rees).
First I tried Jims suggestion alone but the mountall patch was
Looks like the patch is correct
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Hmm, it seems to me that nobody really cares about that bug.
I think it is a major bug that booting from NFS root filesystems doesn't work
with a nearly 3 month old LTS release.
I heavily depend on Ubuntu in my open-source cloning system called OpenClone
(http://openclone.nongnu.org/) and this
Sometimes it helps if you poke people on IRC or request sponsorship for
your patch (https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews). I
would very much like to see this fixed in Lucid as well.
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received
I think I have found the root cause of the remaining bug. The problem is
mountall adds remote mount childs to the nih watch list but it doesn't
wait until all childs exited properly. Therefore it also doesn't trigger
some events e.g. local-filesystems and filesystem in my case. If all
other mounts
I got a similar situation to Philippe DUBRULLE above net-booting an
arch= 386 old laptop diskless, from an AMD64 server, all Lucid.
The client freezes just after it is done with initrd. A friend suggested
pinging the machine continuously, and lo and behold I got 7 responses,
before the whole
FYI,
I used debootstrap to create a root for my new development machine. I
then spent two days trying to get it to boot. (all the howtos are
useless, as they tell me it works after setting up dhcp tftpboot etc.
The conclusion for me was that remounting the root rw solved my
problems. Where this
Another suggested fix, from Bug #548917, is to run mountall twice from
mountall.conf. Or I suspect you could put your remount in mountall.conf,
just before the exec mountall, since it's only the root that needs to
be remounted. I'll try this when I get a chance.
--
mountall issues with NFS root
Hi, I have benn trying (for two months now) to boot lucid with the root
partition mounted on NFS.
I tried to apply Aron's patch to mountall and put the nolock option in
/etc/fstab but lucid still doesn't boot.
I tried to apply Jim's idea (turnoff statd) but lucid still doesn't
boot.
The boot
I had to try a number of different things to get it going. It took
several hours. I don't entirely understand the way the host gets its IP
address. The kernel ipaddr=x.x.x.x option doesn't seem to work, it
always uses dhcp. I ended up using a dhcp server with a static IP for
the host, and also
I should also add that I am not using the mountall patch. And I'm doing
this on i386, not amd64.
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
I can confirm this is still broken with portmap 6.0.0-1ubuntu2
installed. My workaround is to turn off statd in /etc/default/nfs-common
and add nolock to the root options in fstab. Portmap still tries to
start and I get error messages but the boot eventually succeeds.
--
mountall issues with NFS
It takes about 10 minutes to debootstrap and configure minimal lucid for
pxe booting. I've tried it a dozen times and 2.6.32-21-generic just
won't boot. For now i am using karmic's kernel to boot into lucid.
Please don't wait 2 more months to apply Aron's patch.
Thanks in advance,
Ivica Vucemilo
Steve, Scott,
Thanks for looking at this bug and changing the portmap dep chain.
However this only fixes one of the problems mentioned in this report,
and NFS root clients are still broken. The mountall patch I provided
above is still necessary (and I'm not sure that's even the end of the
story).
Added a task for portmap; since that ships its configuration file and is
responsible for when portmap is started. Since portmap is only on the
root filesystem and only doesn't write to it, I think you're probably
correct that this should use virtual-filesystems
Obviously the root filesystem
I'd like to know why there was no SIGCHLD/wait() for the mount of the
root filesystem, are you sure that it wasn't still running?
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of Ubuntu
Bugs, which
I've verified that 'start on virtual-filesystems' should work just fine
for portmap. The post-start script only touches /var/run, which is also
covered by virtual (tmpfs). So no reason to wait for other filesystems
before starting up.
** Changed in: portmap (Ubuntu)
Importance: Undecided =
** Branch linked: lp:ubuntu/portmap
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
** Changed in: portmap (Ubuntu Lucid)
Status: Triaged = Fix Committed
--
mountall issues with NFS root filesystem
https://bugs.launchpad.net/bugs/537133
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
This bug was fixed in the package portmap - 6.0.0-1ubuntu2
---
portmap (6.0.0-1ubuntu2) lucid; urgency=low
* portmap should start on virtual-filesystems, not local-filesystems, since
it only ever writes to /var/run; this should break the circular dependency
between portmap
56 matches
Mail list logo
