Subject: Re: Mac OS Installer vs. sysinst
To: Frederick Bruckman <fredb@immanent.net>
From: Bob Nestor <rnestor@murphy.dyndns.org>
List: port-mac68k
Date: 05/25/2002 13:50:35
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