On Fri, 17 Dec 1999, Bob Nestor wrote:

> Let me see if I can explain. It's been a couple of months since I worked 
> on code, but I think I can get most of the explaination correct without 
> digging into the code.

Thanks for detailed response! You'd explained this to me before, but
I'm a little thick. :-)
 
> When I wrote the sysinst code to do the disk partitioning process I put 
> in code to directly read and update the ondisk Apple Disk Partition Map.  
> Sysinst (and your Installation Kernel in the 1.4.2-current snapshot) 
> should be able to do this, but since the kernel's copy of the disk label 
> is left unchanged it appears that  the disk partitioning process failed. 
> If the system is rebooted after this point in sysinst, one discovers that 
> the new partitions in fact do now exist.

Hmmm. Not this time. The error is always "Could not open /etc/disktab"
and the changes don't stick, even after a reboot. If there's an easy
fix to get the old behavior back, you can just tell the user to reboot
after making changes. I vid changes to mac68k sysinstall have a better
chance of making it into 1.4.2 than changes to the MI disklabel code,
at this point.

> The one remaining problem with sysinst seems to be an MI one.  There are 
> times that it gets confused about the updated disk label and confuses the 
> memory-disk with the physical disk. When this happens the newfs step 
> fails and thus the installation fails.

Demanding a reboot is crude, but it would address that, too.

> There are other problems with sysinst accessing NFS volumes, etc.
> These have been reported on a couple of other ports and there are
> PRs outstanding for them.

This might be fixed by now. NFS install worked for me on i386, at
least with the correct directory exported, or -alldirs.
 
> The other main problem facing us in the mac68k (and macppc) port is the 
> lack of a way to access HFS filesystems from the Installation Kernel.

Since last we talked about this, the softdeps code has been imported
into the gnu/sys directory. By that precedent, "libhfs" could be
imported into gnu/sys; it would never be used by the default, official
release kernels, but an option in the INSTALL kernel config could pull
it in. All sysinst has to do is check errno so it can bow out
gracefully, if necessary. I've added a mechanism (to current) to build
multiple install kernels using multiple, alternate kernel configs with
this scenario in mind.