>
>
> On 03/30/10 07:51 AM, Dave Miner wrote:
> > On 03/30/10 03:46 AM, Alexander Eremin wrote:
> >> Hi all,
> >> reflecting on the possible fix for 6260 (sparc AI
> need a way to
> >> mechanism to explicitly ask for creating label on
> Sparc disk), I
> >> encountered a problem - a liborchestrator in the
> Target Discovery
> >> process ignores non-labeled disk and
> disk_criteria_match function do
> >> not test this disk.
> >> ...
> >> <AI Mar 30 06:23:46> Initiating Target
> Discovery...
> >> <OM Mar 30 06:23:49> Ignoring c0t0d0 because of
> bad Geometry
> >> <AI Mar 30 06:23:53> Target Discovery finished
> successfully
> >> <AI Mar 30 06:23:53> testing disk c0t2d0
> >> <AI Mar 30 06:23:53> testing disk c0t3d0
> >> <AI Mar 30 06:23:53> testing disk c0t1d0
> >> <AI Mar 30 06:23:53> Searching for a disk target
> matching the following
> >> criteria
> >> <AI Mar 30 06:23:53> Disk name: c0t0d0
> >> <AI Mar 30 06:23:53> Disk c0t2d0 doesn't match
> desired name c0t0d0
> >> <AI Mar 30 06:23:53> Disk c0t3d0 doesn't match
> desired name c0t0d0
> >> <AI Mar 30 06:23:53> Disk c0t1d0 doesn't match
> desired name c0t0d0
> >> <AI Mar 30 06:23:53> No disk that matches all
> manifest criteria was
> >> found
> >> <AI Mar 30 06:23:53> Could not find a disk based
> on manifest criteria
> >> <AI Mar 30 06:23:53> ai target device not found
> >> ...
> >> As you see, c0t0d0 was removed from target
> searching.
> >> In this case, perhaps labeling the disk on early
> stage is needed, before
> >> Target Discovery.
> >> I'd like to know your opinion.
> >>
> >
> > I don't believe that labeling disks automatically
> during discovery is a
> > good idea, as there is no expectation that anything
> will be written to a
> > disk prior to initiating an installation. Seems
> like we should think
> > about how to get TD to not ignore the disk and make
> the apps capable of
> > dealing with the lack of geometry.
>
> I am not sure it is TD that ignores the disk, it may
> be libdiskmgt,
> which uses phygeom and ggeom to get the data. If
> there is no label, for
> sparc, ggeom won't return anything and libdiskmgt
> won't have values for
> the attributes. I would have to check to be sure what
> the behavior of
> libdiskmgt is in this case.
>
> sarah
> ****
> >
> > Dave
> > _______________________________________________
> > caiman-discuss mailing list
> > caiman-discuss at opensolaris.org
> >
> http://mail.opensolaris.org/mailman/listinfo/caiman-di
> scuss
> >
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-di
> scuss
>
So, this is here:
...
<TDDM_I Mar 30 15:21:41> Disk c0t0d0 device ID: id1,sd at n500000e0136e8da0
<TDDM_I Mar 30 15:21:41> Physical device path for disk c0t0d0: /pci at 780/pci
at 0/pci at 9/scsi at 0/sd at 0,0
<OM Mar 30 15:21:41> 2 Ignoring c0t0d0 because of bad Geometry
...
2 - this is my ankor, this is :
/*
* Calculate the size of 1 cylinder in blocks/sectors
* One sector = 512 bytes
* 1 cylinder = (number of sectors per track) * (number of heads)
*/
if (nvlist_lookup_uint32(attr_list,
TD_DISK_ATTR_NHEADS, &nheads) != OM_SUCCESS) {
dt->dinfo.disk_cyl_size = 0;
om_log_print("2 Ignoring %s because of bad Geometry\n",
dt->dinfo.disk_name);
goto end_return;
}
...
in target_discovery.c.
Cheers,
Alex
--
This message posted from opensolaris.org
