rpc.statd fails on diskless Debian 3.0 install

Hi there,

I'm having some slight problems with a diskless install. Here are the
basics:

Client - Sun Sparcstation 5 remote booting from TFTP (TFTPBOOT.IMG file
from the Debian 3.0 CDs).

Server - Redhat 7.3 box running RARPD, TFTPD, NFSD etc.

The sparcstation gets the installation image from TFTP, and mounts the
debian-sparc-root over NFS okay. In the installation tips it mentions
that you have to enable NFS locking so that packages can be properly
installed. There are a few steps that are followed, ending in starting
portmap and rpc.statd.

Portmap appears to start ok, but starting rpc.statd looks like it fails
with the following error:

rpc.statd[166]: Version 1.0 Starting
rpc.statd[167]: unable to register (statd, 1, udp).

The only things I've found on the net have related to services not
running on the server, or not having r/w access to the root filesystem.
Nothing I've found so far has helped. I can provide more information if
necessary.

Any suggestions?

Cheers,
Oliver.

In comp.os.linux.help Oliver Hookins <(E-Mail Removed)> wrote:
> Hi there,

> I'm having some slight problems with a diskless install. Here are the
> basics:

> Client - Sun Sparcstation 5 remote booting from TFTP (TFTPBOOT.IMG file
> from the Debian 3.0 CDs).

> Server - Redhat 7.3 box running RARPD, TFTPD, NFSD etc.

> The sparcstation gets the installation image from TFTP, and mounts the
> debian-sparc-root over NFS okay. In the installation tips it mentions
> that you have to enable NFS locking so that packages can be properly
> installed. There are a few steps that are followed, ending in starting
> portmap and rpc.statd.

> Portmap appears to start ok, but starting rpc.statd looks like it fails
> with the following error:

> rpc.statd[166]: Version 1.0 Starting
> rpc.statd[167]: unable to register (statd, 1, udp).

Then portmap is not running. Check with rpcinfo -p localhost.

Or you've locked yourself out via hosts.deny. Check that.


Peter

Peter T. Breuer wrote:

> In comp.os.linux.help Oliver Hookins <(E-Mail Removed)> wrote:
>
>>Hi there,
>
>
>>I'm having some slight problems with a diskless install. Here are the
>>basics:
>
>
>>Client - Sun Sparcstation 5 remote booting from TFTP (TFTPBOOT.IMG file
>>from the Debian 3.0 CDs).
>
>
>>Server - Redhat 7.3 box running RARPD, TFTPD, NFSD etc.
>
>
>>The sparcstation gets the installation image from TFTP, and mounts the
>>debian-sparc-root over NFS okay. In the installation tips it mentions
>>that you have to enable NFS locking so that packages can be properly
>>installed. There are a few steps that are followed, ending in starting
>>portmap and rpc.statd.
>
>
>>Portmap appears to start ok, but starting rpc.statd looks like it fails
>>with the following error:
>
>
>>rpc.statd[166]: Version 1.0 Starting
>>rpc.statd[167]: unable to register (statd, 1, udp).
>
>
> Then portmap is not running. Check with rpcinfo -p localhost.
>
> Or you've locked yourself out via hosts.deny. Check that.

Portmap is running on both the server and on the client.

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 1024 status
100024 1 tcp 1024 status
100011 1 udp 624 rquotad
100011 2 udp 624 rquotad
100011 1 tcp 627 rquotad
100011 2 tcp 627 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1051 nlockmgr
100021 3 udp 1051 nlockmgr
100021 4 udp 1051 nlockmgr
100005 1 udp 1052 mountd
100005 1 tcp 4113 mountd
100005 2 udp 1052 mountd
100005 2 tcp 4113 mountd
100005 3 udp 1052 mountd
100005 3 tcp 4113 mountd

Hosts.deny is empty on the server, and I've added ALL: ALL to the
hosts.allow file (although I believe some of the man pages say it isn't
necessary).

Oliver.

