mountall issues with NFS root filesystem

Bug #537133 reported by Aron Griffis on 2010-03-11
152
This bug affects 28 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Medium
Unassigned
Lucid
Medium
Unassigned
Maverick
Medium
Unassigned
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned
Raring
Medium
Unassigned
nfs-utils (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned
Maverick
Undecided
Unassigned
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned
Raring
Undecided
Unassigned
portmap (Ubuntu)
Medium
Steve Langasek
Lucid
Medium
Steve Langasek
Maverick
Medium
Unassigned
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned
Raring
Medium
Steve Langasek

Bug Description

Binary package hint: mountall

I think I've found two bugs in mountall-2.7 related to nfsroots. This report describes both, since working around one exposes the other.

The first bug is a dependency issue, circular and otherwise. Unless the nfsroot is mounted with "nolock", NFS locking depends on rpc.statd, which depends on portmap, which depends on the "local-filesystems" event (in /etc/init/portmap.conf). mountall will never provide this event because it treats the rootfs as "local" even if it's networked, for the sake of daemons that need to wait for the rootfs to be remounted rw.

The problem is that portmap.conf needs access to /etc (ro), /var/run (rw) and /lib/init/rw (rw). A dependency on "local-filesystems" essentially means / and /tmp. Changing the dependency to "virtual-filesystems" would be more correct, but I'm not entirely certain that remounting / should depend on any general *-filesystems events.

It gets messier in statd.conf, which doesn't call out any filesystem dependencies, yet requires portmap to be running. It tries to directly "start portmap" which fails because the mentioned filesystems aren't writable yet. Portmap and statd will start successfully later, but not in time to satisfy the rootfs dependency.

The second bug is when one tries to work around the above problems by specifying "nolock" in /etc/fstab for the nfsroot. In this case we land in mountall.c at the bottom of run_mount() where the is_remote() test causes spawn() to be called with wait=FALSE. spawn() then calls nih_child_add_watch() which is supposed to eventually call back to spawn_child_handler(), but it appears to fail to connect:

 spawn: mount -n -a -t nfs -o remount,nolock 16.1.1.2:/export/romano /
 spawn: mount / [272]
 spawn: calling nih_child_add_watch for /
 init: job_process_handler: Ignored event 1 (0) for process 272

The third line is debugging I added. If spawn_child_handler() had been called, we would have seen an additional line:

 mount / [272] exited normally

I didn't dig into libnih to figure out why this isn't working. Rather I changed the test on which wait=FALSE depends, since it seems like mountall should be waiting for the rootfs. This works, see attached patch, though it only fixes the non-ideal "nolock" case.

ProblemType: Bug
Architecture: amd64
Date: Thu Mar 11 01:18:06 2010
DistroRelease: Ubuntu 10.04
Package: mountall 2.7
ProcEnviron:
 LC_COLLATE=C
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-15.22-generic
SourcePackage: mountall
Uname: Linux 2.6.32-15-generic x86_64

Aron Griffis (agriffis) wrote :
tags: added: patch
Changed in mountall (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium

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 needs to depend on *some* events - because something has to start portmap ;-)

summary: - mountall issues with nfsroots
+ mountall issues with NFS 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?

Steve Langasek (vorlon) on 2010-04-17
Changed in portmap (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Steve Langasek (vorlon) wrote :

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 Lucid):
assignee: nobody → Steve Langasek (vorlon)
Steve Langasek (vorlon) on 2010-04-17
Changed in portmap (Ubuntu Lucid):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

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 and mountall when the root filesystem is on NFS.
    LP: #537133
 -- Steve Langasek <email address hidden> Sat, 17 Apr 2010 01:43:55 +0000

Changed in portmap (Ubuntu Lucid):
status: Fix Committed → Fix Released
Aron Griffis (agriffis) wrote :

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).

