Re: Upgrading from 10.0 to 10.1

[Havard Eidnes <he%NetBSD.org@localhost>]

> On Thu 16 Oct 2025 at 18:37:01 +0100, Liam Proven wrote:
>> I think as far as curious readers who are thinking of exploring NetBSD go,
>> then I am probably at the stage of telling people:
>> 
>> "Currently NetBSD is at a comparable level of sophistication to 9front:
>> upgrading means manually rebuilding your system, and you'll need a
>> considerable level of proficiency to even try. Until you acquire this, then
>> for now, the only easy way to upgrade to a new version of NetBSD is to
>> reinstall it."
>
> That would be a total misrepresentation.

Even without knowing 9front, I would agree.

> When doing minor (and even major) version upgrades, I reboot to
> the install media, choose to upgrade the existing system, let
> it extract all sets, and I'm back on IRC in about 15 minutes.

When I'm doing NetBSD upgrades, I'm using what I find to be an
even simpler method causing even less "service downtime". I think
this works for 8 -> 9, 9 -> 10 and 10 to 11.0_BETA; at least on
mainstream platforms, if I recall correctly, there hasn't been a
need to mess with the boot code for these upgrades.

1) Fetch the new binary sets for the version you want to upgrade
   to.  (Not to /tmp, as the startup after #4 below will in
   effect remove those files, if they weren't already gone due to
   it being a "tmpfs".)

2) Rename the old kernel as /netbsd.old (for use in case a
   rollback would be needed)

3) Extract and install the new kernel as /netbsd.

4) Reboot the system.  

At that point you'll be running the new kernel with an old
user-land, but that mostly works fine due to "compatibility with
the previous version" being enabled in the kernel config.

5) Extract the new sets on top of what's running:

   # cd /
   # for s in $(install-sets-except-etc.tgz-or-etc.tar.xz); do
   > progress -f $s tar xzfpB -
   > done
   #

6) Run the etcupdate script:

   # etcupdate -s etc.tgz # or whatever path and suffix it has

   Config files which are locally modified needs either to be
   skipped or merged.  This includes among other files
   /etc/master.passwd, /etc/group and /etc/rc.conf which
   etcupdate will provide an option to overwrite / replace; doing
   so to an already configured system would be bad.

7) If you've done a major version upgrade, the packages may need
   to be upgraded.

   a) modify /usr/pkg/etc/pkgin/repositories.conf
   b) run "pkgin upgrade" followed by "pkgin fug" (shorthand for
      "full-upgrade").

   Also, follow any additional instructions provided.
   This presumes you already have pkgin in use and installed.

8) Do a second reboot, to make sure you run the correct version.
   For example, I've had "cron" stop working due to ignoring this
   step in the past when going from 9.x to 10.1 (OK, if you
   detest this step, you can remember to do "sh /etc/rc.d/cron
   restart", but there may be more similar cases, so "better safe
   than sorry!")

Hm, possibly ... not the recommended procedure for every user?
However, myself, I find it concptually simple (maybe that says
something about myself...) and gives minimal downtime.

Nowadays the "sysinst" program is even distributed and installed
as part of the base OS, so that should make it less neccessary to
mess with an installation medium to perform an upgrade(?)

$ type sysinst
sysinst is /usr/sbin/sysinst
$

However, do note that the rule "kernel first, user-land second"
still needs to be obeyed, i.e. steps 1-4 above needs to be
performed also if that route is followed.

But by using the already-installed sysinst, you get the "old"
sysinst, and it is still being developed and will change between
major releases, so if you follow that route instead of the above
procedure, perhaps best to use the install medium all the same?

As you might guess, I've never used sysinst to perform an upgrade
myself, so take that part with a grain of salt.

Regards,

- Håvard