Frederick Bruckman  (fb@enteract.com) wrote:

>On Fri, 17 Dec 1999, Bob Nestor wrote:
> 
>> 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.
>
This is a new behaviour that I've not seen or heard about before.  It 
could be the result of some of the more recent changes that were made to 
the mac68k file installation lists.  I'll see if I can upgrade to a 
-current snapshot this weekend and try to update my patches and see if I 
can reproduce the problem.  If I do I'll resubmit the PR with the new 
patches.

>> 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.
>
True, but I think if you're going to do something like this you need to 
actually force the system into a reboot rather than ask the user to do 
it.  My reasoning here is if you ask the user to reboot and s/he doesn't, 
then you're working with the old disk partition layout rather thant he 
one that will be used on the next boot.  The user could go thru an entire 
installation that does nothing but toast the disk.  Also asking the user 
to reboot for the disk partition changes to take effect would then become 
additional mac68k folklore and five years from now you'd still have 
people telling new users to reboot halfway thru the installation process. 
 I've been down that road with some of the old Mkfs problems that were 
addressed years ago.

I really think rather than doing this you should consider either _NOT_ 
building and distributing an Installation Kernel with 1.4.2, or 
installing the one line kernel patch into your Installation Kernel.  Yes 
it would be better if the patch made it into 1.4.2 but as you say it 
probably won't.  SInce most people can't or won't build their own 
Installation Kernels (it's a pain), the lack of the patch won't be that 
must of an issue.  Also by having the Installation Kernel, if it's 
provided, operate as it should (without requiring a system reboot) would 
be much better for a new user.  It wouldn't look like a hack and give the 
mac68k port an undeserved reputation for being a hack.  However, if 
there's a new problem with /etc/disktab then maybe it's a moot point and 
the Instalation Kernel shouldn't be a part of the distribution in this 
release at all.

>> 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.
>
Some of the problems with sysinst don't happen all the time.  The 
networking issues still seem to be there.  Folks over on the macppc port 
are struggling with them and I've seen them during my macppc install.  
Knowing how to drop out of sysinst down to a command line and coax the 
ethernet up and then returning to sysinst did the trick for me, but I'm 
not sure that's easily documented for a new user to follow.  There are 
still a lot of nagging problems with sysinst across all ports that use 
it.  Just look at the PR list for Install.
 
>> 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.

Isn't everything in the gnu/ path covered by a GPL type license though?  
As I understand it building standalone binaries that can be invoked or 
loaded by a running system isn't a problem since only the code that goes 
into the binary being loaded needs to match the GPL license.  Moving that 
code into the kernel, even if it's an Installation Kernel, forces all the 
code in that image to be placed under a GPL license.  That would mean 
that even if we didn't put the code in an operational kernel we'd still 
be opening ourselves up to having to put the kernel under GPL license 
because the Installation Kernel would contain GPL code. I'm not a license 
weenie so I could be wrong, but that's the way it was explained to me.  
If this is the case we'll _NEVER_ get any of the current HFS code into 
either kernel.  We need a different solution, such as coming up with our 
own HFS code that can be included in either an Installation or 
Operational Kernel.

-bob