NFS mount problem since 017

NFS mount problem since 017

[Wim Muskee]

I have a chroot that get's mounted via NFS at boot time, after the
root mount, some scripts kick in (after Dracut) and mount some tmpfs
directories on the NFS mount.

The command I'm using is: dracut --force -m "nfs network base"
(hostonly is turned off)

This worked fine using dracut-014, however when using an image
generated by dracut-017, I get the following error when trying a mount
a dir on the NFS mounted chroot:

mount: only root can do that (effective UID is 4294967294)

Re: NFS mount problem since 017

[Karel Zak]

On Sun, Mar 18, 2012 at 10:25:44AM +0100, Wim Muskee wrote:
> I have a chroot that get's mounted via NFS at boot time, after the
> root mount, some scripts kick in (after Dracut) and mount some tmpfs
> directories on the NFS mount.
> 
> The command I'm using is: dracut --force -m "nfs network base"
> (hostonly is turned off)
> 
> This worked fine using dracut-014, however when using an image
> generated by dracut-017, I get the following error when trying a mount
> a dir on the NFS mounted chroot:
> 
> mount: only root can do that (effective UID is 4294967294)

 is it the new mount from  util-linux 2.21? Please, cut & past mount
 -V, it would be also nice to have the mount command line with all
 arguments.

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 http://karelzak.blogspot.com

Re: NFS mount problem since 017

[Wim Muskee]

>  is it the new mount from  util-linux 2.21? Please, cut & past mount
>  -V, it would be also nice to have the mount command line with all
>  arguments.
>
Nope, using util-linux-2.20.1-r2 on Gentoo
$ mount -V
mount from util-linux 2.20.1 (with libblkid support)

The full mount command is:
mount -t nfs -oro,nolock 192.168.0.1:/opt/ltsp-dev/i686 /sysroot

Re: NFS mount problem since 017

[Wim Muskee]

Harald also asked me on irc to check if rpc.idmapd was running.

I added a ps fax | grep idmap at the end of 95nfs/nfsroot-cleanup.sh
and saw no rpc.idmapd process.

Is that the correct way to check? I figured at the end of the cleanup,
it should be there.

Re: NFS mount problem since 017

[Harald Hoyer]

Am 27.03.2012 20:13, schrieb Wim Muskee:
> Harald also asked me on irc to check if rpc.idmapd was running.
> 
> I added a ps fax | grep idmap at the end of 95nfs/nfsroot-cleanup.sh
> and saw no rpc.idmapd process.
> 
> Is that the correct way to check? I figured at the end of the cleanup,
> it should be there.
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ah, we now kill rpc.idmapd. So before you do any action, you have to restart
rpc.idmapd in the real root.

Re: NFS mount problem since 017

[Wim Muskee]

On Thu, Mar 29, 2012 at 12:39 PM, Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Am 27.03.2012 20:13, schrieb Wim Muskee:
>
> Ah, we now kill rpc.idmapd. So before you do any action, you have to restart
> rpc.idmapd in the real root.

Any reason the rpc.idmapd is killed now?

Re: NFS mount problem since 017

[Harald Hoyer]

Am 29.03.2012 20:53, schrieb Wim Muskee:
> On Thu, Mar 29, 2012 at 12:39 PM, Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> Am 27.03.2012 20:13, schrieb Wim Muskee:
>>
>> Ah, we now kill rpc.idmapd. So before you do any action, you have to restart
>> rpc.idmapd in the real root.
> 
> Any reason the rpc.idmapd is killed now?
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

ok, just investigated: we kill rcp.idmapd since dracut 0.3.

must be another problem