Re: newfs_msdos behaviour change between 4.x and 5?

On Tue, 20 Apr 2004, Geoff Buckingham wrote:

> On Tue, Apr 20, 2004 at 02:58:02PM +1000, Bruce Evans wrote:
> >
> > Summary: to create bootable and/or trustworthy file systems using
> > newfs_msdos under -current, you must now specify the correct -h, -u
> > and -o parameters on the command line.
> >
> Thanks, the works fine, allthough anoyingly I now realise my original scripting
> written early on in the 4.x life cycle had -h -u -o parameters, but i dropped
> them when i realised newfs_msdos worked them out for me and using the wrong
> values breaks things when you switch between devices with 32/63 sectors per
> track (Compaq/HP raid arrays/ nearley everything else)
>
> Zero seems a very poor choice of default value for the badly miss-named
> hidden sectors field, it is never going to be correct for any hd/flash media.

It was just apparently untested except on floppies.

> Short of doing the correct thing, taking the value of sectors per track should
> at least work for the first  partition on the disk (assuming the partition is
> in the correct place :-)

Further investigation showed that most of my booting problems were from
the test partition being to far from the beginning of the disk for old
versions of DOS to boot.  Running "sys" under DOS fixes up the fields
set by -h, -u and -o, and these are apparently only used for booting, so
the main broken cases are ones like yours where the boot block and DOS
itself are installed under FreeBSD.  It is very reasonable for the
bootstrap to expect the -h, -u and -o fields to be correct and for
whatever installs the bootstrap to write them, since they are part of
the bootstrap's data and not determining them dynamically helps fit
the bootstrap in 512 bytes.

The test partition was at offset 6.1GB on an old 6.4GB disk.  But 6.4GB
disks are new compared with DOS 4.01.  I think DOS 4.01 doesn't understand
disks larger than 2GB.  Its fdisk starts printing negative and truncated
(modulo 1 or 2G) values for partitions beyound 1 or 2GB.  I think DOS
6.22 is supposed to work up to 8GB, but it didn't seem to on my test
partition.  Its fdisk sort of understands partitions beyond 8GB -- it
reduces to the 8GB boundary instead of blindly truncating values modulo
the boundary.

The tests worked better on 1GB partition at offset 63 sectors.  I started
with the wrong geometry and offset given by GEOM and newfs_msdos:
H = 16, S = 63, O = 0.  Running "sys" under DOS 4.01 then fixed this up
to H = 255, S = 63, O = 63.  DOS 4.01 was then bootable.  Undoing some
of the fixups gave the following results starting from the fixed values:
- set O back to 0.  This broke booting.  I think the bootstrap is just
  using O to find where the partition is (and is is not using the partition
  table for this).
- set H to back to 16.  This was harmless.  I think this is because O is
  small, so all disk addresses for accesses done by bootstrap are decoded
  to the same CHS addresses for H = 16 and H = 255 (C is always 0, and the
  head number is always < 16 (H is the number of heads, not the head number).
- set S to 32.  This broke booting.  I think this is because O is not smaller
  than 32, so the relevant disk addresses now get misdecoded to CHS.

Bruce