I don't have any silver bullets here but I have a couple of suggestions. My experience is on junk hardware with Solaris 10 at home and a variety of small to large sparc hardware running Solaris 9 or Solaris 10 at work.
First, drop into the BIOS setup menu and make sure all the SATA ports can be and are configured identically (I have a couple of really cheap boards which can only present two or even one SATA disk as an SATA device). Second, my experience is that cfgadm works slightly differently seemingly depending on time of day and phase of the moon (really, different server models and patch level variations). In this case, even though it says 'configured', try cfgadm -c configure sata0/2 cfgadm -c configure sata0/3 and/or cfgadm -c configure sata0/2::dsk/c1t2d0 cfgadm -c configure sata0/3::dsk/c1t3d0 and similar creative variations if those do not make everything be sane. On 09/03/10 10:57, Karel Gardas wrote:
I also need to add, that inbetween of unconfigure/disconnect/connect/configure cycle I've also added several invocations of devfsadm -C -- which might be perhaps the right reason I've lost the disk for sata0/3 which was presented before. I don't remember well, but the new drive which was identified well was IIRC sata0/3 and was assigned to dsk/c1t3d0 hence following the rule set by previous two disks: sata0/0::dsk/c1t0d0 sata0/1::dsk/c1t1d0 As I'm studying also the remaining snapshots of the root fs before todays attempt of disk attachements I see that /dev/dsk contained c1t3d0* files pointing to the right /devices file i.e. /p...@0,0/pci1043,2...@1f,2/d...@3,0. To my surprise all the files in /dev/dsk are already "pregenerated" from the time I installed whole machine (Jun 8-10 2009), so no new files were added dynamically by the devfsadmd. The second surprise here is that if there are c1t0d0*, c1t1d0* and finally c1t3d0* files for SATA drives 0, 1, 3 then I'm wondering why there are no c1t2d0* files for the "problematic" disc sata0/2, /p...@0,0/pci1043,2...@1f,2/d...@2,0 ? Also the idea now is what happens if I copy c1t3d0* from snapshot back to the /dev/dsk and /dev/rdsk and create manually c1t2d0* following the naming rules set by all the files in /dev/dsk and /dev/rdsk? Will Solaris complain or will it use the drive correctly? BTW: while reading all the stuff about device reconfiguration, /devices, /dev/dsk, devfsadm I've also found some stuff about /etc/path_to_inst and by it also stuff about `boot -a', i.e. `-a' kernel parameter on x64 machines. Do you think this might help to reconfigure whole stuff and finally enforce Solaris to recreate missing /dev/(r)dsk links pointing to the right disks for me? Any help with this issue is highly appreciated here, Karel
-- Jerry Sutton jer...@airmail.net _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
