>
>
> 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
>
TD has no problems with this EFI disk (c0t0d0), for example test_td output:
Disk discovery
Total number of disks: 4
----------------------------------------------------------------------------------------
num | name| vendor| ctype| mtype| rem| lbl| bsize|#of blocks|size [MB]|
volname|
----------------------------------------------------------------------------------------
1 |* c0t2d0| FUJITSU| scsi| FIXED| No| V| 512| 143374738| 70007|
- |
2 | c0t3d0| FUJITSU| scsi| FIXED| No| V| 512| 143374738| 70007|
- |
3 | c0t0d0| FUJITSU| scsi| FIXED| No| G| 512| 143374738| 70007|
- |
4 | c0t1d0| FUJITSU| scsi| FIXED| No| V| 512| 143374738| 70007|
- |
----------------------------------------------------------------------------------------
--
Alex
--
This message posted from opensolaris.org
