topic Re: tru64 bootdev problems in Operating System - Tru64 Unix

tru64 bootdev problems

victory_1 — Tue, 09 Aug 2005 01:00:40 GMT

P00 test>>>show boot*
boot_dev dkb100.1.0.3.0
boot_file
boot_osflags A
boot_reset ON
bootdef_dev dkb100.1.0.3.0
booted_dev
booted_file
booted_osflags
P00 test>>>sh dev
polling ncr0 (NCR 53C810) slot 1, bus 0 PCI, hose 1 SCSI Bus ID 7
dka500.5.0.1.1 DKA500 RRD45 1645
polling floppy0 (FLOPPY) PCEB - XBUS hose 0
dva0.0.0.1000.0 DVA0 RX23
polling isp0 (QLogic ISP10X0) slot 3, bus 0 PCI, hose 0 SCSI Bus ID 7
dkb100.1.0.3.0 DKB100 RZ29B 0016
dkb200.2.0.3.0 DKB200 RZ29B 0016
dkb300.3.0.3.0 DKB300 RZ29B 0016
dkb400.4.0.3.0 DKB400 RZ29B 0016
dkb500.5.0.3.0 DKB500 RZ29B 0016
dkb600.6.0.3.0 DKB600 RZ29B 0016
polling kgpsa0 (KGPSA-C) slot 5, bus 0 PCI, hose 0 kgpsaa0.0.0.5.0 - Nvram read failed.

kgpsaa0.0.0.5.0 PGA0 WWN 2000-0000-c92f-2950
polling tulip0 (DECchip 21140-AA) slot 3, bus 0 PCI, hose 1
ewa0.0.0.3.1 00-00-F8-04-F5-B9 FastFD (Full Duplex)
polling tulip1 (DECchip 21140-AA) slot 4, bus 0 PCI, hose 1
ewb0.0.0.4.1 00-00-F8-06-08-43 FastFD (Full Duplex)

This is the output of sh dev and show boot*

When I do a set ewa0_protocols bootp
it says nvironment variable ewa0_protocols created

Then I give show boot* and it should show me

boot_dev as ewa0 but it is not changing.

Anyway to change this to boot through ewa0.

Thanks

Re: tru64 bootdev problems

Venkatesh BL — Tue, 09 Aug 2005 03:05:35 GMT

Are you saying that you are not to use 'set boot_dev ewa0'?

What about '>>> b ewa0' does that do a network boot?

Re: tru64 bootdev problems

victory_1 — Tue, 09 Aug 2005 04:07:54 GMT

P00 test>>>show boot*
boot_dev dkb100.1.0.3.0
boot_file
boot_osflags A
boot_reset ON
bootdef_dev dkb100.1.0.3.0
booted_dev dkb100.1.0.3.0
booted_file
booted_osflags A

When I do set boot_dev ewa0 it gives me this
message:
P00 test>>>set boot_dev ewa0
boot_dev protected from attempted operation

Yes I am able to boot through network and i have attached the same in a txt file

Thanks

Re: tru64 bootdev problems

Ivan Ferreira — Tue, 09 Aug 2005 08:10:53 GMT

Post the output of

>> show ew*

Re: tru64 bootdev problems

Mark Poeschl_2 — Tue, 09 Aug 2005 10:06:18 GMT

What exactly are you trying to accomplish? If you want to change the default boot device to ewa0 use:

>>> set bootdef_dev ewa0

If you want to do a one-time boot from ewa0 use:

>>> boot ewa0 -fl

Why would you expect changing the 'ewa0_protocol' (Note: no 's' at the end) variable to have any effect on the 'boot*' variables?

Re: tru64 bootdev problems

victory_1 — Fri, 12 Aug 2005 03:34:49 GMT

I am configuring one machine as the RIS server and one more machine as client.

Here are also some inputs on the client from the prompt like sh device , show boot* .

After adding the client to the RIS server I go to the client and give at the # prompt

# shutdown â h now and it takes me to the >>> prompt

I do the following commands to boot from the network

>>> init

>>> set ewa0_protocols bootp