It's pretty trivial to install a VM then convert it to a NFS root VM for testing. Would you mind doing that so you can see the problems for yourselves? I've already spent more energy than I budgeted tracking down the bugs described in this report. No offense intended, but if Ubuntu maintainers don't care about NFS roots, then I'm probably better off to switch to a different distribution at this point.

Thanks,
Aron

Ivica Vucemilo (vucemilo) wrote :

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

Jim Rees (rees) wrote :

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.

Philippe DUBRULLE (fredphil91) wrote :

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 process goes well until the end of the init file (in the initrd) and then I get a black screen with a blinking cursor...
I tried to add this line at the end of the init file (just before the run-init line) : panic "TEST" but I don't know what to test once I'm in busybox...

Did anyone find a solution ?

Jim Rees (rees) wrote :

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 configuring the same static IP in /etc/network/interfaces. The other thing I can think of is that I bound portmap to localhost, by uncommenting the OPTIONS line in /etc/default/portmap. I'm not sure whether any of this is necessary. I wasted so much time on this I didn't really feel like spending any more time figuring out what the exact bug is, especially since there seem to be multiple bugs.

Jim Rees (rees) wrote :

I should also add that I am not using the mountall patch. And I'm doing this on i386, not amd64.

rew (r-e-wolff) wrote :

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 is supposed to happen, I don't know. Adding the "nolock" to fstab was something I figured out on my own.

I wrote: remountroot.conf (with utterly too little knowledge to do this properly, but it works for me)

#
# hack by REW to remount the root
#
start on startup
description "remount root readwrite"

start on startup

task
exec mount -o remount,rw /

Jim Rees (rees) wrote :

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.

Sam Freed (sam-freed) wrote :

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 thing froze. Same friend suggested "mv /etc/init/network/* /tmp/TRASH", this means no-one will try to re-init my NICS while I am on an NFS root. It worked, I can login. What would be a more correct solution, I know not.

Over to you, oh gods of Ubuntu.

subscribe trentbuck@gmailcom
thank you

David Gnedt (lxp13) wrote :

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 finish faster than the remote mounts on the nih watch list, mountall should wait for the childs.

The attached patch fixes this race condition by checking the nih watch list before exiting the main loop.

For anyone who want to give it a try, I have uploaded a fixed package to my PPA. (It will need some hours until the packages are built.)

David Gnedt (lxp13) wrote :

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 bug currently prevents me from releasing a new version.

I don't really know what the problem is. Doesn't my contributed patch solve the problem in acceptable way?

Of course, I also want to provide some useful info with this comment too:
I think this bug only affects remote filesystems which are already mounted and are only going to be remounted. The problem seems to be that mounted filesystems are immediatelly marked as remounted before the mount process really exits.

Nikolaus Rath (nikratio) wrote :

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.

Looks like the patch is correct

Claus (linuxuser42) wrote :

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 also necessary.

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!

Björn Tillenius (bjornt) wrote :

using mountall 2.16~lxp1, as well as disabling statd and adding nolock to the mount options worked for me.

Tony Travis (ajtravis) wrote :

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.

Jim Rees (rees) wrote :

Does anyone know if the fix is in 10.10? Do you still have to disable statd?

Colin Watson (cjwatson) on 2010-11-29
Changed in mountall (Ubuntu Maverick):
status: New → Confirmed
importance: Undecided → Medium
Changed in portmap (Ubuntu Maverick):
status: New → Fix Released
importance: Undecided → Medium
Colin Watson (cjwatson) wrote :

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 process outstanding
 * try_mounts returns since newly_mounted is false and there's still a child watch
 * The remote mount fails, so the remote mount process exits non-zero
 * spawn_child_handler calls run_mount_finished with status != 0
 * run_mount_finished returns more or less immediately without doing anything that might set newly_mounted to true

As far as I can see, mountall will now be hung, which will hang the boot process. If you agree with this analysis, perhaps try_mounts needs to be adjusted to cope with this case?

David Gnedt (lxp13) wrote :

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 about the code finds the issue.

