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?
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 (*))
The most immediate problems I noticed are with networking. ifconfig -a
returns without printing anything, and trying to enable IPF crashes:
Enabling ipfilter.
[ 90.1912601] panic: kmem_free(0xffffd000108870c0, 697) != allocated size 18374686479671623680; overwrote?
[ 90.1912601] cpu3: Begin traceback...
[ 90.1922525] vpanic() at netbsd:vpanic+0x14a
[ 90.1922525] snprintf() at netbsd:snprintf
[ 90.1922525] kmem_alloc() at netbsd:kmem_alloc
[ 90.1932517] frrequest() at netbsd:frrequest+0x100
[ 90.1932517] ipf_ipf_ioctl() at netbsd:ipf_ipf_ioctl+0x37d
[ 90.1932517] ipfioctl() at netbsd:ipfioctl+0x9a
[ 90.1942516] cdev_ioctl() at netbsd:cdev_ioctl+0x81
[ 90.1942516] VOP_IOCTL() at netbsd:VOP_IOCTL+0x3e
[ 90.1942516] vn_ioctl() at netbsd:vn_ioctl+0xad
[ 90.1952515] sys_ioctl() at netbsd:sys_ioctl+0x555
[ 90.1952515] syscall() at netbsd:syscall+0x9c
[ 90.1952515] --- syscall (number 54) ---
[ 90.1952515] netbsd:syscall+0x9c:
[ 90.1952515] cpu3: End traceback...
[ 90.1952515] fatal breakpoint trap in supervisor mode
[ 90.1952515] trap type 1 code 0 rip 0xffffffff8022d93d cs 0xe030 rflags 0x202 cr2 0x7a0d38c36020 ilevel 0 rsp 0xffffd0018da561b0
[ 90.1952515] curlwp 0xffffd0000f5468c0 pid 184.184 lowest kstack 0xffffd0018da522c0
Stopped in pid 184.184 (ipf) at netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x14a
snprintf() at netbsd:snprintf
kmem_alloc() at netbsd:kmem_alloc
frrequest() at netbsd:frrequest+0x100
ipf_ipf_ioctl() at netbsd:ipf_ipf_ioctl+0x37d
ipfioctl() at netbsd:ipfioctl+0x9a
cdev_ioctl() at netbsd:cdev_ioctl+0x81
VOP_IOCTL() at netbsd:VOP_IOCTL+0x3e
vn_ioctl() at netbsd:vn_ioctl+0xad
sys_ioctl() at netbsd:sys_ioctl+0x555
syscall() at netbsd:syscall+0x9c
--- syscall (number 54) ---
netbsd:syscall+0x9c:
ds 61c0
es 6170
fs 61b0
gs 10
rdi 0
rsi ffffd0018da55f5c
rbp ffffd0018da561b0
rbx 1
rdx 2
rcx 0
rax 0
r8 1
r9 1
r10 0
r11 fffffffe
r12 104
r13 ffffffff8063bb30 ostype+0x36eb8
r14 ffffd0018da561f8
r15 3
rip ffffffff8022d93d breakpoint+0x5
cs e030
rflags 202
rsp ffffd0018da561b0
ss e02b
netbsd:breakpoint+0x5: leave
db{3}>
(*) alternatives
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.
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.
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.
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.
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpyMebsBJER3.pgp
Description: OpenPGP Digital Signature