>>> boot ewa0

After I boot through ewa0 I get the errors which I have attached in the txt file bootlogtru-cd-dev2.txt

P00 tru-cd-dev2>>>sh device

polling ncr0 (NCR 53C810) slot 1, bus 0 PCI, hose 1 Ã¸ SCSI Bus ID 7

dka500.5.0.1.1 DKA500 RRD45 1645

polling floppy0 (FLOPPY) PCEB - XBUS hose 0

dva0.0.0.1000.0 DVA0 RX23

polling isp0 (QLogic ISP10X0) slot 3, bus 0 PCI, hose 0 SCSI Bus ID 7

dkb100.1.0.3.0 DKB100 RZ29B 0016

dkb200.2.0.3.0 DKB200 RZ29B 0016

dkb300.3.0.3.0 DKB300 RZ29B 0016

dkb400.4.0.3.0 DKB400 RZ29B 0016

dkb500.5.0.3.0 DKB500 RZ29B 0016

dkb600.6.0.3.0 DKB600 RZ29B 0016

polling kgpsa0 (KGPSA-C) slot 5, bus 0 PCI, hose 0 kgpsaa0.0.0.5.0 - Nvram read failed.

kgpsaa0.0.0.5.0 PGA0 WWN 2000-0000-c92f-2950

polling tulip0 (DECchip 21140-AA) slot 3, bus 0 PCI, hose 1

ewa0.0.0.3.1 00-00-F8-04-F5-B9 FastFD (Full Duplex)

polling tulip1 (DECchip 21140-AA) slot 4, bus 0 PCI, hose 1

ewb0.0.0.4.1 00-00-F8-06-08-43 FastFD (Full Duplex)

P00 tru-cd-dev2>>>sh boot*

boot_dev dkb100.1.0.3.0

boot_file

boot_osflags

boot_reset ON

bootdef_dev dkb100.1.0.3.0

booted_dev dkb100.1.0.3.0

booted_file

booted_osflags

Re: tru64 bootdev problems

Aaron Biver_2 — Fri, 12 Aug 2005 09:57:57 GMT

The point at which the boot is failing indicates a failure of the remote client to send a [second] bootp request to the host. This is to get datafiles necessary for the boot.

If you set the SRM variable boot_osflags to "ba" on the client, it should print a few more messages here that might indicate the source of the problem.

Also, I suggest you run the BOOTP server with debug flags. If you are using joind, try running i in foreground mode with debug flags, such as:

joind -d5 -f

(not sure about the debug level, so experiment)

Re: tru64 bootdev problems

Mark Poeschl_2 — Fri, 12 Aug 2005 14:44:56 GMT

Also, the correct variable name is "ewa0_protocol" not "ewa0_protocols"

That's why you're getting that "environment variable ewa0_protocols created" message.

Re: tru64 bootdev problems

victory_1 — Tue, 16 Aug 2005 03:26:30 GMT

Hello all

I have tried all options as replied to me.

But no luck. Well this is a simple thing I am trying but do not understand why it should be so difficult.Any ideas and commnents please
help

Regards

Re: tru64 bootdev problems

Aaron Biver_2 — Tue, 16 Aug 2005 09:37:38 GMT

Hi victory,

By the way, booting over the network is not a simple thing.

You said "no luck"...

...but the joind options I suggested were not given to resolve the problem, but to get additional information about the network activity. This is important because you are having a network problem - most likley in the configuration of the server software.

Would you please post the joind debug messages, if any, that occurred at the time the clinet tried to boot?

Re: tru64 bootdev problems

victory_1 — Fri, 19 Aug 2005 05:05:09 GMT

Hello all

This issue has been resolved , the problem was with the kernel and patches .

HP recommended to install

T64V51BB26AS0005-20050502 patch kit and also

put 51BPK5_genvmunix kernel.

Thanks

Re: tru64 bootdev problems

Venkatesh BL — Fri, 19 Aug 2005 05:22:34 GMT

Hmm...little strange. Not sure how an OS patch could solve a problem on the '>>>' prompt...anyways, all is well that ends well!