Re: backward compatibility: how far can it reasonably go?
At Tue, 7 Dec 2021 20:37:26 -0800 (PST), Paul Goyette wrote: Subject: Re: backward compatibility: how far can it reasonably go? > > Without looking at the details of your backtrace, the issue with > ifconfig(8) could be related to PRs kern/54150 and/or kern/54151. Aw, damn, my memory is too short! Thanks for reminding me of those! The kernel crash was IPF-related, and in my test back then I was testing on an i386 machine, which at the time did not, IIRC (and we know what that might mean), was not running IPF. Anyway, the two machines I'm upgrading do need to run IPF, at least until they are running a new OS with new pkgs. I'm beginning to think the only way to avoid that rabbit hole in order to get these upgrades done in the next week will be to shut them down and do the upgrades by mounting their filesystems in their dom0s. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpV1TJFBLXGn.pgp Description: OpenPGP Digital Signature
Re: backward compatibility: how far can it reasonably go?
On Tue, 7 Dec 2021, Greg A. Woods wrote: 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? I believe that this 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: Without looking at the details of your backtrace, the issue with ifconfig(8) could be related to PRs kern/54150 and/or kern/54151. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
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
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(0xd000108870c0, 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 0x8022d93d cs 0xe030 rflags 0x202
cr2 0x7a0d38c36020 ilevel 0 rsp 0xd0018da561b0
[ 90.1952515] curlwp 0xdf5468c0 pid 184.184 lowest kstack
0xd0018da522c0
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 d0018da55f5c
rbp d0018da561b0
rbx 1
rdx 2
rcx 0
rax 0
r8 1
r9 1
r10 0
r11 fffe
r12 104
r13 8063bb30ostype+0x36eb8
r14 d0018da561f8
r15 3
rip 8022d93dbreakpoint+0x5
cs e030
rflags 202
rsp d0018da561b0
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
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpS15LHa_ZPh.pgp
Description: OpenPGP Digital Signature
daily CVS update output
Updating src tree: P src/UPDATING P src/distrib/sets/lists/base/mi P src/distrib/sets/lists/comp/mi P src/distrib/sets/lists/debug/mi P src/distrib/sets/lists/debug/module.mi P src/distrib/sets/lists/man/mi P src/distrib/sets/lists/modules/mi P src/doc/CHANGES P src/etc/MAKEDEV.tmpl P src/external/lgpl3/gmp/lib/libgmp/Makefile P src/lib/libc/rpc/svc_vc.c P src/lib/librumpuser/sp_common.c P src/sbin/mount/mount.c P src/share/man/man4/Makefile P src/share/man/man4/iic.4 U src/share/man/man4/scmd.4 U src/share/man/man4/scmdi2c.4 U src/share/man/man4/scmdspi.4 P src/share/man/man4/spi.4 P src/share/mk/bsd.clean.mk P src/sys/arch/aarch64/aarch64/pmap.c P src/sys/arch/m68k/fpsp/res_func.sa P src/sys/arch/mips/adm5120/dev/ahci.c P src/sys/conf/files P src/sys/conf/majors P src/sys/dev/acpi/vald_acpi.c P src/sys/dev/i2c/files.i2c U src/sys/dev/i2c/scmdi2c.c P src/sys/dev/ic/Makefile P src/sys/dev/ic/pckbcvar.h U src/sys/dev/ic/scmd.c U src/sys/dev/ic/scmdreg.h U src/sys/dev/ic/scmdvar.h P src/sys/dev/nand/hamming.c P src/sys/dev/pci/ixgbe/ixgbe.c P src/sys/dev/sbus/sio16.c P src/sys/dev/spi/files.spi U src/sys/dev/spi/scmdspi.c P src/sys/dev/usb/ehci.c P src/sys/modules/Makefile U src/sys/modules/scmd/Makefile U src/sys/modules/scmd/scmd.ioconf U src/sys/modules/scmdi2c/Makefile U src/sys/modules/scmdi2c/scmdi2c.ioconf P src/sys/secmodel/keylock/secmodel_keylock.c P src/sys/ufs/chfs/chfs.h P src/sys/ufs/chfs/chfs_gc.c P src/sys/ufs/chfs/chfs_malloc.c P src/sys/ufs/chfs/chfs_nodeops.c P src/sys/ufs/chfs/chfs_vnode.c P src/sys/ufs/chfs/chfs_vnops.c P src/sys/ufs/chfs/chfs_write.c P src/sys/ufs/chfs/ebh.c P src/tests/lib/libcurses/slave/curses_commands.c P src/tests/usr.bin/xlint/check-expect.lua P src/usr.bin/Makefile P src/usr.bin/m4/gnum4.c P src/usr.bin/m4/PSD.doc/Makefile U src/usr.bin/m4/PSD.doc/m4.ms P src/usr.bin/mail/list.c P src/usr.bin/make/hash.c P src/usr.bin/make/hash.h P src/usr.bin/make/parse.c P src/usr.bin/make/var.c U src/usr.bin/scmdctl/Makefile U src/usr.bin/scmdctl/common.c U src/usr.bin/scmdctl/common.h U src/usr.bin/scmdctl/i2cspi.c U src/usr.bin/scmdctl/i2cspi.h U src/usr.bin/scmdctl/printscmd.c U src/usr.bin/scmdctl/printscmd.h U src/usr.bin/scmdctl/responses.h U src/usr.bin/scmdctl/scmdctl.1 U src/usr.bin/scmdctl/scmdctl.c U src/usr.bin/scmdctl/scmdctl.h U src/usr.bin/scmdctl/scmdctlconst.h U src/usr.bin/scmdctl/uart.c U src/usr.bin/scmdctl/uart.h P src/usr.bin/what/what.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.3 P sys/arch/x86/x86/identcpu.c P sys/dev/i2c/sdtemp.c P sys/dev/i2c/spdmem_i2c.c Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.3 P sys/arch/x86/x86/identcpu.c P sys/dev/i2c/sdtemp.c P sys/dev/i2c/spdmem_i2c.c P sys/dev/usb/ehci.c Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 40492204 Dec 8 03:11 ls-lRA.gz
