[1785] in NetBSD-Development
Re: Disk partitioning problems
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 9 18:58:09 1998
Date: Wed, 9 Sep 1998 18:57:58 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
Cc: netbsd-dev@MIT.EDU
In-Reply-To: "[1784] in NetBSD-Development"
> The partition table Karl showed me on one affected machine had the
> NetBSD partition in the last slot, so the install script probably
> didn't make it (it would have chosen the first slot). It was
> presumably made by fdisk or disklabel or something else NetBSD, but
> I don't know what.
The partition table Karl showed me on an affected machine matched the
partition table written out by installboot when I (manually) created a
NetBSD partition starting at sector 0. So we know where it came from,
but it provides no information as to what created the overlapping
partition.
On a wd machine, I verified that the install does the right thing
starting from an invalid MBR and from an empty MBR. Repeating the
tests on an sd machine would be good.
On another note, back in [1720], Nathan wrote:
> There's still bugs with the install; [...] one that mistakenly lets
> newfs use default parameters on drives with weird geometries.
Yoav has an affected machine. The problem here is that the LBA values
for tracks/cylinder and sectors/cylinder are being used instead of the
values reported by the disk. This happens when a NetBSD partition is
created but not labeled (e.g. created using pfdisk). The signature of
this problem is a disklabel geometry which looks way too big, e.g.:
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 16383
for an 8GB disk. (If you lower tracks/cylinder to 16, you get a
reasonable product.) The cause of this geometry is a NetBSD
misfeature in the i386 disklabel generation routine: if it finds a
NetBSD partition on the disk (but no disklabel in that partition), it
modifies sectors/track and tracks/cylinder to match the ending values
of the partition, but doesn't modify the number of cylinders. At this
point, there is no way to get at the drive-reported geometry other
than through dmesg. I suggest we modify the install to attempt to get
the native disk geometry from dmesg.
