Summary: | unable to remount nfs rootfs without rpc.statd running | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Stefan Kiesler <heavymetal> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | CONFIRMED --- | ||
Severity: | major | CC: | pacho, stefan |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Stefan Kiesler
2008-01-14 12:22:12 UTC
you need to set the nolock option on your rootfs in your /etc/fstab or in your kernel cmdline Setting nolock in /etc/fstab works fine. But is it a good idea to disable locking or may this lead to problems when multiple clients try to access the same files on a share? Does upstream care about this issue or is the only "real" solution a switch to NFSv4, which seems to perform locking on protocol level, without the need of extra programs running? i highly doubt they'll add locking to the protocol itself ... they split it off into a sep daemon on purpose NFS has always been silently doing no locking, you just never noticed until now where NFS userspace failed early on with an error ... i'm not suggesting that nolock is a fix, just something to get you going until we figure out how to get rpc.statd running early on ... this most likely will require baselayout-2 to get fixed properly though I thought i had read about that protocol merge somewhere, but maybe I just mixed something up. So am I getting the situation right? Locking works when rpc.statd is running, but doesn't work and never has worked for root nfs? Would it be possible to somehow "attach" locking to root nfs later or is there no way to get that running without an explicit remount of the affected (root) nfs? I'm sorry for those stupid questions, but most of the nfs documentation one can find on the internet is... weird. :-) you'd have to ask those questions on the nfs sourceforge mailing list ... i really dont know the answers ;) |