Ramiro Aceves <ea1...@gmail.com> 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.
