Re: sysupgrade from -stable (was: error rebuilding binaries after 6.9->7.0 sysupgrade)
On Mon, Apr 04, 2022 at 08:37:57PM +0100, Steve Fairhead said: > To put it another way, what is the recommended way of upgrading a production > system with patches applied (so -stable)? Historically I used the manual method to upgrade releases but have been using sysupgrade(8) since it became The Thing. I use pkg_add(8) -u and syspatch(8) to keep up with -stable between releases. The FAQ is rather extensive on these topics as are the manpages. https://www.openbsd.org/faq/upgrade70.html https://www.openbsd.org/faq/faq10.html#Patches --Matt
Re: sysupgrade from -stable (was: error rebuilding binaries after 6.9->7.0 sysupgrade)
On 2022/04/04 20:37, Steve Fairhead wrote: > On 04/04/2022 13:10, owner-m...@openbsd.org wrote: > > sysupgrade only copes with what look like release versions (no version > > suffix, upgrades to release+0.1 with no arguments, or snapshot with -s) > > or snapshots (-current or -beta suffix, by default -current upgrades > > to release+0.1 or -beta upgrades to release, or snapshot with -s). > > > > It doesn't handle -stable, and it doesn't handle going from the current > > situation which is "it's still snapshots rather than release but there's > > no suffix" to the forthcoming release. > > I've now upgraded a couple of systems from 6.8 -stable, using "sysupgrade > -r", through 6.9 and then 7.0 (rebuilding and rebooting after patches). They > seem fine. Any gotchas with this? Ah looking at what that does, it does look alright as a way to handle -stable with just flags rather than patching the script. > To put it another way, what is the recommended way of upgrading a production > system with patches applied (so -stable)? On an arch where syspatches are available (amd64, i386, arm64), the method that would normally be recommended these days would be to use syspatches rather than compiling -stable.
sysupgrade from -stable (was: error rebuilding binaries after 6.9->7.0 sysupgrade)
On 04/04/2022 13:10, owner-m...@openbsd.org wrote: sysupgrade only copes with what look like release versions (no version suffix, upgrades to release+0.1 with no arguments, or snapshot with -s) or snapshots (-current or -beta suffix, by default -current upgrades to release+0.1 or -beta upgrades to release, or snapshot with -s). It doesn't handle -stable, and it doesn't handle going from the current situation which is "it's still snapshots rather than release but there's no suffix" to the forthcoming release. I've now upgraded a couple of systems from 6.8 -stable, using "sysupgrade -r", through 6.9 and then 7.0 (rebuilding and rebooting after patches). They seem fine. Any gotchas with this? To put it another way, what is the recommended way of upgrading a production system with patches applied (so -stable)? Thanks, Steve -- -- Steve Fairhead fivetrees ltd - for the complete music service www: http://www.fivetrees.com --
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
OK, thanks, good to know. Dave On 4/3/22, Stuart Henderson wrote: > On 2022/04/03 14:02, Raymond, David wrote: >> So, to clarify, if I upgrade to a snapshot after upgrading to 7.0 >> stable, what happens when 7.1 stable comes along? Can I get to that >> stable release from a previous snapshot? > > Official binaries do not have "-stable" (neither releases nor > syspatches). If your kernel has -stable in the version string then > it is a self-built kernel and sysupgrade doesn't handle it > > At the current point in time, snapshots say "OpenBSD 7.1" with no > suffix. When running such a kernel, if you want to do something other > than "upgrade to whatever is currently in the /snapshots/ directory" > or "upgrade to 7.*2* release when available" you either need to > modify the sysupgrade shell script, or download the files yourself > (typically the easy way to do this is to download the bsd.rd installer > from the version you want and install manually) > > Unless you modify sysupgrade you can't get from a "OpenBSD 7.1" kernel > to downloading files from the /7.1/ directory. > >> Dave Raymond >> >> On 4/3/22, Stuart Henderson wrote: >> > On 2022-04-03, Steve Fairhead wrote: >> >> On 07/11/2021 10:35, Steve Fairhead wrote: >> >>> >> >>> That's what I'd expect, and I did indeed run sysupgrade without >> >>> specific >> >>> >> >>> options. Nonetheless I seem to have wound up with -current when I >> >>> would >> >>> have expected -stable: >> >>> >> >>> # dmesg | grep OpenBSD >> >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Mon Aug 23 21:44:18 BST 2021 >> >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 >> >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 >> >>> OpenBSD 7.0-current (RAMDISK_CD) #71: Fri Nov 5 10:13:26 MDT 2021 >> >>> OpenBSD 7.0-current (GENERIC.MP) #72: Fri Nov 5 10:08:43 MDT 2021 >> >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 13:30:45 GMT 2021 >> >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 16:15:08 GMT 2021 >> >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 19:53:47 GMT 2021 >> >>> >> >>> I have no idea how this can have happened. I would dearly love to >> >>> understand what I did wrong. >> >> >> >> I *finally* figured out what happened, after some experimenting with a >> >> spare machine. Running sysupgrade with no parameters on -stable (i.e. >> >> -release + patches, rebuilt) upgrades to a snapshot (i.e. -current). >> >> >> >> Is this expected behaviour? >> > >> > sysupgrade only copes with what look like release versions (no version >> > suffix, upgrades to release+0.1 with no arguments, or snapshot with -s) >> > or snapshots (-current or -beta suffix, by default -current upgrades >> > to release+0.1 or -beta upgrades to release, or snapshot with -s). >> > >> > It doesn't handle -stable, and it doesn't handle going from the current >> > situation which is "it's still snapshots rather than release but >> > there's >> > no suffix" to the forthcoming release. >> > >> > >> > >> >> >> -- >> David J. Raymond >> david.raym...@nmt.edu >> http://kestrel.nmt.edu/~raymond > -- David J. Raymond david.raym...@nmt.edu http://kestrel.nmt.edu/~raymond
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
On 2022/04/03 14:02, Raymond, David wrote: > So, to clarify, if I upgrade to a snapshot after upgrading to 7.0 > stable, what happens when 7.1 stable comes along? Can I get to that > stable release from a previous snapshot? Official binaries do not have "-stable" (neither releases nor syspatches). If your kernel has -stable in the version string then it is a self-built kernel and sysupgrade doesn't handle it At the current point in time, snapshots say "OpenBSD 7.1" with no suffix. When running such a kernel, if you want to do something other than "upgrade to whatever is currently in the /snapshots/ directory" or "upgrade to 7.*2* release when available" you either need to modify the sysupgrade shell script, or download the files yourself (typically the easy way to do this is to download the bsd.rd installer from the version you want and install manually) Unless you modify sysupgrade you can't get from a "OpenBSD 7.1" kernel to downloading files from the /7.1/ directory. > Dave Raymond > > On 4/3/22, Stuart Henderson wrote: > > On 2022-04-03, Steve Fairhead wrote: > >> On 07/11/2021 10:35, Steve Fairhead wrote: > >>> > >>> That's what I'd expect, and I did indeed run sysupgrade without specific > >>> > >>> options. Nonetheless I seem to have wound up with -current when I would > >>> have expected -stable: > >>> > >>> # dmesg | grep OpenBSD > >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Mon Aug 23 21:44:18 BST 2021 > >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 > >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 > >>> OpenBSD 7.0-current (RAMDISK_CD) #71: Fri Nov 5 10:13:26 MDT 2021 > >>> OpenBSD 7.0-current (GENERIC.MP) #72: Fri Nov 5 10:08:43 MDT 2021 > >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 13:30:45 GMT 2021 > >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 16:15:08 GMT 2021 > >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 19:53:47 GMT 2021 > >>> > >>> I have no idea how this can have happened. I would dearly love to > >>> understand what I did wrong. > >> > >> I *finally* figured out what happened, after some experimenting with a > >> spare machine. Running sysupgrade with no parameters on -stable (i.e. > >> -release + patches, rebuilt) upgrades to a snapshot (i.e. -current). > >> > >> Is this expected behaviour? > > > > sysupgrade only copes with what look like release versions (no version > > suffix, upgrades to release+0.1 with no arguments, or snapshot with -s) > > or snapshots (-current or -beta suffix, by default -current upgrades > > to release+0.1 or -beta upgrades to release, or snapshot with -s). > > > > It doesn't handle -stable, and it doesn't handle going from the current > > situation which is "it's still snapshots rather than release but there's > > no suffix" to the forthcoming release. > > > > > > > > > -- > David J. Raymond > david.raym...@nmt.edu > http://kestrel.nmt.edu/~raymond
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
So, to clarify, if I upgrade to a snapshot after upgrading to 7.0 stable, what happens when 7.1 stable comes along? Can I get to that stable release from a previous snapshot? Dave Raymond On 4/3/22, Stuart Henderson wrote: > On 2022-04-03, Steve Fairhead wrote: >> On 07/11/2021 10:35, Steve Fairhead wrote: >>> >>> That's what I'd expect, and I did indeed run sysupgrade without specific >>> >>> options. Nonetheless I seem to have wound up with -current when I would >>> have expected -stable: >>> >>> # dmesg | grep OpenBSD >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Mon Aug 23 21:44:18 BST 2021 >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 >>> OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 >>> OpenBSD 7.0-current (RAMDISK_CD) #71: Fri Nov 5 10:13:26 MDT 2021 >>> OpenBSD 7.0-current (GENERIC.MP) #72: Fri Nov 5 10:08:43 MDT 2021 >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 13:30:45 GMT 2021 >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 16:15:08 GMT 2021 >>> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 19:53:47 GMT 2021 >>> >>> I have no idea how this can have happened. I would dearly love to >>> understand what I did wrong. >> >> I *finally* figured out what happened, after some experimenting with a >> spare machine. Running sysupgrade with no parameters on -stable (i.e. >> -release + patches, rebuilt) upgrades to a snapshot (i.e. -current). >> >> Is this expected behaviour? > > sysupgrade only copes with what look like release versions (no version > suffix, upgrades to release+0.1 with no arguments, or snapshot with -s) > or snapshots (-current or -beta suffix, by default -current upgrades > to release+0.1 or -beta upgrades to release, or snapshot with -s). > > It doesn't handle -stable, and it doesn't handle going from the current > situation which is "it's still snapshots rather than release but there's > no suffix" to the forthcoming release. > > > -- David J. Raymond david.raym...@nmt.edu http://kestrel.nmt.edu/~raymond
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
On 2022-04-03, Steve Fairhead wrote: > On 07/11/2021 10:35, Steve Fairhead wrote: >> >> That's what I'd expect, and I did indeed run sysupgrade without specific >> options. Nonetheless I seem to have wound up with -current when I would >> have expected -stable: >> >> # dmesg | grep OpenBSD >> OpenBSD 6.9-stable (GENERIC.MP) #0: Mon Aug 23 21:44:18 BST 2021 >> OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 >> OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 >> OpenBSD 7.0-current (RAMDISK_CD) #71: Fri Nov 5 10:13:26 MDT 2021 >> OpenBSD 7.0-current (GENERIC.MP) #72: Fri Nov 5 10:08:43 MDT 2021 >> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 13:30:45 GMT 2021 >> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 16:15:08 GMT 2021 >> OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 19:53:47 GMT 2021 >> >> I have no idea how this can have happened. I would dearly love to >> understand what I did wrong. > > I *finally* figured out what happened, after some experimenting with a > spare machine. Running sysupgrade with no parameters on -stable (i.e. > -release + patches, rebuilt) upgrades to a snapshot (i.e. -current). > > Is this expected behaviour? sysupgrade only copes with what look like release versions (no version suffix, upgrades to release+0.1 with no arguments, or snapshot with -s) or snapshots (-current or -beta suffix, by default -current upgrades to release+0.1 or -beta upgrades to release, or snapshot with -s). It doesn't handle -stable, and it doesn't handle going from the current situation which is "it's still snapshots rather than release but there's no suffix" to the forthcoming release.
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
On 07/11/2021 10:35, Steve Fairhead wrote: That's what I'd expect, and I did indeed run sysupgrade without specific options. Nonetheless I seem to have wound up with -current when I would have expected -stable: # dmesg | grep OpenBSD OpenBSD 6.9-stable (GENERIC.MP) #0: Mon Aug 23 21:44:18 BST 2021 OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 OpenBSD 7.0-current (RAMDISK_CD) #71: Fri Nov 5 10:13:26 MDT 2021 OpenBSD 7.0-current (GENERIC.MP) #72: Fri Nov 5 10:08:43 MDT 2021 OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 13:30:45 GMT 2021 OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 16:15:08 GMT 2021 OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 19:53:47 GMT 2021 I have no idea how this can have happened. I would dearly love to understand what I did wrong. I *finally* figured out what happened, after some experimenting with a spare machine. Running sysupgrade with no parameters on -stable (i.e. -release + patches, rebuilt) upgrades to a snapshot (i.e. -current). Is this expected behaviour? Again, apologies if this is obvious to everyone but me ;) . Steve -- -- Steve Fairhead fivetrees ltd - for the complete music service www: http://www.fivetrees.com --
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
On 07/11/2021 08:44, Sebastien Marie wrote: You didn't need to remove the previous; you could have just updated the source you had. running cvs update (with -r OPENBSD_7_0) is a possibility, but removing files and reinstall is another. Nothing wrong here. Actually I did try a CVS update first, before nuking/reinstalling. That's when I first saw the error, so I kinda started over. for the errata; still fine. For errate to 7.0? If you have a -current system for sysupgrade and only updated to the 7.0 errata, the source you have in /usr/src is behind what you have installed. sysupgrade (when used without specific options) is used to upgrade a system from one release to next release. If you are on 6.9 (-release or -stable) and run `doas sysupgrade', you will get a 7.0 system (and not -current). That's what I'd expect, and I did indeed run sysupgrade without specific options. Nonetheless I seem to have wound up with -current when I would have expected -stable: # dmesg | grep OpenBSD OpenBSD 6.9-stable (GENERIC.MP) #0: Mon Aug 23 21:44:18 BST 2021 OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 OpenBSD 6.9-stable (GENERIC.MP) #0: Sun Oct 31 10:03:46 GMT 2021 OpenBSD 7.0-current (RAMDISK_CD) #71: Fri Nov 5 10:13:26 MDT 2021 OpenBSD 7.0-current (GENERIC.MP) #72: Fri Nov 5 10:08:43 MDT 2021 OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 13:30:45 GMT 2021 OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 16:15:08 GMT 2021 OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Nov 6 19:53:47 GMT 2021 I have no idea how this can have happened. I would dearly love to understand what I did wrong. (The last 3 lines are, presumably, because I rebuilt the kernel after re-installing the source. But I now have a mismatch. Maybe my best bet is to stay with -current on this machine.) Thanks for your responses. Steve -- -- Steve Fairhead fivetrees ltd - for the complete music service www: http://www.fivetrees.com --
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
On Sun, Nov 07, 2021 at 08:48:47AM +0100, Jan Stary wrote: > On Nov 06 20:51:53, st...@fivetrees.com wrote: > > Hi folks, > > > > I think I've probably done something stupid, but I'm not sure where. Not > > used sysupgrade before; I usually reinstall. So this is new to me. > > > > I updated a system from 6.9 to 7.0 with sysupgrade; no problems at all. I > > then nuked the contents of /usr/src, > > Why? > > > and decanted the 7.0 src.tar.gz and > > sys.tar.gz files as usual with a new install. > > Then did a cvs update > > You didn't need to remove the previous; > you could have just updated the source you had. running cvs update (with -r OPENBSD_7_0) is a possibility, but removing files and reinstall is another. Nothing wrong here. > > for the errata; still fine. > > For errate to 7.0? If you have a -current system for sysupgrade > and only updated to the 7.0 errata, the source you have in /usr/src > is behind what you have installed. sysupgrade (when used without specific options) is used to upgrade a system from one release to next release. If you are on 6.9 (-release or -stable) and run `doas sysupgrade', you will get a 7.0 system (and not -current). > > Rebuilt kernel, installed it, rebooted; no problem. Then > > tried rebuilding binaries, and it failed with: > > > > ld: error: undefined symbol: X509_STORE_get_by_subject > > That's probably a change in libcrypto. For example, > I have these versions of libcrypto.so here: > > /usr/lib/libcrypto.so.46.1 > /usr/lib/libcrypto.so.46.3 > /usr/lib/libcrypto.so.47.0 > /usr/lib/libcrypto.so.48.0 > > The first three have X509_STORE_get_by_subject (says nm(1)), > but the newest one does not. So I believe X509_STORE_get_by_subject > was recently dropped. X509_STORE_get_by_subject was not dropped. It changed from function to macro. There is no more symbol in object file for it, but it is still usable in C source file. Thanks. -- Sebastien Marie
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
On Sat, Nov 06, 2021 at 08:51:53PM +, Steve Fairhead wrote: > Hi folks, > > I think I've probably done something stupid, but I'm not sure where. Not > used sysupgrade before; I usually reinstall. So this is new to me. > > I updated a system from 6.9 to 7.0 with sysupgrade; no problems at all. I > then nuked the contents of /usr/src, and decanted the 7.0 src.tar.gz and > sys.tar.gz files as usual with a new install. Then did a cvs update for the > errata; still fine. Rebuilt kernel, installed it, rebooted; no problem. Then > tried rebuilding binaries, and it failed with: > > ld: error: undefined symbol: X509_STORE_get_by_subject > >>> referenced by x509.c > >>> x509.o:(x509_generate_kn) > >>> referenced by x509.c > >>> x509.o:(x509_generate_kn) > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error 1 in sbin/isakmpd (:126 'isakmpd') > *** Error 2 in sbin (:48 'all': @for entry in atactl badsect > bioctl clri dhclient dhcpleased disklabel dmesg dump dumpfs fdi...) > *** Error 2 in . (:48 'all': @for entry in lib include bin > libexec sbin usr.bin usr.sbin share games gnu sys; do set -e; if ...) > *** Error 2 in . (Makefile:97 'do-build') > *** Error 2 in /usr/src (Makefile:74 'build') > > Where did I goof? Hi, First, I will reply with in orthognal way: you after updating your system with sysupgrade(8), you could use syspatch(8) to automatically get all errata for free (in fact, it is part of the first boot). You could see syspatch(8) man page for more informations. Next regarding your build problem. Could you check that your /usr/src checkout is really a 7.0 checkout ? $ cd /usr/src && cvs status Makefile === File: Makefile Status: Up-to-date Working revision:1.136 Repository revision: 1.136 /cvs/src/Makefile,v Commit Identifier: X942RVJkKyHKgpGo Sticky Tag: OPENBSD_7_0 (branch: 1.136.8) Sticky Date: (none) Sticky Options: (none) You should have a Sticky Tag with OPENBSD_7_0. You should also check src/lib/libcrypto/x509/x509_vfy.h header file (in case only a part of the source tree isn't 7.0): $ cd /usr/src && cvs status lib/libcrypto/x509/x509_vfy.h === File: x509_vfy.hStatus: Up-to-date Working revision:1.32 Repository revision: 1.32/cvs/src/lib/libcrypto/x509/x509_vfy.h,v Commit Identifier: eX8XGeJSFn9gUlal Sticky Tag: OPENBSD_7_0 (branch: 1.32.4) Sticky Date: (none) Sticky Options: (none) In 7.0, X509_STORE_get_by_subject is a function (with symbol), but under -current, it moved to be a macro (no more symbol). x509_vfy.h is the one where the function (or the macro) is defined. And your build error looks like your source dir is mixing 7.0 and -current. If it is the case, as you might already installed some part of the source tree, you might want to reinstall to 7.0. Downgrading from -current (or partial -current) to 7.0 isn't supported. If you want to put your source tree back to 7.0, you could use: $ cd /usr/src && cvs update -A -r OPENBSD_7_0 -A : Reset any sticky tags/date/kopts (not sure if 100% necessary or not, but doesn't hurt) -r : Update using tag for 7.0 (the tag will become sticky) Thanks. -- Sebastien Marie
Re: error rebuilding binaries after 6.9->7.0 sysupgrade
On Nov 06 20:51:53, st...@fivetrees.com wrote: > Hi folks, > > I think I've probably done something stupid, but I'm not sure where. Not > used sysupgrade before; I usually reinstall. So this is new to me. > > I updated a system from 6.9 to 7.0 with sysupgrade; no problems at all. I > then nuked the contents of /usr/src, Why? > and decanted the 7.0 src.tar.gz and > sys.tar.gz files as usual with a new install. > Then did a cvs update You didn't need to remove the previous; you could have just updated the source you had. > for the errata; still fine. For errate to 7.0? If you have a -current system for sysupgrade and only updated to the 7.0 errata, the source you have in /usr/src is behind what you have installed. > Rebuilt kernel, installed it, rebooted; no problem. Then > tried rebuilding binaries, and it failed with: > > ld: error: undefined symbol: X509_STORE_get_by_subject That's probably a change in libcrypto. For example, I have these versions of libcrypto.so here: /usr/lib/libcrypto.so.46.1 /usr/lib/libcrypto.so.46.3 /usr/lib/libcrypto.so.47.0 /usr/lib/libcrypto.so.48.0 The first three have X509_STORE_get_by_subject (says nm(1)), but the newest one does not. So I believe X509_STORE_get_by_subject was recently dropped. So this would make sense, if your source is behind. But looking at the current /usr/src/sbin/isakmpd, it indeed calls X509_STORE_get_by_subject(). I get a different error: /usr/src/sbin/isakmpd/x509.c:163:8: error: implicit declaration of function 'X509_OBJECT_new' is invalid in C99 [-Werror,-Wimplicit-function-declaration] obj = X509_OBJECT_new(); ^ So perhaps the current isakmpd source itself is behind. That sometimes happens at the bleeding edge of -current. Running cvs log x509.c in sbin/isakmpd shows that there have been recent changes to the X509_OBJECT. Jan > >>> referenced by x509.c > >>> x509.o:(x509_generate_kn) > >>> referenced by x509.c > >>> x509.o:(x509_generate_kn) > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error 1 in sbin/isakmpd (:126 'isakmpd') > *** Error 2 in sbin (:48 'all': @for entry in atactl badsect > bioctl clri dhclient dhcpleased disklabel dmesg dump dumpfs fdi...) > *** Error 2 in . (:48 'all': @for entry in lib include bin > libexec sbin usr.bin usr.sbin share games gnu sys; do set -e; if ...) > *** Error 2 in . (Makefile:97 'do-build') > *** Error 2 in /usr/src (Makefile:74 'build') > > Where did I goof? > > Thanks, and apologies for my dumbassness, > > Steve > > -- > > -- > Steve Fairhead > fivetrees ltd - for the complete music service >www: http://www.fivetrees.com > -- > >
error rebuilding binaries after 6.9->7.0 sysupgrade
Hi folks, I think I've probably done something stupid, but I'm not sure where. Not used sysupgrade before; I usually reinstall. So this is new to me. I updated a system from 6.9 to 7.0 with sysupgrade; no problems at all. I then nuked the contents of /usr/src, and decanted the 7.0 src.tar.gz and sys.tar.gz files as usual with a new install. Then did a cvs update for the errata; still fine. Rebuilt kernel, installed it, rebooted; no problem. Then tried rebuilding binaries, and it failed with: ld: error: undefined symbol: X509_STORE_get_by_subject >>> referenced by x509.c >>> x509.o:(x509_generate_kn) >>> referenced by x509.c >>> x509.o:(x509_generate_kn) cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error 1 in sbin/isakmpd (:126 'isakmpd') *** Error 2 in sbin (:48 'all': @for entry in atactl badsect bioctl clri dhclient dhcpleased disklabel dmesg dump dumpfs fdi...) *** Error 2 in . (:48 'all': @for entry in lib include bin libexec sbin usr.bin usr.sbin share games gnu sys; do set -e; if ...) *** Error 2 in . (Makefile:97 'do-build') *** Error 2 in /usr/src (Makefile:74 'build') Where did I goof? Thanks, and apologies for my dumbassness, Steve -- -- Steve Fairhead fivetrees ltd - for the complete music service www: http://www.fivetrees.com --
