Subject: Re: sysinstal isn't fun anymore
To: Frederick Bruckman <fb@enteract.com>
From: Bob Nestor <rnestor@augustmail.com>
List: port-mac68k
Date: 02/10/2001 19:58:34
Frederick Bruckman wrote:

>On Sat, 10 Feb 2001, Daniel Parks wrote:
>
>> At 3:45 PM -0600 2/10/2001, Bob Nestor wrote:
>> >
>> >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.
>
>If you _don't_ _reboot_, and you let sysinstall blindly "newfs" using
>the old partiton map, things get really ugly. Sysinstall should
>probably set a flag when it changes the partition table, and refuse to
>newfs when that flag is set, instead prompting for a reboot. Or does
>it do that already, now?

The old version of the sysinst code had this problem.  (Actually the old 
code running on a system that didn't have my kernel patches had the 
problem.  With my patch in the kernel the in-core map was forced to 
update with the on-disk information.  But the partition sizing wasn't 
always correct which was a different problem.  The installation kernels 
on the NetBSD Server for 1.4.2 and 1.4.3 don't have my patch, so they can 
corrupt the disk.  Even with my kernel patch installations didn't always 
work because of the sizing problem.)

The new version of the code that's in 1.5 has internal checks to make 
sure the in-core map matches what it wrote to disk.  If the two don't 
compare it refuses to continue.  If they do match, which they will if you 
don't partition with sysinst, then it allows the file loading process to 
continue.  So if you either partition your disk under MacOS or reboot 
after partitioning with sysinst, the rest of the installation should 
complete without a problem. The sizing code was also changed which should 
take care of the other problem some people saw and told me about. At 
least that was the plan. :)

I'm not saying there isn't a possibility of the 1.5 version of sysinst 
corrupting the HFS portion of the disk like the older version did, but I 
think that problem has been fixed.  If anyone has seen something 
different I'd like to know about it, especially if it's reproducable.

-bob