"Greg A. Woods" <woods%planix.ca@localhost> writes: > So I've got a couple of old but important machines (Xen amd64 domUs) > running NetBSD-5, and I've finally decided that I'm reasonably well > enough prepared to try upgrading them. > > However it seems a "modern" (9.99.81, -current from about 2021-03-10) > kernel with COMPAT_40 isn't able to run some of the userland on those > systems. > > Is this something that should work? Yes, except ipf, is my memory. > If it should I think it would make the upgrade much easier as I could > then plop down the new userland and run etcupdate. (there are of course > alternative ways to do the upgrade, eased by the fact they are domUs (*)) Yes, if you can just new kernel, reboot unpack user sets, merge etc, reboot then your packages should be ok. I am unclear if ipf has been removed by default from current. (Others commented on your backtrace and I have nothing useful to say about that.) > Now since these are domUs and their dom0 is also NetBSD I could also > upgrade them "in absentia" so to speak, i.e. drop a new userland on > their filesystems from the dom0, though this seems more scary somehow. > I guess it shouldn't be since the dom0 and other test systems are > already running what I want them to run. I think mounting their filesystems into dom0 and doing the unpack/merge there, perhaps chrooted, is sensible. > Or, given they are relatively cleanly configured filesystem-wise > (esp. with a separate /usr/pkg, /home, etc.) I could also build new > prototype systems, copy over the /etc files and old shared libraries > from the old system to the new prototype, then run etcupdate on the new > prototype, and finally shut down the old system, re-assign the other > filesystems (/var, /usr/pkg, /home, /work, etc.) to the prototype, > reboot the prototype with the old system's name and address, and finally > patching up and/or rebuilding whatever is needed in /var. You could, but that sounds like way more work, and you will almost certainly miss things. I have found upgrading to be better than fresh, although I know one person who puts configs in a VCS with salt and debugs them until they work and uses that for new/recovery. But he's a bit extreme. > The key thing is that I want to be able to upgraded pkgs piecemeal since > I'm sure there will be some hiccups and reconfigs required along the > way. That is the iffy part. packages are linked to base system libs and each such package needs to see a consistent set via dynamic linking. I would build a full set of packages on another machine so you can 'pkgin up'. > Note that most everything is static-linked on these systems. The base > system is 100% static linked (except for ld.elf_so itself) though of > course there still are a few baroque packages which require > dynamic-loaded code so I will still need to be very careful to preserve > all old shared libraries. That makes the approach of building a fresh > prototype somewhat more difficult, though ultimately perhaps safest as > it can be fully tested before ditching the old system. If you really did that, then things should be relatively simple.
Attachment:
signature.asc
Description: PGP signature