On Thursday, May 23, 2002, at 06:41 PM, Frederick Bruckman wrote:

> It is a lot faster, but the partition editor is broken and dangerous.
> I just found that if you use "part of the disk", it doesn't even show
> you HFS partitions (for "safety"), but then it goes ahead and
> overwrites them anyway! It would be safe for upgrades (no partition
> changes), except that the a.out to ELF transition goop is missing for
> mac68k. Also, no DHCP on mac68k.

I've done some further investigation on this problem and have managed to 
reproduce the error on my system.

First, the HFS partitions should always be shown, and as far as I know 
always have been.  The only partitions that aren't shown (for "safety") 
are the Driver and Patch partitions.  If these are deleted or modified 
the MacOS system may become unbootable off the volume being modified.  
Corrupting the SCSI Driver on the disk selected by the ROM during boot 
will cause a very serious problem and result in a "Death Chime" on 
bootup.  I did this once while working on Mkfs which is the reason I 
added those "safety" checks to sysinst.  Recovery from the problem 
wasn't easy.  However if one selects the "full disk" option this doesn't 
matter and a new Partition Map is created.  The user is warned that the 
volume may no longer be bootable under MacOS though.

The observed corruption doesn't appear to be in the Partition Map on 
disk so I'd have to say the partition editor isn't broken, although it 
may not work as intuitively as some may want.  After corrupting a disk 
with sysinst I verified that the new partition map still describes the 
corrupted HFS partition as it had prior to running sysinst.  The 
corruption in the HFS partition is in the data in the HFS partition 
itself, not in the Partition Map entry.  Unfortunately there is no place 
for the user to bailout of the installation between the time the Disk 
Partition Map is rewritten to the disk and when the new partitions are 
"newfs'd".

This corruption is most likely caused by an error in the way the new 
on-disk disklabel is being transferred to the in-core disklabel.  A fake 
on-disk disklabel is constructed by the kernel from the contents of the 
Apple Disk Partition Map when NetBSD is booted.  A small change in the 
kernel allows for this to be re-done on command from sysinst, which it 
does when the Apple Disk Partition Map is rewritten.  There used to be a 
sanity check in sysinst/mac68k to verify that the newly loaded disklabel 
matched what it had just written out.  If a mismatch was detected the 
installation was stopped before the new partitions were initialized.  At 
this point the user could reboot the system and the new Disk Partition 
Map would be correctly parsed and the installation could continue.  The 
purpose of this check was to insure that any NetBSD wouldn't write to 
non-NetBSD areas of the newly partitioned disk which was the primary 
cause of disk corruption in the first version of sysinst/mac68k on 
1.3.3.  If that code is still there then it needs to be improved to 
catch whatever this error is, and I'll look into doing that.

For what it's worth, the only code that was added to sysinst for the 
mac68k was the partition editor and menus specific to dealing with the 
Apple Disk Partition Map.  The rest of the code is MI code that is 
shared with all other ports which use sysinst.  (The code which writes 
out the bootstrap is disabled though since it isn't possible right now 
to boot directly from power-up into NetBSD without passing through 
MacOS.)  I don't think the MI portion of sysinst is at fault here 
though.  I suspect we still have some issues with the on-disk vs. the 
in-core disklabel.  There was a plan to unify disklabel handling with 
some new IOCTLs which would have eliminated the need for the kernel mod 
in the mac68k port, but that hasn't happened yet.

It might be prudent to disable the kernel mod which allows the disklabel 
to be reprocessed, or add some temporary code to sysinst/mac68k which 
prohibits going into the "newfs" step if the Disk Partition Map is 
updated.  This would still leave sysinst usable but would require the 
user to reboot whenever the Disk Partition Map was updated.

-bob