Ramiro Aceves <ea1abz%gmail.com@localhost> writes:
But my concern is for upgrading from 10.x to 11, when 11 will be
released (major version upgrade). ¿Is it mandatory to use an install
media (pendrive 11.0 installer for example )? ¿would it be possible to
use built-in sysinst from 10.x to upgrade to 11, upgrading kernel
first and reboot, then upgrade the base system upgrade using the
built-in sysinst?
I haven't upgraded netbsd-10 to netbsd-11, but have many times done N to
N+1. Unpacking the kernel (and modules, if your system loads any) and
rebooting should be fine. Then you can unpack sets and reboot. And
then packages.
The above depends on binary compatibility where 11 can run 10 binaries.
NetBSD is very careful about this. I tried to run a 386bsd binary the
other day while cleaning up, under 10, and that failed, because a.out
support wasn't compiled in. I didn't try harder - perhaps module
loading would have got me there, because I didn't really want to run it.
I have been running a disk utility I wrote, and I just checked and it
was built under 7. I have a binary for another program I wrote, and it
runs fine. The mod date on the binary is July 2003. So that tells you
generally how far back things go. I'd expect pretty much anything ELF
to work.
The trickier part is programs that interact tightly with kernel
interfaces. I have a memory that ipfilter's control programs had an ABI
change at some major upgrade, maybe around NetBSD 5, and something about
ifconfig once. But even this is rare. So if you can manage it:
have console access for updates
stage the rest of the userland bits on the disk before you update the
kernel
but really these problems were discussed on the list, and NetBSD has
gotten more careful (going from very good to almost perfect) about
compat, so 10-11 should be fine.
If you have a remote machine with no console access, then you should
have a shadow copy, write your procedure down, and practice on the copy.
However, I suspect that with most other OSes, doing such an upgrade
would be considered crazy.
Of course as you have told us, I understand that it is also possible
to do a "full manual" system upgrade downloading the *.tgz sets and
uncompressing them manually over the old ones, with the etc files
upgraded separately, but I am a bit lazy and I think it will be more
prone to human errors that using sysinst and sysupgrade programs.
That's why sysugrade was written, and etcmanage, which is another way to
do it. I prefer etcmanage, because it (not surprisingly as I designed
it) does what I want: a file in /etc is just upgraded, as long as the
records show that it was not modified from the previous automatic
placement.