In comp.os.linux.help Oliver Hookins <(E-Mail Removed)> wrote:
>>>Portmap appears to start ok, but starting rpc.statd looks like it fails
>>>with the following error:
>>
>>>rpc.statd[166]: Version 1.0 Starting
>>>rpc.statd[167]: unable to register (statd, 1, udp).
>>
>> Then portmap is not running. Check with rpcinfo -p localhost.
>> Or you've locked yourself out via hosts.deny. Check that.

> Portmap is running on both the server and on the client.

> program vers proto port
> 100000 2 tcp 111 portmapper
> 100000 2 udp 111 portmapper
> 100024 1 udp 1024 status
> 100024 1 tcp 1024 status

There you are! statd is running.

> Hosts.deny is empty on the server, and I've added ALL: ALL to the
> hosts.allow file (although I believe some of the man pages say it isn't
> necessary).

You have no problem to solve.

Peter

Peter T. Breuer wrote:

> In comp.os.linux.help Oliver Hookins <(E-Mail Removed)> wrote:
>
>>>>Portmap appears to start ok, but starting rpc.statd looks like it fails
>>>>with the following error:
>>>
>>>>rpc.statd[166]: Version 1.0 Starting
>>>>rpc.statd[167]: unable to register (statd, 1, udp).
>>>
>>>Then portmap is not running. Check with rpcinfo -p localhost.
>>>Or you've locked yourself out via hosts.deny. Check that.
>
>
>>Portmap is running on both the server and on the client.
>
>
>> program vers proto port
>> 100000 2 tcp 111 portmapper
>> 100000 2 udp 111 portmapper
>> 100024 1 udp 1024 status
>> 100024 1 tcp 1024 status
>
>
> There you are! statd is running.
>
>
>>Hosts.deny is empty on the server, and I've added ALL: ALL to the
>>hosts.allow file (although I believe some of the man pages say it isn't
>>necessary).
>
>
> You have no problem to solve.

Sorry. That was the output from the server only. On the client, I use ps
to check that portmap is running, which it is. rpc.statd still gives the
error message as above.

Oliver.

In comp.os.linux.networking Oliver Hookins <(E-Mail Removed)> wrote:
> Peter T. Breuer wrote:
>> In comp.os.linux.help Oliver Hookins <(E-Mail Removed)> wrote:
>>> program vers proto port
>>> 100000 2 tcp 111 portmapper
>>> 100000 2 udp 111 portmapper
>>> 100024 1 udp 1024 status
>>> 100024 1 tcp 1024 status
>>
>> There you are! statd is running.
>>
> Sorry. That was the output from the server only. On the client, I use ps

I don't understand what you mean. I don't know anything about a server
or a client from your description. I only know that you have a machine
on which statd won't run. The above output shows a machine on which
statd is running. Correct your experimental procedure.

> to check that portmap is running, which it is. rpc.statd still gives the
> error message as above.

So what! Why are you telling me? You should be running rpcinfo as I
asked you to! I really don't feel like playing games of 20 questions to
screw information out of you! Show the rpcinfo output and we will know.

Peter

Peter T. Breuer wrote:
> In comp.os.linux.networking Oliver Hookins <(E-Mail Removed)> wrote:
>
>>Peter T. Breuer wrote:
>>
>>Sorry. That was the output from the server only. On the client, I use ps
>
>
> I don't understand what you mean. I don't know anything about a server
> or a client from your description. I only know that you have a machine
> on which statd won't run. The above output shows a machine on which
> statd is running. Correct your experimental procedure.

I mentioned there was a server and a client in the first post. From
other posts I've read in various places I thought it might be a
pertinent point to mention the setup I am using.

In any case here is the output from ps which (I believe) shows portmap
is running:

PID Uid Stat Command
1 root S [swapper]
2 root S [kflushd]
3 root S [kupdate]
4 root S [kswapd]
5 root S [keventd]
6 root S init
49 root S /sbin/syslogd -m 0
55 root S /usr/bin/tail -f /proc/kmsg
56 root S /usr/bin/tail -f /var/log/messages
57 root S -sh
58 root S /sbin/dbootstrap
65 root S [rpciod]
91 daemon S sbin/portmap
95 root R ps

