I found I was rebooting into new sets a lot, so I decided to write 2
scripts to save aching fingers and failing brain cells, and just to make
life easier for myself - the scripts kinda encapsulate the sequences
Havard was talking about below.
Firstly, some context - I build the sources, the sets are under /usr/build,
and I keep a few previous kernels in /, named by date, and with the active
kernel a hard link to the latest dated kernel:
-rw-r--r-- 2 root wheel 19763888 Oct 19 15:26 netbsd
-rw-r--r-- 1 root wheel 19690440 Sep 22 23:59 netbsd-20250922
-rw-r--r-- 1 root wheel 19695792 Oct 5 14:42 netbsd-20251005
-rw-r--r-- 2 root wheel 19758112 Oct 7 15:16 netbsd-20251007
-rw-r--r-- 2 root wheel 19763888 Oct 19 15:26 netbsd-20251019
-rw-r--r-- 2 root wheel 19758112 Oct 7 15:16 netbsd-recover
(Hard link because I was burned by a symlink in 1989. I know, I know)
Having built the sets, I use the newos1 script to install into the new
kernel:
% cat ~/scripts/newos1
#! /bin/sh
d=/usr/build/release/evbarm-aarch64/binary/sets
t=$(date +%Y%m%d)
(cd / &&
sudo cp $d/../kernel/netbsd-GENERIC64.gz /netbsd-${t}.gz &&
sudo gunzip -v /netbsd-${t}.gz &&
sudo mv netbsd /netbsd-recover &&
sudo ln netbsd-${t} netbsd &&
sudo tar xpzf ${d}/modules.tar.xz
sudo tar xpzf ${d}/rescue.tar.xz
)
%
and then reboot the machine with the new kernel.
Then I run newos2, which installs the rest of the sets, and runs etcupdate
for the merge:
% cat ~/scripts/newos2
#! /bin/sh
d=/usr/build/release/evbarm-aarch64/binary/sets
sets='
base
comp
dtb
games
gpufw
man
manhtml
misc
modules
rescue
tests
text
xbase
xcomp
xetc
xfont
xserver
'
(cd / &&
for i in ${sets}; do
echo ${i}
sudo tar xpzf ${d}/${i}.tar.xz
done &&
sudo etcupdate -v -s ${d}/etc.tar.xz
)
%
At this point, I run any postinstall that comes up, then reboot again, just
for completeness, and to make sure everything is as expected.
On Sat, 18 Oct 2025 at 11:20, Havard Eidnes <[email protected]> wrote:
> > 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
>
>
