Re: upgrade bits & pieces

[Alan Barrett <apb%cequrux.com@localhost>]

On Mon, 09 Mar 2009, Steve Blinkhorn wrote:
> 1. I just upgraded a machine in the next room from 2.0.2 to 4.0.1.
> First I copied all the install sets over, then I took a copy of the
> contents of pam.d from a 4.0 machine, then I unpacked a 4.0.1 kernel.
> I argued a lot with myself as to whether I should unpack base.tgz
> first or reboot, and decided to unpack base.tgz.   Mistake, I think -
> reboot wouldn't work because of a system call failure.   If I had
> rebooted first, would a later unpacking of base.tgz have worked?

In general, running a new userland with an old kernel is not expected to
work.  You must reboot with a new kernel before unpacking base.tgz.

> 2. There are mutterings in the installation guide (round about page
> 35) about upgrading involving replacing boot blocks.  Really?
> Necessrily?   If so, why is this machine working when all I have done
> in essence is to replace the kernel and the base software?

New kernel features sometimes depend on new bootblock features.  For
example, you can't boot a kernel that has "options MODULAR" using boot
blocks that don't understand modular kernels.  Going from NetBSD-2.x to
NetBSD-4.x without updating boot blocks will probably be fine, but it's
a good idea to update the boot blocks anyway.

> 3. Postinstall tells me that I have to set up some uids and gids
> manually. a) why cannot this be dome programmatically? b) does it
> matter what the numeric uids and gids are?   If it matters, or if
> there are preferred values, why no textual hint?

etcupdate provides a little more help with merging new content into your
passwd and group files.  There's no fundamental reason why postinstall
can't be better, but nobody has writen the code.

> 4. A bunch of stuff has to be manually "migrated" from
> /usr/X11R6/lib/X11 to /etc/X11.  Does "migrate" here mean move,
> copy, something else?  And what's the problem with a programmatic
> "migration"?

I don't know.

--apb (Alan Barrett)