I am going to look into it again within the next days. Although I can't remember my partial analysis exactly, I think there has to be a sequence with a successful remote mount leading into a hung mountall.

David Gnedt (lxp13) wrote :

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 run_mount. also take a closer look on needs_remount and has_option)
* run_mount spawns a mount process for this remount with wait = FALSE, because is_remote tells that it is in fact a remote mount
* accordingly to the options spawn adds a child watch for the mount process and returns immediately
* try_mounts is continually executed by the mainloop (when all is mounted and nothing needs a remount try_mounts exits the mainloop)
* All mounts except the / remount finishes

Somehow magically the read-only flag used by need_remount changes before the mount process finishes. (I think this is caused by an udev event, which then may call update_mount, which then again may change opts)
As a result try_mounts thinks all mounts are done and simply exists, which then causes a blocked boot process, because the necessary events (local-filesystems, ...) weren't sent.

As you can see this seems to be a bug not only related to nfs mounts, more generally it is related to all remounts. I think it doesn't show up on local filesystems because remounts are much faster and therefore the risk is rather low to run into such a situation. In contrast remote filesystems (like nfs) require more time for remounting and also show up this bug.

I can think of the following possible ways to fix this:
* Also check in try_mounts if mount_pid > 0
* Spawn all remounts with wait = TRUE
* Set mounted to FALSE, when a remount is started - possible side effects?
* Maybe it is also possible to somehow change the behaviour of update_mount and needs_remount

I can provide my detailed system setup, mountall logs and patches for the various ways to fix this if you like.

I hope that a fix could be released soon ;)

Jim Rees (rees) wrote :

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.

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 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 undocumented.

ingo (ingo-steiner) wrote :

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 undocumented.

David Gnedt (lxp13) wrote :

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 nfsroot=10.10.10.254:/nfsroot ip=dhcp" kernel options and have no entry for / in my /etc/fstab.
If I add a "/dev/nfs / nfs defaults 0 1" line nothing changes.
If I add a "/dev/nfs / nfs defaults,ro 0 1" line mountall doesn't remount /, the bug isn't triggered and the boot process also continues normally. (I just discovered this simple workaround.)

David Gnedt (lxp13) wrote :

One thing I forgot to say: The nfs root is Ubuntu Lucid 10.04.1 LTS (using mountall 2.15.3)

Jim Rees (rees) wrote :

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 say anything about non-nfs options like rw.

David Gnedt (lxp13) wrote :

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)

Jim Rees (rees) wrote :

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 developer, but have nothing to do with nfsroot).

Bryce Harrington (bryce) wrote :

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 updated patch for proposed addition to mountall that incorporates both those patches and other changes in follow up comments deemed appropriate?

Bryce Harrington (bryce) wrote :

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
Elisiano Petrini (elisiano) wrote :

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 virtualize all the environment (server with 2 interfaces, and client).

Can anyone confirm that this has been seen also in 12.04?

Thanks, Elisiano

Steve Langasek (vorlon) wrote :

> 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.

Steve Langasek (vorlon) wrote :

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 things is not yet resolved. The statd job is still 'start on local-filesystems'. Can someone using NFS root confirm that changing this to 'virtual-filesystems' does the right thing on boot?

Changed in mountall (Ubuntu Precise):
status: New → Incomplete
Steve Langasek (vorlon) wrote :

(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):
status: New → Fix Released
Changed in portmap (Ubuntu Quantal):
status: New → Fix Released
Changed in mountall (Ubuntu Maverick):
status: Confirmed → Won't Fix
Steve Langasek (vorlon) wrote :

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 this all sorted for 14.04.

Ryan Tandy (rtandy) wrote :

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, but it still doesn't successfully remount /.

On all three releases, with 'rw' in the kernel command line, mountall spawns 'mount /', it returns immediately, and the system boots successfully.

