1

After moving a Solaris 10 server to a new machine, the rpool disk is now c1t0d0. We have some third party applications hard coded for c0t0d0. How can I change the controller enumeration on this machine? There is no longer a c0.

I've tried rebuilding the /etc/path_to_inst, but the instance numbers don't seem to match up with the controller numbers. Also, it's not clear if i86pc platforms use this file.

I've tried devfsadm -C to clear the dangling links, but I'm not sure how to cause devfsadm to start numbering from 0 again (or force certain devices in the tree to a specific controller number).

Next I am going to try to create the symlinks manually in /dev/dsk and rdsk to point to the correct /devices.

I feel like I am going way off path here. Any suggestions?

Thanks

Update:

This is on virtual ESXi hardware with an additional pass-through HBA. There is no controller 0 on the machine, that is for sure. devfsadm -C cleans up all the c0 device symlinks but keeps the already linked controllers at their current ids.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
Jim
  • 11
  • 1
  • 3

2 Answers2

1

Seems strange to have an application care about the disk device name, but putting that aside, it sounds like there may still be another controller being discovered before the one where the rpool disk resides. Likely suspects would be onboard IDE or SATA ports, perhaps a CDROM device. CDROMs and other non-disk devices don't show up in 'format'.

i86pc platforms do use path_to_inst, but it's a list of hardware attached to specific driver instances, whereas "controller" is a generic identifier potentially covering multiple drivers. I'd look at the output of 'iostat -En' and see if it lists anything on c0. That might give you a hint. If there is something there, you may need to disable that port, otherwise it will continue to show up and occupy that controller number. Controllers are enumerated in a defined order and while there are bound to be differences among various PC BIOSes, my experience has been that onboard controllers are discovered before add-in controllers in PCI/PCI-X/PCIe slots.

You might also try a reconfigure boot: 'touch /reconfigure' and reboot.

eirescot
  • 574
  • 4
  • 8
  • Thank you for your suggestions. Ive tried iostat -En show the first controller as c1 I've tried devfsadm -C and touch /reconfigure and reboot, but this device is still enumerated as c1. There are no longer any symlinks for a c0 device in /dev/dsk however. I've read elsewhere that the reconfigure should generate a new /dev/path_to_inst but on my system, it is still missing. As mentioned, I can force this to be created but has no effect. – Jim Jun 25 '11 at 04:42
  • This is old, but hints at what I'm thinking: http://www.lbl.gov/ITSD/CIS/faqs/UNIX_Faq/9.html ; which is, that now that c0* links are gone, maybe removing the links for the existing controller will cause everything to be re-enumerated. Substitute the names of your bus architecture and controller drivers (mine would be pcieb and mpt_sas, for example). This method involves more than just path_to_inst and /dev symlinks, so it seems more... dangerous. ;) – eirescot Jun 26 '11 at 12:09
0

Physically move the disk to controller 0 and Solaris will update it accordinly (might have to reconfigure).

If you're going to create symlinks, beware that they could change in the future and devfsadm won't care about it.

gtirloni
  • 5,746
  • 3
  • 25
  • 52
  • There is no controller 0 to move to. devfsadm -C clears all the c0 dangling links but keeps all the existing controllers at their current number. – Jim Jun 25 '11 at 04:06