Prev: Cannot boot x4200 via dhcp (from another x4200)
Next: Solaris 10 tape drive permission issues...
From: Simon John on 5 Mar 2007 05:02
On 4 Mar, 22:09, Frank Cusack <fcusack(a)fcusack.com> wrote:

[snip]
> > i had been using root=0, but now i'm trying root=192.168.0.0/24
>
> both are wrong.
>
> You want anon=0 or root=(a)192.168.0.0/24 .

ah sorry, i had been using anon=0 (not root=0) then incorrectly
root=192.168.0.0/24, just tried root=(a)192.168.0.0/24 and still the
same result :-(

From: Tim Bradshaw on 5 Mar 2007 09:37
On Mar 5, 10:02 am, "Simon John" <simoninusa2...(a)yahoo.co.uk> wrote:
> On 4 Mar, 22:09, Frank Cusack <fcus...(a)fcusack.com> wrote:

> ah sorry, i had been using anon=0 (not root=0) then incorrectly
> root=192.168.0.0/24, just tried r...(a)192.168.0.0/24 and still the
> same result :-(

Well, if you are seeing *some* NFS traffic, then you know inetboot has
started and it talking NFS. If you are (now) completely sure that
your NFS options are correct and that the bootparams are completely
correct (in particular that they are pointing the thing at the right
NFS server etc), then the next thing to do would be to get some kind
of trace of the NFS traffic and see what the last thing it says is.
If you run snoop with the output to a file (snoop -o ...) of the
client on the NFS server machine, then you should capture everything
that is of interest (even better if this is the machine that answers
rarp/bootp, as you'll then see all that). Then you can use something
like ethereal (or snoop -i, if you can persuade it to report the UDP
NFS traffic correctly) to see what it was doing, and particularly what
it did towards the end. You should see it mounting the filesystem,
and then looking for & fetching the kernel etc.

One issue which probably is not affecting you but has bitten me in the
past is netmasks. In particular if you're using a `supernetted' (I
just made this term up, there probably is some proper one) network -
say a 162.168.0.0/16 or something (anything bigger than a /24) then
there can be some significant confusion causing things to mysteriously
go silent. I think I understood the problem once but have forgotten
the details. It was also in the Solaris 8 timeframe, so quite a long
time ago now.

I would look at NFS traces first.

--tim

From: Frank Cusack on 5 Mar 2007 11:55
On 5 Mar 2007 06:37:06 -0800 "Tim Bradshaw" <tfb+google(a)tfeb.org> wrote:
> One issue which probably is not affecting you but has bitten me in the
> past is netmasks. In particular if you're using a `supernetted' (I
> just made this term up, there probably is some proper one) network -

That is the correct term! :-)

> say a 162.168.0.0/16 or something (anything bigger than a /24) then
> there can be some significant confusion causing things to mysteriously
> go silent. I think I understood the problem once but have forgotten
> the details. It was also in the Solaris 8 timeframe, so quite a long
> time ago now.

If you are using a network with a non-natural netmask (eg 192.168 with
anything except /24, or 10.x.x.x with anything except /8) then you
will be unable to network boot *with rarpd/bootparams*. It will hang
after the initial kernel load and in snoop/tcpdmp you can see
bootparam traffic for the wrong netmask after the kernel loads. With
dhcp it works correctly at least on x86. I've never tried dhcp on
sparc but I assume it also works correctly.

Actually that's not quite true, non-natural netmask will work as long
as the host is in the "highest" netmask such that the broadcast address
for the incorrect, natural netmask is correct for the supernet/subnet.
eg if the host gets IP 192.168.1.4 in a 192.168.0.0/23 network, it will
broadcast as 192.168.1.255 (correct for 192.168.0.0/23) and things will
work if the bootparam server is in 192.168.1.x part of the supernet.
But if the host gets IP 192.168.0.4 it will broadcast 192.168.0.255 and
the jumpstart server will ignore it as that is a host address as far
as it is concerned (even though the traffic will be an ethernet level
broadcast, ie dst mac all 1's).

-frank
From: david on 5 Mar 2007 20:38
>
> I would look at NFS traces first.
>
> --tim

I would first force the NFS server to use NFS version 2 and if that
fails force it to use NFS version 3.

I hit a problem jumpstarting from a Linux host and it was resolved by
forcing the NFS version used.

David.

From: Tim Bradshaw on 6 Mar 2007 02:50
On 2007-03-06 01:38:29 +0000, "david(a)smooth1.co.uk" <david(a)smooth1.co.uk> said:

> I hit a problem jumpstarting from a Linux host and it was resolved by
> forcing the NFS version used.

I don't think the server is a Linux box here, but I agree if it is -
Linux's idea NFS implementation is, um, interesting.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Cannot boot x4200 via dhcp (from another x4200)
Next: Solaris 10 tape drive permission issues...