Very Computer

I jumpstarted a E5500 yesterday and am puzzled about the controller number of the disk I
used.

From the 2.6 system, I selected from format:
1. c0t13d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>

to be the new disk, and specified c0t13d0 as the usedisk in the jumpstart profile.  

The jumpstart of Solaris 8 failed, indicating the disk did not exist.  Checking format after the
failure, the desired disk was under controller c2.
The c1 controller had the A3000 disk array, which normally are c2 and c3.

So I changed the jumpstart profile to:
usedisk                 c2t13d0
and it worked ok.

It appears that the boot server discovered devices in a different order.  This surprised
me but wasn't a show stopper.

What causes this and how can it be avoided, or predicted?

--

The "boot server" doesn't discover devices.  The client is the only one
that does.

The "problem" here is that it is considered bad for a device to change
it's number between reboots.  If numbering was done purely by looking at
hardware, then if you pulled a card, all the other devices might
change.  That would be "bad".

So instead, the first time a device is seen, it is given a unique number
(like c0 or c1).  That number is saved in a file (usually
/etc/path_to_inst and /dev/cfg on Solaris 8) and reused whenever the
machine boots.

The jumpstart client doesn't have the old configuration files, so the
numbering may not be identical.

For a given system, and a given set of devices, and no
/etc/path_to_inst, the numbering should always be the same, but it might
be difficult to determine what the numbering would be in advance.  It
would probably depend on the probe order for the particular machine you
were working with.

Clear as mud?
--

Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

That explanation helps.
Now I'm wondering what impact, if any, this will have on Veritas Volume Manager when I
import previously deported volumes, which now reside on different controllers.  
Likewise, will Raid Manager (rm6) complain about the changes.
Also, I'm assuming the new device names will remain constant as long as I don't add or
remove devices.  In other words, my boot device will now always be the new name.

--

None whatsoever (unless you're doing a *very* strange installation).

Veritas doesn't use the OS labelling scheme for understanding the
devices at all.

Instead at boot (or at 'vxdctl enable') it goes and probes all disks.
If it finds a disk with two slices that have tags 0x14 and 0x15, it
assumes it to be a VxVM sliced disk, and will attempt to read data from
the VxVM private region.  This data includes a "serial number" for each
disk.  The configuration is brought online using that number to find the
disks.

You can shut down a VxVM machine, rearrange all the disks, then reboot.
As long as the OS can see all the disks (might need a -r
reconfiguration), then VxVM will find the disks and bring them online.  

Quote:> Likewise, will Raid Manager (rm6) complain about the changes.

I don't know why.  I don't think RM keeps any sort of device database on
the host.  It should just find the RM devices.  You would be advised to
do a boot -r if you expected controller renumbering though.

Quote:> Also, I'm assuming the new device names will remain constant as long
> as I don't add or remove devices.  In other words, my boot device will
> now always be the new name.

"new" device names?  How would a new device be consistent with
something?  What are you trying to say here?  It is possible for the
onboard controller to be assigned a different number depending on how
the machine is booted.

"old" device names are consistent whether your add or remove any
others.  That's the point.  

System - one controller (boot)
c0 -> onboard.
    Add a controller in slot 3
c0-> onboard.
c1 -> slot 3
    Add a controller in slot 2
c0 -> onboard.
c1 -> slot3
c2 -> slot2
    Yank the slot3 controller
c0 -> onboard.
c2 -> slot2
    Put a different vendor controller in slot 3
c0 -> onboard.
c2 -> slot2
c3 -> slot3

--

Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >