|Summary:||sys-apps/openrc: The root script does not work correctly if root or any filesystems it remounts are nfs|
|Product:||Gentoo Hosted Projects||Reporter:||Dennis Schridde <devurandom>|
|Component:||OpenRC||Assignee:||OpenRC Team <openrc>|
|Package list:||Runtime testing required:||---|
|Attachments:||patch for root init script (NFS /)|
Description Dennis Schridde 2012-07-25 08:42:17 UTC
If rootfs is nfs4, OpenRC needs to start rpc.idmapd as early as possible — especially before it does any writing on the filesystem. (See ) Currently it gets itself stuck: rootfs is mounted ro by the initrd, openrc cannot execute mount because that is suid and, due to the lack of idmapd, owned by -1, so it cannot remount the rootfs. After remounting the rootfs, it then seems to see the service dependency cache outdated and tries to regenerate, which is not possible on a ro rootfs… I think it should panic instead, because the dirs it needs to operate are not writable.  https://bugzilla.redhat.com/show_bug.cgi?id=537969#c18 Reproducible: Always
Comment 1 William Hubbs 2012-09-10 17:54:19 UTC
I am duping this to your original bug. If you disagree, please feel free to re-open. *** This bug has been marked as a duplicate of bug 427996 ***
Comment 2 William Hubbs 2012-09-12 00:42:36 UTC
This bug actually applies if any filesystem the root script attempts to remount is nfs or nfsv4, so I am generalizing it.
Comment 3 Dennis Schridde 2012-10-18 17:42:12 UTC
Since bug #427996 was fixed by requiring the user to use nfsmount instead of netmount, can this be fixed in a similar way? Is it possible to make root depend on nfsmount if / is nfs?
Comment 4 Panagiotis Christopoulos (RETIRED) 2013-03-16 22:19:31 UTC
Created attachment 342306 [details, diff] patch for root init script (NFS /) I had the same problem and fixed it with the cc'd patch. It seems that mount calls mount.nfs which can do "remount,rw" only without passing other options to -o . It also needs the absolute path of the remote directory (at least, that's how it worked for me). @William, this is a nasty hack, and I haven't tested it thoroughly. Didn't find time to check the code inside util-linux and nfs-utils for better alternatives yet.