At 3:45 PM -0600 2/10/2001, Bob Nestor wrote:
>Notice I didn't say it would always screw up.  If you do your own kernel
>builds on a system with a combined root&usr that is BSD 4.3 format you
>will probably end up with a problem sooner or later.  The inode number of
>the kernel will eventually be assigned to a value that the Booter can't
>get to and your system will be unbootable.  The simplest way to avoid
>this is to use a separate, small root partition, prefereably one that is
>BSD 4.2 format. But that's not easily done with Sysinst which always uses
>BSD 4.3 format.  The "newfs" part of Sysinst is in the machine
>independent portion of the code.

Well, I'll start cp'ing them instead of using mv. I haven't had any 
problems yet, but it's good to know. I always keep a working kernel 
around, so I'm not too worried about it.

>Really? The last time I checked the code wasn't there that would read and
>reprocess the Apple Disk Partition Map after it had been modified
>on-disk.  To get this done in the current setup is to reboot the system
>after the disk map is written to disk.  The only exception that I know of
>is the NetBSD 1.4.2 Installation Kernel I built with special kernel mods,
>and that kernel was never placed on the NetBSD Server.  It's only
>available from me.

I may have gotten the install kernel off your server. I don't 
remember. I did get the docs off your server.

>For 1.5 I re-wrote much of the disk
>partitioning code and put checks in to make sure the in-core map matched
>the on-disk map before allowing Sysinst to proceed.  The kernel mods I
>used in my 1.4.2 version aren't in the source tree and obviously aren't
>in the 1.5 version, so I'm not sure how you mananged to partition the
>disk sucessfully with it.  As far as I can tell all the 1.5 Installation
>kernels are built using the updated version of my code which was put in
>the source tree by Allen Briggs.

Well, it worked. :-) Don't know how. I do remember I did it twice, 
because I had problems trying to install on 2 HDs the first time. I 
partitioned the drive the first time, rebooted, then went ahead with 
the install. I don't remember if I partitioned the first time or not. 
I think I did, but if so, it was the same as the first.

>  >What needs to be done to insure that sysinst doesn't screw the
>>partition map up? (Or whatever it does that's bad.)
>
>Nothing.  To the best of my knowledge Sysinst doesn't screw up the
>partition map all by itself.  The problem is that once a new map is
>written to disk there's no way for the kernel to re-process the map and
>adjust it's in-core map which is used for all disk I/O in NetBSD.  There
>are plans to install a more robust label facility in the kernel in a
>machine independent way since mac68k isn't the only port with problems
>like this. When those changes are implemented they can be used in
>Sysinst/mac68k.  That should only be a minor modification.

Ah. That's all it is? I was under the impression that it actually did 
something terrible. To solve that, you just have to reboot.

>By the way, a similar problem apparantly exists in MacOS with the pdisk
>utility used by MkLinux.  If you read their source code and instructions
>they tell you to immediately re-boot the system after changing the
>on-disk Partition Map so MacOS has the proper view of the disk
>organization.

I've often wondered if a MacOS-based installer for MkLinux could be 
made using this "bug." First you format the drive HFS. Then you run 
pdisk+installer combo. The installer keeps track of the new 
partitions, and writes data to them as files (don't know if that's 
clear). You reboot, and you have a working MkLinux system.

It probably wouldn't work. It's OT, anyway.

Daniel