On precise, with 'ro' in the kernel command line, I don't know for sure what happens as mountall hangs and never offers to drop to a shell. (Is there some way to get a rescue shell?)

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?) and /tmp waits forever for /. I do, however, get the offer to skip mounting or drop to a shell, so I'm able to recover the output from mountall. If I drop to a shell and run mountall, booting finishes successfully.

I don't see any difference between 'local-filesystems' and 'virtual-filesystems' in /etc/init/statd.conf, on any release.

I also don't see any difference from adding 'nolock' to the options in fstab, which I thought was supposed to make it work. Is there an extra step I'm missing? It's definitely visible in mountall's info about /.

Steve Langasek (vorlon) wrote :

On Tue, Sep 10, 2013 at 11:56:53PM -0000, 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 difference between 'local-filesystems' and 'virtual-
> filesystems' in /etc/init/statd.conf, on any release.

Ok.

At this point I probably need to be able to reproduce this locally to make
any further progress, or somebody needs to debug the upstart jobs
sufficiently on their side to show where things are getting stuck and why.
If someone has a simple recipe I could use to set up a saucy nfsroot for
testing, I can try to take a look; otherwise this will probably stall again.

Ryan Tandy (rtandy) wrote :

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" >> /srv/nfsroot/$RELEASE/etc/network/interfaces
chroot /srv/nfsroot/$RELEASE passwd root

# exporting the nfsroot from the server
echo "/srv/nfsroot/$RELEASE *(rw,no_subtree_check,no_root_squash)" >> /etc/exports
service nfs-kernel-server reload

For testing in a VM, you can set it up in virt-manager to do a direct kernel boot using the host's kernel and initramfs, and kernel args along the lines of "ro boot=nfs root=/dev/nfs nfsroot=<server IP>:/srv/nfsroot/$RELEASE".

I'm tarpman in #ubuntu-devel if you want to talk about this with lower latency, for example if I made some error above.

Steve Langasek (vorlon) wrote :

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 block the / mountpoint, gets us clear of the boot hang.

This is not a perfect fix because it means that anyone trying to do nfsroot over nfsv4 is out of luck; but it's strictly an improvement over the status quo, and it's been suggested that nfsroot doesn't actually work on nfsv4, so I'll go ahead with it for now.

Changed in mountall (Ubuntu Precise):
status: Incomplete → Triaged
Steve Langasek (vorlon) on 2013-09-11
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
Changed in mountall (Ubuntu Raring):
status: Incomplete → Fix Released
Changed in mountall (Ubuntu):
status: Incomplete → Fix Released
Changed in nfs-utils (Ubuntu Lucid):
status: New → Won't Fix
Changed in mountall (Ubuntu Lucid):
status: Confirmed → Won't Fix
Changed in nfs-utils (Ubuntu Maverick):
status: New → Won't Fix
Changed in nfs-utils (Ubuntu Precise):
status: New → Triaged
Steve Langasek (vorlon) on 2013-09-11
Changed in nfs-utils (Ubuntu Quantal):
status: New → Triaged
Changed in nfs-utils (Ubuntu Raring):
status: New → Triaged
Launchpad Janitor (janitor) wrote :

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 MOUNTPOINT=/ for the same reason. This isn't a
    perfect fix since idmapd would be needed if we ever wanted nfsv4
    nfsroot, but implementing that can wait until we have /usr mounting from
    the initramfs. LP: #537133.
 -- Steve Langasek <email address hidden> Wed, 11 Sep 2013 15:00:02 -0700

Changed in nfs-utils (Ubuntu):
status: New → Fix Released
Ryan Tandy (rtandy) wrote :

On Wed, Sep 11, 2013 at 2:57 PM, Steve Langasek
<email address hidden> 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 initramfs-tools uses that; cf. Debian bug #409271. Dracut does
appear to support root on nfsv4 (see dracut-cmdline(7)) but is not
currently installable in Ubuntu.

Rolf Leggewie (r0lf) wrote :

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
Rolf Leggewie (r0lf) wrote :

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
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers