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 -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
