Subject: Re: should sysinst change MBR_PTYPE_386BSD to MBR_PTYPE_NETBSD?
To: <>
From: David Laight <>
List: tech-install
Date: 06/15/2003 22:08:37
On Sun, Jun 15, 2003 at 02:12:58PM -0400, William Allen Simpson wrote:
> On the question posed by the Subject, please don't change any type 
> automatically.

So will anyone complain if I completly kill that code?

> On a related question, please support the MBR_PTYPE and disklabel 
> formats from OpenBSD and FreeBSD.

That is a kernel issue not an install issue.

> Let's debate.
>  1) systinst is primarily for installing a "new" system. 

And probably by people who have never run netbsd before.

>  2) new systems will have new MBR numbers.

Or possibly a OpenBSD/FreeBSD install in another partition.

>  3) upgraders of old systems will be using the old-hand method 
>     (mentioned below), and compiling their kernels the old way, and 
>     thus can turn it on for the rare occasions it's needed.

Or they can edit the partition tabel by hand at some point in the
upgrade process.

> > > As long as there's an option to change the ID in sysinstall, it's
> > > not needed.
> > 
> > Not everyone uses sysinst to upgrade systems. I never do, for
> > example. I just unpack a new kernel, reboot, and then unpack the sets...
> > 
> Me Too.  I'm in favor eliminating the "upgrade" option from systinst, 
> and better documenting the steps for upgrading by hand.  Especially now 
> that the "new" etcupdate is available (that systinst never even solved).
> What does the "upgrade" option offer that would not be solved by 
> better documentation?

My rototiller has also just stalled at the part of sysinst I really
started off to change - the mbr editor.

sysinst seems to (try to) support 3 different installs:
1) clean install to a new (at least to netbsd) disk
2) upgrade of an existing system
3) overlay install of an existing system (ie the 'use existing layout')

These are all compounded by editing the mbr table prior to an overlay
install, and the possibility (there are some PRs about it) that the
kernel might have cached the original disklabel so it uses the existing
info instead of the new disklabel (that is written directly to disk).

The former is soluble (if tricky), the latter is much harder to sort out.
Especially if, for instance, the system is running from a 'miniroot'
copied into swap from tape (etc).

I actually wonder if sysinst should always do an 'upgrade' install?
In particular install /etc to (say) /etc.sysinst and run etcupdate
to populate /etc ?


David Laight: