If rootfs is nfs4, OpenRC needs to start rpc.idmapd as early as possible — especially before it does any writing on the filesystem. (See [1]) 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. [1] https://bugzilla.redhat.com/show_bug.cgi?id=537969#c18 Reproducible: Always
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 ***
This bug actually applies if any filesystem the root script attempts to remount is nfs or nfsv4, so I am generalizing it.
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?
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.
