On Saturday, June 15, 2002, at 11:22 AM, Frederick Bruckman wrote:

> That's wierd, since mime/mailcap pretty much requires a suffix to do
> anything useful at all. In any case, I believe the preferred way is to
> simply include the patch in the body -- no mime attachments. I've
> never gotten complaints about that.

Tried that yesterday.  The file was to large and someplace along the way 
the mail got stopped.  This morning when I didn't see my message from 
last nite show up I just reposted with the changes attached as a file.  
I haven't bothered to figured out where the first mail message got 
stopped since I thought it was more important to try and get these 
changes out and tested for possible inclusion in 1.6.

> While I'm doing all that, let me ask you this: what happens if I have
> two or three ffs partitions, and two or there HFS partitions. Won't
> the second and third of each be "d" and "e" respectively, displaying
> two of the same in the menu? Then, of course, they won't match the
> kernel interpretation -- the kernel doesn't make that mistake -- and
> sysinstall will then newfs and try to mount the wrong partition. It
> certainly does that presently -- there's an open PR -- and I'm failing
> to see where you've addressed that problem in your patch.

The "d" partition isn't used by NetBSD for ffs parts since it is the 
RAW_PART on other ports.  The mac68k port uses "c" as the RAW_PART. I 
think this was a change that was made after 1.3 when the disksubr code 
was cleaned up and rewritten.  I seem to recall that "d" was usable in 
the mac68k port prior to that change.  Unfortunately the original code I 
wrote for sysinst was written and tested on a 1.3 system.  (There was a 
nasty disk bug in 1.4 that kept some systems from running at the time 
and mine was one of them.)

The "d" partition is used by NetBSD for an HFS part though.  The problem 
that you were probably seeing with multiple partitions showing up in 
multiple slots was because the kernel was merging the new on-disk label 
with the existing in-core label.  This didn't occur previously because 
the disksubr patch I submitted in 1999 wasn't committed.  Scott tipped 
me off to this problem since he was also seeing it on his systems.  I 
think I was able to reproduce it and solve it, but that's why I need 
others to test it to make sure.

So I think the problem you described is addressed, just not in the 
sysinst patches.  There is a patch to disksubr in there that must also 
be applied to the Kernel.  It zeros out the existing in-core label prior 
to reprocessing the on-disk Partition Map and creating a new in-core 
label.

You may notice there is a change in sysinst for what parts it assigns to 
different partitions. The "bsd_order" now excludes "d", and the 
"macos_order" includes "d".  I also added some comments to that section 
of code to help remind us in the future that changes in disksubr need to 
be matched with changes in sysinst.  I think that's what happened 
between 1.3 and now that caused the breakage.

You'll also notice that I left in the post-labeling checks that verify 
the new reprocessed on-disk label matches the expected in-core model.  
If it doesn't you'll get a display explaining the problem and sysinst 
will gracefully exit before zapping anything else on the disk.  At this 
point a reboot should have you up and running without a problem.

-bob