invalid disk label on updated current ultra60
dcornejo at gmail.com
Tue Jan 6 21:09:42 UTC 2009
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:
>>> 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
>> 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
> 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...
> Marcel Moolenaar
> xcllnt at mac.com
The committed change solved my problem, many thanks!
More information about the freebsd-sparc64