NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

backward compatibility: how far can it reasonably go?

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

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) ---
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

(*) 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

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 <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgpyMebsBJER3.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index