> So what! Why are you telling me? You should be running rpcinfo as I
> asked you to! I really don't feel like playing games of 20 questions to
> screw information out of you! Show the rpcinfo output and we will know.

Sorry; if I knew where the problem lies then I'd know exactly what
information to provide. Thanks for being patient. Here is the output
from 'rpcinfo -p', which obviously shows something is wrong:

rpcinfo: can't contact portmapper: RPC: Remote system error - No buffer
space available

Incidentally if I run rpc.statd in the foreground (i.e. not as a
daemon), it exits with the following error:

Cannot register service: RPC: Unable to send; errno = No buffer space
available

Regards,
Oliver.

In comp.os.linux.help Oliver Hookins <(E-Mail Removed)> wrote:
> In any case here is the output from ps which (I believe) shows portmap
> is running:

That's irrelevant at this stage. We need rpcinfo output.

> PID Uid Stat Command
> 1 root S [swapper]
> 2 root S [kflushd]
> 3 root S [kupdate]
> 4 root S [kswapd]
> 5 root S [keventd]
> 6 root S init
> 49 root S /sbin/syslogd -m 0
> 55 root S /usr/bin/tail -f /proc/kmsg
> 56 root S /usr/bin/tail -f /var/log/messages
> 57 root S -sh
> 58 root S /sbin/dbootstrap
> 65 root S [rpciod]
> 91 daemon S sbin/portmap
> 95 root R ps

> information to provide. Thanks for being patient. Here is the output
> from 'rpcinfo -p', which obviously shows something is wrong:

> rpcinfo: can't contact portmapper: RPC: Remote system error - No buffer
> space available

Well, please be very specific - it is "rpcinfo -p localhost". Try it
from a remote machine too.

So you''ll have to run portmap with debugging on and see what it
complains of. Oh .. no debugging switches. Well, strace it then, and
look for stuff in logs. It must be doing something. FIrst indication is
that your networking is funny, or else the binary is nuts. You did
say that hosts.deny was clean?


Peter

Peter T. Breuer wrote:
> Well, please be very specific - it is "rpcinfo -p localhost". Try it
> from a remote machine too.
>
> So you''ll have to run portmap with debugging on and see what it
> complains of. Oh .. no debugging switches. Well, strace it then, and
> look for stuff in logs. It must be doing something. FIrst indication is
> that your networking is funny, or else the binary is nuts. You did
> say that hosts.deny was clean?

Aha! I was running 'rpcinfo -p' exactly as written. 'rpcinfo -p
localhost' is failing saying localhost is unknown. Similarly 'rpcinfo -p
127.0.0.1' fails with a networking error.

Checking the output of 'ifconfig -a' seems to reveal that while the
local loopback interface is up, it does not have an IP address. I gave
it the address of 127.0.0.1 and tried to run rpc.statd again, and it
appears to start without failing! Hopefully that will be the end of my
issues.

Many thanks and best regards,
Oliver.

In comp.os.linux.networking Oliver Hookins <(E-Mail Removed)> wrote:
> Peter T. Breuer wrote:
> > Well, please be very specific - it is "rpcinfo -p localhost". Try it
> > from a remote machine too.
> >
> > So you'll have to run portmap with debugging on and see what it
> > complains of. Oh .. no debugging switches. Well, strace it then, and
> > look for stuff in logs. It must be doing something. FIrst indication is
> > that your networking is funny, or else the binary is nuts. You did
> > say that hosts.deny was clean?

> Aha! I was running 'rpcinfo -p' exactly as written. 'rpcinfo -p
> localhost' is failing saying localhost is unknown. Similarly 'rpcinfo -p
> 127.0.0.1' fails with a networking error.

So your networking has been stuffed till now! You must have been having
difficulties all over the place!

> Checking the output of 'ifconfig -a' seems to reveal that while the
> local loopback interface is up, it does not have an IP address. I gave
> it the address of 127.0.0.1 and tried to run rpc.statd again, and it
> appears to start without failing! Hopefully that will be the end of my
> issues.

Nope, not quite - you are missing a /etc/hosts entry for it too, by the
sound of it. Good luck!

Peter