Jumpstarting e3500

  • Follow


Hi,

I have a e3500 running Solaris 9 that I wish to upgrade to Solaris 10.
The boot/install server is Solaris 10 running under vmware on my desktop
machine.

I am having 3 problems.

The first is that the machine insists on running the POST and
autobooting, even though I have set diag-switch? and auto-boot? to false
in the OBP.


The second is when I boot from the network (using default hme
connection),  I get the following

{6} ok boot net
Boot device: /sbus@3,0/SUNW,hme@3,8c00000  File and args:
Using Onboard Transceiver - Link Up.
Timeout waiting for ARP/RARP packet
38e00
Server IP address: 192.168.10.196
Client IP address: 192.168.10.8
Using Onboard Transceiver - Link Up.

Requesting Internet address for 8:0:20:ad:51:f9
SunOS Release 5.10 Version Generic_118833-33 64-bit
Copyright 1983-2006 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
whoami: no domain name

panic[cpu6]/thread=180e000: mutex_enter: bad mutex, lp=600010630f0
owner=180e000 thread=180e000

000000000180b280 nfs:nfs_async_stop+c (600010630f0, 0, 80, 60001062f80,
40, 80)
  %l0-3: 0000060001062f80 0000000000000000 00000600010cbd70 00000000018ba184
  %l4-7: 000000000000000a 0000000000000000 0000000000000000 000003000016b800


And then the machine resets.


And, to the third problem,  I then tried to jumpstart via the ge
interface and i got the following

Rebooting with command: boot /sbus@2,0/network@1,100000
Boot device: /sbus@2,0/network@1,100000  File and args:
Auto-nego didn't complete! Check cable.
phy-status reg: 108
Retrying Network Init/Auto-negotiation.
Auto-nego didn't complete! Check cable.
phy-status reg: 108
Retrying Network Init/Auto-negotiation.
Auto-nego didn't complete! Check cable.
....
Link hasn't comeup yet.
etwork Link Setup Failed.
Please Check Cable and Try Again.
Can not transmit packet

Requesting Internet address for 8:0:20:ad:51:f9

and then hangs.



Any ideas anyone?

Al
0
Reply Al 5/25/2007 9:45:35 AM

Al Slater wrote:
> Hi,
> 
> I have a e3500 running Solaris 9 that I wish to upgrade to Solaris 10.
> The boot/install server is Solaris 10 running under vmware on my desktop
> machine.
>
> I am having 3 problems.

1 actually I think...

http://groups.google.com/group/comp.unix.solaris/browse_frm/thread/be4afa3bab682816/c87f8262f5f9bc8f?lnk=gst&q=jumpstart+vmware&rnum=1#c87f8262f5f9bc8f

0
Reply ISO 5/25/2007 10:11:02 AM


Thommy M. Malmstr�m wrote:
> Al Slater wrote:
>> Hi,
>>
>> I have a e3500 running Solaris 9 that I wish to upgrade to Solaris 10.
>> The boot/install server is Solaris 10 running under vmware on my desktop
>> machine.
>>
>> I am having 3 problems.
> 
> 1 actually I think...
> 
> http://groups.google.com/group/comp.unix.solaris/browse_frm/thread/be4afa3bab682816/c87f8262f5f9bc8f?lnk=gst&q=jumpstart+vmware&rnum=1#c87f8262f5f9bc8f

That link didn't seem to describe the same problem, but...

I realised that I hadn't installed the vmware tools, so I did that and
updated the interfaces to use the vmxnet driver, rebooted and now the
e4500 will boot as expected.

This still doesn't solve problem 1 though, which is bloody irritating,
or problem 3 (though that is now moot).

Al
0
Reply Al 5/25/2007 10:37:46 AM

Al Slater wrote:
> Thommy M. Malmstr�m wrote:
>> Al Slater wrote:
>>> Hi,
>>>
>>> I have a e3500 running Solaris 9 that I wish to upgrade to Solaris 10.
>>> The boot/install server is Solaris 10 running under vmware on my desktop
>>> machine.
>>>
>>> I am having 3 problems.
>> 1 actually I think...
>>
>> http://groups.google.com/group/comp.unix.solaris/browse_frm/thread/be4afa3bab682816/c87f8262f5f9bc8f?lnk=gst&q=jumpstart+vmware&rnum=1#c87f8262f5f9bc8f
> 
> That link didn't seem to describe the same problem, but...
> 
> I realised that I hadn't installed the vmware tools, so I did that and
> updated the interfaces to use the vmxnet driver, rebooted and now the
> e4500 will boot as expected.
> 
> This still doesn't solve problem 1 though, which is bloody irritating,
> or problem 3 (though that is now moot).

1) What position is your key in?
3) OBP patch???
0
Reply ISO 5/25/2007 10:59:33 AM

Al Slater <al.slater.xxx@xxx.scluk.com> wrote:
> This still doesn't solve problem 1 though, which is bloody irritating,

You say the OBP 'diag-switch?' setting is false, but what about the
physical key switch?  Is it in the 'on' or 'diag' position?

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >
0
Reply Darren 5/25/2007 4:21:37 PM

On 2007-05-25, Al Slater <al.slater.xxx@xxx.scluk.com> wrote:

> The first is that the machine insists on running the POST and
> autobooting, even though I have set diag-switch? and auto-boot? to false
> in the OBP.

Hi there. Let's take a look at the diag stuff.

You'll want to (I know, you've probably already done this)
setenv diag-level min
setenv diag-switch? false

and make sure your key is in either the ON or LOCKED position. Apart from 
that, however, the Exx00 machines take a fair time to post even with minimal 
diags and the general solution is to not reboot them too often ;)

Oh, and grab a recent OBP for your system. The newer OBP images will help deal 
with any boot process annoyances.


-- 
                | 
 /\ ._  _|.__   |
/--\| |(_||(/_  | email: andre  at  purplecow  dot  org
               
0
Reply Andre 5/28/2007 12:25:13 AM

Andre wrote:
> On 2007-05-25, Al Slater <al.slater.xxx@xxx.scluk.com> wrote:
> 
>> The first is that the machine insists on running the POST and
>> autobooting, even though I have set diag-switch? and auto-boot? to false
>> in the OBP.
> 
> Hi there. Let's take a look at the diag stuff.
> 
> You'll want to (I know, you've probably already done this)
> setenv diag-level min
> setenv diag-switch? false
> 
> and make sure your key is in either the ON or LOCKED position. Apart from 
> that, however, the Exx00 machines take a fair time to post even with minimal 
> diags and the general solution is to not reboot them too often ;)

Or rather, they take some time and do through testing so that you don't need to 
reboot them ever so often.
0
Reply ISO 5/28/2007 3:15:05 PM

6 Replies
174 Views

(page loaded in 0.075 seconds)


Reply: