As Chris G. Demetriou wrote...

> How long between the AUDIT_BOOT_STARTS and the FAIL?
> If it's not too much trouble to get you to change your firmware a
> couple more times, could you tcpdump that boot sequence with "tcpdump
> -vv"?
> 
 
OK, I went back to firmware V2.2:

>>> boot ez
INIT-S-CPU...
AUDIT_BOOT_STARTS ... 

  84 FAIL

>>> boot ez0
INIT-S-CPU...
AUDIT_BOOT_STARTS ... 

  84 FAIL

>>> boot ez0a
INIT-S-CPU...
AUDIT_BOOT_STARTS ... 

  84 FAIL

>>> show env
Volatile environment:
  AUTO_ACTION = HALT
  BOOT_DEV = BOOTP 1 5 0 0 0 2 JENS-IO 1 08-00-2B-36-86-0C
  BOOTDEF_DEV = EZ0A
  BOOTED_DEV = 
  BOOT_OSFLAGS = I
  LANGUAGE = 6
  TTY_DEV = 0
Non-Volatile environment:
  AUTO_ACTION = HALT (3)
  BOOTDEF_DEV = EZ0A
  BOOT_OSFLAGS = I
  KEYBOARD = US (0)
  OS_TYPE = OSF (3)
  SCSI_HOST_IDS = SCSI_A = 7 , SCSI_B = 7, SCSI_C = 7 , SCSI_D = 7

>>>

In summary what is on the wire is:

bash# tcpdump -vv
tcpdump: listening on de0
^C
0 packets received by filter
0 packets dropped by kernel
bash# 

When I do a BOOT ERA0 (so, MOP instead of BOOTP):

bash# tcpdump -vv
tcpdump: listening on de0
20:23:37.831044 snap 8:0:2b:60:1 8:0:2b:36:86:c > ab:0:0:1:0:0 sap aa ui/C
len=35
                         0200 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 00
20:23:37.832738 snap 8:0:2b:60:2 8:0:2b:36:86:c > ab:0:0:2:0:0 sap aa ui/C
len=35
                         0001 0003 0400 0002 0002 4100 0700 0608
                         002b 3686 0c64 0001 aa90 0101 0191 0102
                         ee05 00
20:23:39.856501 8:0:2b:36:86:c ab:0:0:1:0:0 mopdl 60: 
                         0600 08aa 0102 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000
20:23:41.880265 snap 8:0:2b:60:1 8:0:2b:36:86:c > ab:0:0:1:0:0 sap aa ui/C
len=35
                         0200 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 00

<< ad nauseam >>

And:

>>> boot era0
INIT-S-CPU...
AUDIT_BOOT_STARTS ... 
AUDIT_BOOT_REQ 

>>>

Note that the BOOT EZ0 aborts immediately, without even printing
AUDIT_BOOT_REQ.

Looks like a Jensen SRM bug to me..

$$$ Completely different question:

I tried doing a netboot from the Multia (same server as for the Jensen,
even same root/boot etc) and I get:

Boot: /netbsd I
disk0: error reading disk label
open error: 6
can't boot /netbsd

As a previous mail shows, the Jensen happily boots (with the old SRM
loaded) from the server

OK, it halts on the 'unsupport cpu' thingie, but that is normal.

HuH ??

Wilko
_     ______________________________________________________________________
 |   / o / /  _  Bulte  email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko
 |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
----------------  Support your local daemons: run [Free,Net]BSD Unix  --Yoda