invalid disk label on updated current ultra60

[David Cornejo]

On Sat, Jan 3, 2009 at 10:40 AM, Marcel Moolenaar <xcllnt at mac.com> wrote:
>
> On Dec 31, 2008, at 11:47 AM, Marius Strobl wrote:
>
>> On Sun, Dec 28, 2008 at 09:28:49AM -1000, David Cornejo wrote:
>>>
>>> Hi,
>>>
>>> I've got an ultra60 that works fine with a kernel built Nov 22nd  and
>>> new kernels starting at least a couple of days ago claim that the
>>> disklabel on da0 & da1 are invalid and mounting root fails.  This is a
>>> fairly old system that was probably installed with 6 or 7 and upgraded
>>> to 8.  I haven't seen this problem on my x86/amd64 machines is there
>>> some incantation to make the disklabels valid?
>>>
>>
>> Apparently the problem are labels (originally) generated by
>> Solaris, which uses the native geometry reported by the
>> target rather than a synthetic one based on 255 heads and
>> 63 sectors as demonstrated by the following format(1M) output
>> for two identical disks, the first labeled with format(1M)
>> and the second with sunlabel(8) (after zeroing the previous
>> one):
>>      0. c1t0d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
>>         /pci at 1f,700000/scsi at 2/sd at 0,0
>>      1. c1t1d0 <FreeBSD68G cyl 8922 alt 2 hd 255 sec 63>
>>         /pci at 1f,700000/scsi at 2/sd at 1,0
>>
>> The 63 sectors limit of GEOM_PART_VTOC8 also causes problems
>> with IDE disks > 32GB where FreeBSD uses a synthetic geometry
>> based on 255 sectors like Solaris does in order to circumvent
>> the 16-bit cylinders, heads and sectors fields of the Sun and
>> VTOC8 disk labels. I think the upper limits for heads and
>> sectors therefore should be just removed from GEOM_PART_VTOC8,
>> which should also be safe, i.e. no upper bound needed, as done
>> by the below patch in order for their maximum value to be used.
>> Marcel, are you okay with this? Do you have a good idea how
>> to avoid the warning regarding geometry mismatch for labels
>> created by Solaris?
>
> I'm perfectly happy with it. The limits are mostly PC BIOS
> specific, though I kept them under the assumption that 1)
> they would hold for sparc64 and 2) we may make assumptions
> out the geometry in differenmt parts of the FreeBSD source
> base.
>
> It seems the limits simply don't hold, so it's better to
> remove them and deal with problems in other parts of the
> source tree if we encounter them.
>
> As for the warning: I made the geometry mismatch visible
> so that we can work the problem. If it's something that
> we cannot fix on sparc64 because Solaris uses the native
> geometry and we never do (for example), then we should
> just get rid of the warning and add a comment instead...
>
> FYI,
>
> --
> Marcel Moolenaar
> xcllnt at mac.com

The committed change solved my problem, many thanks!

dave c