steve%prd.co.uk@localhost (Steve Blinkhorn) writes:
> I have a mix of amd64 machines runnong 7.0 and 8.0_RC1 that I plan to
> move to 9.2. In particular, two of these are in remote secure data centres
> providing 24/7/365 services to clients. These two machines have a basic
> RAIDframe setup. The have performed flawlessly since I configured
> them back at base, over three years ago (and, BTW, they also have a
> smaller installation in non-RAID partitions on each of the two disks in
> case of emergency, and out-of-band network access).
>
> The trouble with machines performing flawlessly is that one loses
> familiarity with some system management procedures, and unfortunately
> the Installation Guide give little specific directive upgrade instruction.
There are actually a lot of ways to upgrade.
If you have a way, without your OS working, to:
- push the power button
- get at the console (see and type both)
- mount a cdrom
then this should be very safe. Even without cd it should be ok.
If you don't have any of that, it's scary but likely successful.
> Obviously I will start with one of my physically accessible machines,
> and I know not to install the /etc set. But are there gotchas I need
> to be aware of, particularly with the RAID setup? It's several years
> since I did a remote upgrade. I don't want to change anything at all
> that is specific to how I use these machines, just update the
> operating system and X11 on each of the boxes.
I think the best path is to use sysutils/etcmanage. That's because I
designed etcmanage to do what I think ought to happen, and a number of
people on my team at work wrote a lot of it.
Basically:
It has a script INSTALL-NetBSD to
- unpack and install a new kernel
- unpack and isntall a new userland (but not etc xetc)
- unpack etc xetc to /usr/netbsd-etc
- run the etcmanage script to merge /usr/netbsd-etc to /etc
The script etcmanage records hashes of files in /etc to denote that the
files are "automatically managed". The intended semantics is
If a file was installed from the OS and has not been changed, and
there is a new version of that file in the next OS release, update the
file. If the file has been removed from the OS release, delete it.
Very importantly, never modify or remove a file which is anything
other than a file which was installed from a release and which has not
been modified.
Yes, you need to hand-apply a few changes, but the point is that for the
vast majority of files, you don't need to think about it.
There is a bootstrapping issue, where you have to register files the
first time. This is done by unpacking the etc/xetc sets from what you
installed from, and running etcmanage --generate-manifest which is just
a file of pathname/hash pairs. Then you can on a running system run
etcmanage --import-manifest which will, if a path natches the hash,
record the path/hash pair in the db as automatically managed.
There is a script BUILD-NetBSD which is a thin wrapper around build.sh,
and then unpacks/generates the manifest and drops it into releasedir.
This is how I build, so I have the manifests around. But they are easy
to make by hand.
So to upgrade a system, I just go to the releasedir (copied to the
system) so that "amd64" is in $CWD, and
cp -p /netbsd /netbsd.ok
INSTALL-NetBSD installkernel
reboot (if I am switching branches)
INSTALL-NetBSD installuser
# which unpacks sets except etc to the system, and etc/xetc to
# /usr/netbsd-etc and then runs "etcmanage --update /usr/netbsd-etc"
postinstall -s /usr/netbsd-etc check
postinstall -s /usr/netbsd-etc fix
# perhaps hand-merge new lines in master.passwd/group
# run "etcmanage --update /usr/netbsd-etc" again and examine (diff)
# the files that it's talking about, and think about hand-merging.
or if not switching branches I just copy to netbsd.ok and do
"INSTALL-NetBSD install" and reboot. I do this every 2 months on many
systems, and thus am in condition to do it on an emergency basis if
there's a bad bug.
It will take you some hours to learn this and get it set up, but then it
will avoid a lot of work and avoid manual typing you might get wrong.
You probably should test-boot into the rescue install, and maybe update
that and then test-boot again. That will make sure that your new kernel
has drivers for everything that matters and it all works. I suggest
etcmanage in that rescue install too.
The other big issue could be boot blocks. You said 7, and if you
installed from 7, it's almost certain that the 7 bootcode can boot a 9
kernel. Generally compat has been quite good. I am paranoid because I
had a problem perhaps on sparc maybe 15 years ago when a machine
installed over 20 years ago needed new boot blocks to run newer NetBSD.
However, I like to keep boot blocks updated too, and this is scary on
machines you can't boot from rescure media. I feel like I'd make
mistakes, so I create a "/.installboot" that runs installboot with the
right args, and tells me if /boot needs updating (mismatch with
/usr/mdec/boot).
This is even harder to understand with raidframe as you want boot blocks
on both disks so it will boot if either is failed.
Beware if you do the clone at home thing that you match ffsv1/ffsv2 as
while that's not a big deal the script to write the boot blocks has to
match the root filesystem in v1/v2 ness.
Example script on regular PC:
#!/bin/sh
if ! cmp /usr/mdec/boot /boot; then
echo "TODO: update /boot"
fi
installboot -v /dev/rwd0a /usr/mdec/bootxx_ffsv2
and on apu2 (serial console):
installboot -v -o console=com0 -o speed=115200 /dev/rwd0a /usr/mdec/bootxx_ffsv1
But, I have no memory of *any* actual trouble on amd64 ever, or on any
version of NetBSD where the original install was 2005 or later.
Attachment:
signature.asc
Description: PGP signature