Re: backward compatibility: how far can it reasonably go?
ya...@sdf.org writes: >> "Greg A. Woods" writes: >> I am unclear if ipf has been removed by default from current. > > Even in NetBSD 9, ipf is not in the GENERIC kernel config. > > Was the kernel compiled to use ipf? > > e.g. add to kernel config: > options IPFILTER_LOG# ipmon(8) log support > options IPFILTER_LOOKUP # ippool(8) support > options IPFILTER_COMPAT # Compat for IP-Filter > pseudo-device ipfilter# IP filter (firewall) and NAT You are correct, but /sbin/ipf loads the ipl module, and it does this well enough that I had no idea it wasn't in GENERIC. signature.asc Description: PGP signature
re: backward compatibility: how far can it reasonably go?
> > On Dec 8, 2021, at 10:52 AM, Greg A. Woods wrote:
> >
> > That's one bullet I've dodged entirely already since my oldest systems
> > are running netbsd-5 stable. (Though in theory isn't there supposed to
> > be COMPAT support for SA?)
>
> int
> compat_60_sys_sa_register(lwp_t *l,
> const struct compat_60_sys_sa_register_args *uap,
> register_t *retval)
> {
> return sys_nosys(l, uap, retval);
> }
>
> SA is one of those things that's REALLY hard to provide compatibility for.
indeed, and only static userland would be affected, as ad@ also
provided replacement libpthread.so's for netbsd-4 that made it
use the newer kernel system instead, for use in chroot, and
this technique could also be provided for earlier if needed.
.mrg.
Re: backward compatibility: how far can it reasonably go?
At Wed, 8 Dec 2021 11:36:17 -0800, Jason Thorpe wrote:
Subject: Re: backward compatibility: how far can it reasonably go?
>
>
> > On Dec 8, 2021, at 10:52 AM, Greg A. Woods
> > wrote:
> > That's one bullet I've dodged entirely already since my oldest
> > systems are running netbsd-5 stable. (Though in theory isn't
> > there supposed to be COMPAT support for SA?)
>
> int
> compat_60_sys_sa_register(lwp_t *l, const struct
> compat_60_sys_sa_register_args *uap, register_t *retval)
> { return sys_nosys(l, uap, retval);
> }
>
> SA is one of those things that's REALLY hard to provide
> compatibility for.
:-) I see!
Yes, I can appreciate that SA isn't easily maintained in any way.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp4UZmrDv0i5.pgp
Description: OpenPGP Digital Signature
Re: backward compatibility: how far can it reasonably go?
Jason Thorpe writes:
>> On Dec 8, 2021, at 10:52 AM, Greg A. Woods wrote:
>>
>> That's one bullet I've dodged entirely already since my oldest systems
>> are running netbsd-5 stable. (Though in theory isn't there supposed to
>> be COMPAT support for SA?)
>
> int
> compat_60_sys_sa_register(lwp_t *l,
> const struct compat_60_sys_sa_register_args *uap,
> register_t *retval)
> {
> return sys_nosys(l, uap, retval);
> }
>
> SA is one of those things that's REALLY hard to provide compatibility for.
>
> -- thorpej
Ya, that... I remember a diff that is probably sitting in a mailing
list message somewhere that provided an emulation I think at the lib
layer for this. However, in the case I mentioned, the lack of support
was not a show stopper. It really was the only thing that caused any
problems at all. Even a 7.x kernel, as an initial test, booted with a
4.x userland didn't really have any real trouble in that it ran all of
the /etc/rc stuff mostly just fine and I could log in. I would suspect
that going from 5.x forward would not be just too much of a problem.
--
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: backward compatibility: how far can it reasonably go?
> On Dec 8, 2021, at 10:52 AM, Greg A. Woods wrote:
>
> That's one bullet I've dodged entirely already since my oldest systems
> are running netbsd-5 stable. (Though in theory isn't there supposed to
> be COMPAT support for SA?)
int
compat_60_sys_sa_register(lwp_t *l,
const struct compat_60_sys_sa_register_args *uap,
register_t *retval)
{
return sys_nosys(l, uap, retval);
}
SA is one of those things that's REALLY hard to provide compatibility for.
-- thorpej
Re: backward compatibility: how far can it reasonably go?
At Wed, 08 Dec 2021 11:08:09 -0500, Brad Spencer wrote: Subject: Re: backward compatibility: how far can it reasonably go? > > When I took a system from 4.0 to 7.x some time ago, the only thing that > I had problems with was anything that used scheduler activations since > that had been removed. For me this only effected stuff from pkgsrc, as > I also rolled in new userland at the same time. That's one bullet I've dodged entirely already since my oldest systems are running netbsd-5 stable. (Though in theory isn't there supposed to be COMPAT support for SA?) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpFm57bXUxlC.pgp Description: OpenPGP Digital Signature
Re: backward compatibility: how far can it reasonably go?
At Wed, 8 Dec 2021 15:32:24 -, ya...@sdf.org wrote: Subject: Re: backward compatibility: how far can it reasonably go? > > > "Greg A. Woods" writes: no, Greg Troxel wrote: > > I am unclear if ipf has been removed by default from current. > Even in NetBSD 9, ipf is not in the GENERIC kernel config. Well I'm running in Xen domUs, so not GENERIC but XEN3_DOMU, and indeed I'm running all custom kernel builds. > Was the kernel compiled to use ipf? Clearly IPF is in the 9.99.81 kernel I booted, since it's functions are visible in the backtrace of the crash :-) If it were not compiled in, I think/hope it would not crash -- just the ipf tool would return an error and complain about something like ENXIO or maybe ENODEV. So if IPF were the only problem I would try taking it out temporarily, but with ifconfig also useless, I'll probably try the upgrade from the dom0. > e.g. add to kernel config: > options IPFILTER_LOG# ipmon(8) log support > options IPFILTER_LOOKUP # ippool(8) support > options IPFILTER_COMPAT # Compat for IP-Filter > pseudo-device ipfilter# IP filter (firewall) and NAT Yes, all there (and BRIDGE_IPF as well, though I haven't used that feature yet, and it would likely only be needed in the dom0) Indeed an identical kernel is already running IPF in another domU instance, but of course with the corresponding 9.99.81 userland. It works as well as ever -- I use it with blocklistd, as well as for basic firewalling (most of my systems are mostly on a private network with only one or two ports forwarded to them from the main firewall and so otherwise using the main FW's NAT for outgoing connections only). -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpZy7_nCYGHf.pgp Description: OpenPGP Digital Signature
Re: backward compatibility: how far can it reasonably go?
Brad Spencer writes: > You can also shut the DOMU down and present the disks to another DOMU in > real time using "xl block-attach " just use the "r" device if you > use devices or the file otherwise. I have done this for many years with > PV DOMUs on many different Xen versions. Once you have the disks > presented, mostly I just "tar -xpf " the sets or my own build of > userland on top of the old system. Use postinstall after that usually > once the system is booted up again with the newer kernel and newer > userland. You will need the etc sets for postinstall, but nothing has > been scary there. Messed that statement up... use the Not "r" device, the block device not the character device. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: backward compatibility: how far can it reasonably go?
"Greg A. Woods" writes: > 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 You can also shut the DOMU down and present the disks to another DOMU in real time using "xl block-attach " just use the "r" device if you use devices or the file otherwise. I have done this for many years with PV DOMUs on many different Xen versions. Once you have the disks presented, mostly I just "tar -xpf " the sets or my own build of userland on top of the old system. Use postinstall after that usually once the system is booted up again with the newer kernel and newer userland. You will need the etc sets for postinstall, but nothing has been scary there. Although I have never seen this problem, there may be trouble if the block size that the DOMU sees of the disks is different from what DOM0 sees. There have been comments about this from time to time. I have also done other variations of this using a copy of /rescue/tar to extract the new userland onto a live DOMU system usually from the Xen console in single user mode. This has also generally worked out just fine and I use that in the case where I have made /usr a LVM disk inside of the DOMU and it is a pain to present that to another DOMU. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: backward compatibility: how far can it reasonably go?
"Greg A. Woods" 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? > > 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: When I took a system from 4.0 to 7.x some time ago, the only thing that I had problems with was anything that used scheduler activations since that had been removed. For me this only effected stuff from pkgsrc, as I also rolled in new userland at the same time. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: backward compatibility: how far can it reasonably go?
> "Greg A. Woods" writes: > I am unclear if ipf has been removed by default from current. > Even in NetBSD 9, ipf is not in the GENERIC kernel config. Was the kernel compiled to use ipf? e.g. add to kernel config: options IPFILTER_LOG# ipmon(8) log support options IPFILTER_LOOKUP # ippool(8) support options IPFILTER_COMPAT # Compat for IP-Filter pseudo-device ipfilter# IP filter (firewall) and NAT --gene
Re: backward compatibility: how far can it reasonably go?
"Greg A. Woods" 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. signature.asc Description: PGP signature
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
