setboot 11.31 and Agile addresses

[Mike Myers_5]

We have an odd problem here. Two systems with the same OS installed (B.11.31.0803, VSE version) on the same hardware (vPars in a Superdome nPar), built using the same ignite server and finish scripts show different behavior when running the setboot command.

On one server, when you run setboot as a "regular" user (eg. not root) it returns the DSF or Agile addresses for the boot devices. On the other server it says "No dsf found". Running it as root however DOES show the addresses:

$ setboot
Primary bootpath : 0/0/0/1/0.0.0 (No dsf found)
[...]
$ sudo setboot
Primary bootpath : 0/0/0/1/0.0x0.0x0 (/dev/rdisk/disk2036)

It also put this log out via syslog:

syslog: setboot: get_dsf_from_hw_path() failed : 0/0/0/1/0.0.0 is a legacy hw_path

Clearly this is a permissions problem...somewhere.

We've tusc/truss'ed the two commands on the two systems and there's not a clear error -- they seem to diverge shortly after doing some ioctl calls on /dev/config (IOCONF_HW_T_STR, IOCONF_HW_T_NODE and IOCONF_QUERY). The "working" one goes off to query all the disks on the system so it's trace is a lot longer. The other exits shortly after the point of divergence.

I've checked permissions on /dev/disk, /dev/rdisk, /dev/rdsk and /dev/dsk -- all the directories are readable and the files not on both systems.

I checked /etc/ioconfig and /stand/ioconfig -- both have the same cksum and are world readable.

Now, before anyone says "why the heck do you care?" I'll just say we're just starting to deploy 11.31 in this environment so if there's a problem in our deployment method I'd like to understand it and fix it before we get a bunch more systems.

Thanks in advance!

[Duncan Edmonstone]

Mike,

This might also be a vPars issue as setboot behaves differently in a vPars environment anyway... what version of vPars are you running? Can you also compare the legacy DSFs for the agile DSFs you boot off - are either of them on an ext_bus instance over 255?

HTH

Duncan

[Mike Myers_5]

The vPar software is the same release on both -- T1335CC, version A.05.03.

The ext_bus instance numbers for the boot devices are all 0.

One other difference is that the system that CAN see the translations in setboot is booted off SAN, the other is booted off local (SAS) disk.

Another thing I noticed just now is the subtle difference in format of the legacy device path names between root and non-root -- the last two components are rendered in hex when it works:

0/0/0/1/0.0.0 (No dsf found)
vs.
0/0/0/1/0.0x0.0x0 (/dev/rdisk/disk2036)