Solaris 10u3 jumpstart fails with 38e00
in [Solaris]
|
Prev: Cannot boot x4200 via dhcp (from another x4200)
Next: Solaris 10 tape drive permission issues...
From: Bruce Porter on 3 Mar 2007 06:28 On Sun, 25 Feb 2007 17:00:40 -0800, simoninusa200 wrote: > On 25 Feb, 22:47, Bruce Porter <b...(a)ytc1NOARGEYSPAM.co.uk> wrote: > > [back-to-back] >> Yes, it would at least rule out the network/switch > > I'm going to try tha next, get a piece of crossover from work in the > morning. I couldn't get the first bit of Cat5 I tried to work at all, so > maybe my switch doesn't like the Netra, or the Netra is very fussy about > cables. > > [openboot] >> Good point :-) > > Bit of an oversight by Sun that - if you're having OBP issues, then you're > unlikely to have a working OS! > > [cd-rom] >> If it was like my laptop drive, I just had to remove an outer plastic >> case and the correct connectors were underneath > > I might have a tinker later then, is it just a standard IDE cable then? > IIRC, yes How did it go ? > [hp/redhat] >> Noooooooooooooooooooooo, a DVD drive would be cheaper :-) > > Yeah, if I can find one on ebay - I might have to buy another Netra just > to get the drive! As I say, cheap laptop drive should fit > > Have you any idea what the "size" bit means that seems to be where "net > boot -v install" hangs? > IIRC its the size of the miniroot delivered > Cheers ;-) -- Bruce "The internet is a huge and diverse community and not every one is friendly" http://www.ytc1.co.uk
From: Simon John on 3 Mar 2007 14:44 Nothing's making any difference here - crossover cable, I tried adding a domain name to everything, recreated the jumpstart, manually copied the inetboot from the DVD..... Any more ideas folks? I'm 99% convinced it's an NFS issue, as the size bit apparently is the size of the NFS install image, not what's come from tftp? if it's not that then maybe it's a problem with an x86 server and Sparc client....
From: Tim Bradshaw on 3 Mar 2007 16:15 On 2007-03-03 19:44:50 +0000, "Simon John" <simoninusa2001(a)yahoo.co.uk> said: > I'm 99% convinced it's an NFS issue, as the size bit apparently is the > size of the NFS install image, not what's come from tftp? the 38e00 is how big the second stage boot program is (inetboot). It will have another little batch of BOOTP stuff (with perhaps RARP before it) to find where it should mount things from, and it will then fetch the kernel from that, using NFS over UDP. After this it will hand control over to the kernel which will configure itself (loading yet more stuff using NFS over UDP at first) and then start to boot. I forget at which point you get a banner from the kernel. inetboot is depressingly silent I think. The PRINTER stuff you are seeing in snoop is a Solaris 10 snoop falsely reporting NFS over UDP traffic: this is a known bug (well, it's known to people who teach Solaris courses!). You need to make absolutely sure your NFS options are right on the server: in particular you *must* allow the client root access to the filesystem (it should only be read-only, but root on the client must be root on the server). For a solaris NFS server the options you want are ro,root=<client-list>: see http://docs.sun.com/app/docs/doc/816-5166/6mbb1kqfr?a=view say. Doing the initial NFS stuff can take some time, and if the server is a VMWare image it might take really quite a long time. If something is wrong then the thing will eventually give up. If you are seeing traffic then it is probably still doing stuff: how long did you wait? --tim
From: Simon John on 4 Mar 2007 15:53 On 3 Mar, 22:15, Tim Bradshaw <t...(a)tfeb.org> wrote: > the 38e00 is how big the second stage boot program is (inetboot). It > will have another little batch of BOOTP stuff (with perhaps RARP before > it) to find where it should mount things from, and it will then fetch > the kernel from that, using NFS over UDP. After this it will hand > control over to the kernel which will configure itself (loading yet > more stuff using NFS over UDP at first) and then start to boot. I > forget at which point you get a banner from the kernel. inetboot is > depressingly silent I think. yup, after the 38e00/size prompt i did see some rarp/biff traffic before the nfs. > You need to make absolutely sure your NFS options are right on the > server: in particular you *must* allow the client root access to the > filesystem (it should only be read-only, but root on the client must be > root on the server). For a solaris NFS server the options you want are > ro,root=<client-list>: seehttp://docs.sun.com/app/docs/doc/816-5166/6mbb1kqfr?a=viewsay. i had been using root=0, but now i'm trying root=192.168.0.0/24 > Doing the initial NFS stuff can take some time, and if the server is a > VMWare image it might take really quite a long time. If something is > wrong then the thing will eventually give up. If you are seeing > traffic then it is probably still doing stuff: how long did you wait? just tried it with the new setting and after 15mins there seemed to be no traffic and had to break #. into the lom as there was no display on the console either. i can still ping the netra, so i'm going to leave it for an hour or so, but i'm not hopeful as there's been no traffic for another 5mins whilst i've been typing this.
From: Frank Cusack on 4 Mar 2007 17:09
On 4 Mar 2007 12:53:40 -0800 "Simon John" <simoninusa2001(a)yahoo.co.uk> wrote: > On 3 Mar, 22:15, Tim Bradshaw <t...(a)tfeb.org> wrote: >> You need to make absolutely sure your NFS options are right on the >> server: in particular you *must* allow the client root access to the >> filesystem (it should only be read-only, but root on the client must be >> root on the server). For a solaris NFS server the options you want are >> ro,root=<client-list>: seehttp://docs.sun.com/app/docs/doc/816-5166/6mbb1kqfr?a=viewsay. > > 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 . -frank |