Hi,

[ I'm moving this from source-changes to tech-install. ]

> I'm pretty sure that we are both wrong.  But I'll let you
> fix it for 1.3.3.  First, if I do an fdisk -i, I really think you 
> shouldn't second guess and decide if that's what I want to
> do.  (I've not had the chance to look at your change yet, but
> I don't see how it would change my opinion.)

I'm not doing any second guessing.  After my change, our fdisk is more or
less similar to what DOS fdisk does.  That is:

1. If fdisk doesn't write to the mbr due to some other option, the contents
of sector 0 are left alone.

2. If it doesn't find a valid mbr (i.e. the magic number in the last two
bytes of sector 0 are not 55 aa, the mbr is initialized with valid boot
code _and_ a zeroed out partition table.  This is almost what was done
before, except that the old code did initialize the last mbr partition
to span the whole disk except the first track.

3. fdisk -i initializes the code part of the mbr, but leaves the partition
table alone.  If you really want to zero out the partition table, you can
edit the individual partitions to have zero start/size.  In order to really
make a partition entry all zeros, currently you'd have to use interactive
mode (otherwise you get a start sector of 1), but I already have a fix
for that. That is, fdisk -i is equivalent to (the undocumented to my
best knowledge) fdisk/mbr.

> So what is really wrong.  Certainly, I goofed in my attempt to make
> sure that fdisk -i never happens again.  (You sort of get that
> way after you spend a day or two restoring your disk.)  You
> are right; you need to initialize an empty disk.  The problem is
> sysinst.  There are two flags, mbr_present and bstuffset.  It is 
> mbr_present that should be used to control fdisk -i.  At present,
> (1.3) mbr_present == 0, causes the geometry stuff to be called
> which then sets bstuffset.  At present, bstuffset controls the 
> fdisk -i.  The problem is that there other ways into the geometry
> code ... that sets bstuffset and ...

Hmm, I really think that fdisk -i shouldn't be done by sysinst.  The way
this is done now, seems perfectly valid to me.  And, since it's similar to
the way DOS does this for years, it probably conforms to the principle of
least surprise for people familiar with PCs.

As an aside, with the previous implementation of fdisk, the flag mbr_present
was never being set.  The fdisk code, when determining that the magic number
is wrong, would have initialized its incore partition table to have a
third partition that spans the whole disk except the first track and mark
this partition as NetBSD (165 in 1.3).  It then dumps out the values from
this incore table.  So the code that determines mbr_present = 0 will never
trigger, as it checks for all four partition types being zero.

> So I'll fix current (as indicated above) if there are no objections
> and you fix 1.3.3

I really think that the current code is correct.  IMHO it would be bad to
have two places with heuristics determining the presence/absence of a
valid boot sector.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800