Re: How do I know if my 13-stable has security patches?
Thanks, Ed, but where do I find this? uname -a" gives me stable/13-007101f87. For a while I was seeing a hyphenated number prefixed with a 'c' and I had assumed that that number was the sequence. The full hash from the logs just is a long hex number. As usual with git stuff, I'm still very confused. After decades with a common paradigm with RCS CVS and SVN, git is fundamentally very different and old terminology does not really align as git is designed from a very different perspective. I have read the little mini-guide Warner wrote as well as a couple of web tutorial, but the web tutorials are really about running your own repo on github or gitlab, not using a repo as a source for distributions. I'm still a long way from having a real clue. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Wed, Feb 24, 2021 at 12:06 PM Ed Maste wrote: > On Wed, 24 Feb 2021 at 12:35, Kevin Oberman wrote: > > > > In the svn days, I could just look at my svn revision to check on > whether a > > security patch was required. Now I have a git hash. I have no idea how to > > tell if my system running 13-STABLE of a few days ago has the patch. > > Thanks for posting this question. I see some useful information in > other replies to this thread and we'll want to make sure that makes > its way to appropriate documentation. > > For future advisories we should also report the commit count > associated with the fix; this is a monotonically-increasing number and > is reported in the uname. > > If you build stable/13 right now you would get > "stable/13-n244668-4664afc05402", and the fix in > 894360bacd42f021551f76518edd445f6d299f2e corresponds to n244572. > 244668 being larger than 244572 indicates that the fix is included. > > These counts are not unique across different branches; you can only > compare counts for the same branch. > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Drastic slowdown for geli attach
On Wednesday, 24 February 2021 23:34:06 CST Kevin Oberman wrote: > Sometime around the first week of this month (February) the time to do a > geli attach on my 13.0-ALPHA3 amd64 system sharply increased. It started > taking about 10 seconds. Prior to this, it took about 3-4 seconds. I have > not seen any issues with the disc after it attaches, I am simply concerned > that the longer time may be indicative of a deeper issue. > Just for reference, I have not experienced this with 13.0-BETA3. > The system is a ThinkPad L15 with a CometLake i5-10210U and a Seagate > ST2000LM007-1R8174 2T HDD. > I have 13.0-BETA3 on a HP laptop (HP EliteBook 850 G1) and on a small low-power PC (Gigabyte J1900N-D3V). No issues of any kind so far. I know this doesn't help you directly, but at least it's a data point. -- Greg ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Drastic slowdown for geli attach
Sometime around the first week of this month (February) the time to do a geli attach on my 13.0-ALPHA3 amd64 system sharply increased. It started taking about 10 seconds. Prior to this, it took about 3-4 seconds. I have not seen any issues with the disc after it attaches, I am simply concerned that the longer time may be indicative of a deeper issue. The system is a ThinkPad L15 with a CometLake i5-10210U and a Seagate ST2000LM007-1R8174 2T HDD. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-EN-21:07.caroot.asc question
On Wed, Feb 24, 2021 at 06:42:17PM -0600, Greg Balfour wrote: > After installing the security and errata patches that came out today > on my 12.2-RELEASE system, I see the following during the "make > installworld" step. Is this the expected output after removing > certificates from the root certificate bundle or did something go > wrong? > > [...] > -- > >>> Installing everything completed on Wed Feb 24 18:16:59 CST 2021 > -- > Scanning /usr/share/certs/blacklisted for certificates... > Scanning /usr/share/certs/trusted for certificates... > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: /usr/share/certs/trusted/GeoTrust_Global_CA.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: /usr/share/certs/trusted/GeoTrust_Primary_Certification_Authority.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: > /usr/share/certs/trusted/GeoTrust_Primary_Certification_Authority_-_G3.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: /usr/share/certs/trusted/GeoTrust_Universal_CA.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: /usr/share/certs/trusted/GeoTrust_Universal_CA_2.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: > /usr/share/certs/trusted/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: > /usr/share/certs/trusted/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: /usr/share/certs/trusted/thawte_Primary_Root_CA.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: /usr/share/certs/trusted/thawte_Primary_Root_CA_-_G2.pem > unable to load certificate > 34371108864:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED CERTIFICATE > Error: /usr/share/certs/trusted/thawte_Primary_Root_CA_-_G3.pem Patch does not remove empty files unless "-E" switch is used. The pem files above are propably empty and you have to remove them manually (both in /usr/src and /usr/share). Why are you not using svn/git to update /usr/src? -- Herbert ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD-EN-21:07.caroot.asc question
After installing the security and errata patches that came out today on my 12.2-RELEASE system, I see the following during the "make installworld" step. Is this the expected output after removing certificates from the root certificate bundle or did something go wrong? [...] -- >>> Installing everything completed on Wed Feb 24 18:16:59 CST 2021 -- Scanning /usr/share/certs/blacklisted for certificates... Scanning /usr/share/certs/trusted for certificates... unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/GeoTrust_Global_CA.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/GeoTrust_Primary_Certification_Authority.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/GeoTrust_Primary_Certification_Authority_-_G3.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/GeoTrust_Universal_CA.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/GeoTrust_Universal_CA_2.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/thawte_Primary_Root_CA.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/thawte_Primary_Root_CA_-_G2.pem unable to load certificate 34371108864:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /usr/share/certs/trusted/thawte_Primary_Root_CA_-_G3.pem ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How do I know if my 13-stable has security patches?
On Wed, 24 Feb 2021 at 12:35, Kevin Oberman wrote: > > In the svn days, I could just look at my svn revision to check on whether a > security patch was required. Now I have a git hash. I have no idea how to > tell if my system running 13-STABLE of a few days ago has the patch. Thanks for posting this question. I see some useful information in other replies to this thread and we'll want to make sure that makes its way to appropriate documentation. For future advisories we should also report the commit count associated with the fix; this is a monotonically-increasing number and is reported in the uname. If you build stable/13 right now you would get "stable/13-n244668-4664afc05402", and the fix in 894360bacd42f021551f76518edd445f6d299f2e corresponds to n244572. 244668 being larger than 244572 indicates that the fix is included. These counts are not unique across different branches; you can only compare counts for the same branch. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 13-BETA3 installation from source problems.
W dniu 24.02.2021 o 20:03, Kyle Evans pisze:
On Wed, Feb 24, 2021 at 12:57 PM Dean E. Weimer wrote:
On 2021-02-23 12:34 pm, Kyle Evans wrote:
The more I look at `make -dm` output, the less sense it makes. Your
patch is decidedly correct regardless of how this specific scenario is
playing out:
1.) As you noted, it's wrong to clean something that's built
elsewhere. You can reasonably expect `make clean all` to work pretty
much everywhere else.
2.) i386/loader cannot make an informed decision about whether it's
out-of-date, which is sufficient to tell that the existing addition to
OBJS was not the correct implementation in hindsight.
3.) The failure mode if it's *missing* is exactly the same before and
after your patch; file can't be found, cannot build it.
On Tue, Feb 23, 2021 at 12:09 PM Warner Losh wrote:
I'm unsure of the mechanics as well. I do know that we shouldn't
delete stuff in OTHER directories, though. the btx stuff is trying to
do a bit of an end run around the link only with the installed stuff
here and using crt0.o as a library from the 'where it was built'
directory which I think creates one too many dependencies... I've not
yet puzzled through all of them to find out which one is causing us to
think we need to rebuild though.
Warner
On Tue, Feb 23, 2021 at 9:21 AM Kyle Evans wrote:
Hi,
What I don't understand here is, why are these being considered
out-of-date? That seems like it is indicative of a larger problem
that
we'd surely fall over elsewhere on if not for here, that the source
tree's timestamps are post-dated w.r.t. the objdir.
Thanks,
Kyle Evans
On Mon, Feb 22, 2021 at 5:52 PM Warner Losh wrote:
What does this patch do for you?
diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefile
index ad95948ec50a..cbbe15bd1fc0 100644
--- a/stand/i386/loader/Makefile
+++ b/stand/i386/loader/Makefile
@@ -90,7 +90,8 @@ FILES+= ${LOADER}
FILESMODE_${LOADER}= ${BINMODE} -b
# XXX crt0.o needs to be first for pxeboot(8) to work
-OBJS= ${BTXCRT}
+# Can't add it to OBJS w/o pain and suffering
+LDFLAGS+= ${BTXCRT}
DPADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
LDADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
Anything?
Warner
On Mon, Feb 22, 2021 at 4:17 PM Dean E. Weimer wrote:
On 2021-02-22 10:53 am, Dean E. Weimer wrote:
On 2021-02-22 9:38 am, Dean E. Weimer via freebsd-stable wrote:
On 2021-02-22 9:29 am, Warner Losh wrote:
On Mon, Feb 22, 2021 at 8:24 AM Dean E. Weimer via freebsd-stable
wrote:
I was able to successfully build and install BETA2 from source,
however
I am now attempting to upgrade the same machine to BETA3 buildworld
and
buildkernel complete. installkernel also completes, but installworld
fails, it appears to not find a file for i386 boot.
/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/stand/i386/btx/btx/btx
-l boot2.ldr -o boot2.ld -P 1 boot2.bin
make[6]: exec(btxld) failed (No such file or directory)
Does this happen every time, or only sometimes? Do you have the
complete log? Why we're trying to run btxld and objcopy in the
*INSTALL* phase is likely why (paths are different between the two)
Warner
mail to "freebsd-stable-unsubscr...@freebsd.org"
Everytime, not sure why I am trying to run btxld and objcopy in
install phase, I am simply running the command make installworld
I do use env variables to change paths, as I install to a ZFS clone of
the original system dataset then change boot setting on pool and
reboot.
Environment Variables used during build and install, been doing this
process ever since I started using ZFS boot on FreeBSD 9.2.
setenv MAKEOBJDIRPREFIX /jails/devel/ROOT/usr/obj
setenv DESTDIR /jails/devel/ROOT
setenv __MAKE_CONF /jails/devel/ROOT/etc/make.conf
setenv SRCCONF /jails/devel/ROOT/etc/src.conf
I had already started a new build specifying CPUTYPE=silvermont in
make.conf, as attempt work around. It failed as well. I did check and
the path above exists on the system
:/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/stand/i386/btx/btx
# ll
total 10
-rw-r--r-- 1 root wheel 117B Feb 22 10:13 .depend.btx.o
-rwxr-xr-x 1 root wheel 1.7K Feb 22 10:37 btx*
-rw-r--r-- 1 root wheel 5.4K Feb 22 10:13 btx.o
drwxr-xr-x 2 root wheel 4B Feb 22 10:13 include/
I have removed my CPU Type specification and will run a new make and
install capturing full logs so that I can post a link to full logs.
I did a new build and capture output from full buildworld and
installworld, but first I cleared ccache same error was a result.
Here is the entire output along with my make.conf and src.conf files.
https://nextcloud.dweimer.net/index.php/s/YYx6WX7KieatM9L
--
Thanks,
Dean E. Weimer
http://www.dweimer.net/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to
Re: 11.4-STABLE - libcxxrt changes (?) broke libreoffice
On 24 Feb 2021, at 19:13, Dimitry Andric wrote: > > On 24 Feb 2021, at 16:04, Bengt Ahlgren wrote: >> >> After updating my laptop with 11.4-STABLE to r369345, libreoffice >> (7.0.3.1_2) just exits with "Application Error". Going back to >> 11.4-STABLE r369313, before the libcxxrt changes, makes the same >> libreoffice binary work again. >> >> I build libreoffice with the KF5, QT5 and JAVA options on, in a 11.4-REL >> poudriere jail. >> >> I didn't see any other application crashes. > > This is likely fixed by: > https://cgit.freebsd.org/src/commit/?id=d149877758f162f0c777e7760164bf2c1f7a1bc1 > > for which the MFC timer will expire tomorrow, then I will commit the fix. Since this can cause crashes, I've fast-tracked the MFC: stable/11: https://cgit.freebsd.org/src/commit/?id=696961f67c5eaabe03713dbf1b4fc2b7a0ce1cb1 or: https://svnweb.freebsd.org/base?view=revision=369363 stable/12: https://cgit.freebsd.org/src/commit/?id=64809c763b0c73fe488b61601670067056b07780 or: https://svnweb.freebsd.org/base?view=revision=369362 stable/13: https://cgit.freebsd.org/src/commit/?id=1c1460747efd44eb74762b960883656b56134e30 (Note stable/13 is not exported to Subversion.) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: 13-BETA3 installation from source problems.
Also doing ls -lR from the obj sir for stand before and after installworld
might preserve data that may help.
Warner
On Wed, Feb 24, 2021, 12:04 PM Kyle Evans wrote:
> On Wed, Feb 24, 2021 at 12:57 PM Dean E. Weimer
> wrote:
> >
> > On 2021-02-23 12:34 pm, Kyle Evans wrote:
> > > The more I look at `make -dm` output, the less sense it makes. Your
> > > patch is decidedly correct regardless of how this specific scenario is
> > > playing out:
> > >
> > > 1.) As you noted, it's wrong to clean something that's built
> > > elsewhere. You can reasonably expect `make clean all` to work pretty
> > > much everywhere else.
> > >
> > > 2.) i386/loader cannot make an informed decision about whether it's
> > > out-of-date, which is sufficient to tell that the existing addition to
> > > OBJS was not the correct implementation in hindsight.
> > >
> > > 3.) The failure mode if it's *missing* is exactly the same before and
> > > after your patch; file can't be found, cannot build it.
> > >
> > > On Tue, Feb 23, 2021 at 12:09 PM Warner Losh wrote:
> > >>
> > >> I'm unsure of the mechanics as well. I do know that we shouldn't
> > >> delete stuff in OTHER directories, though. the btx stuff is trying to
> > >> do a bit of an end run around the link only with the installed stuff
> > >> here and using crt0.o as a library from the 'where it was built'
> > >> directory which I think creates one too many dependencies... I've not
> > >> yet puzzled through all of them to find out which one is causing us to
> > >> think we need to rebuild though.
> > >>
> > >> Warner
> > >>
> > >> On Tue, Feb 23, 2021 at 9:21 AM Kyle Evans
> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> What I don't understand here is, why are these being considered
> > >>> out-of-date? That seems like it is indicative of a larger problem
> > >>> that
> > >>> we'd surely fall over elsewhere on if not for here, that the source
> > >>> tree's timestamps are post-dated w.r.t. the objdir.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Kyle Evans
> > >>>
> > >>> On Mon, Feb 22, 2021 at 5:52 PM Warner Losh wrote:
> > >>> >
> > >>> > What does this patch do for you?
> > >>> >
> > >>> > diff --git a/stand/i386/loader/Makefile
> b/stand/i386/loader/Makefile
> > >>> > index ad95948ec50a..cbbe15bd1fc0 100644
> > >>> > --- a/stand/i386/loader/Makefile
> > >>> > +++ b/stand/i386/loader/Makefile
> > >>> > @@ -90,7 +90,8 @@ FILES+= ${LOADER}
> > >>> > FILESMODE_${LOADER}= ${BINMODE} -b
> > >>> >
> > >>> > # XXX crt0.o needs to be first for pxeboot(8) to work
> > >>> > -OBJS= ${BTXCRT}
> > >>> > +# Can't add it to OBJS w/o pain and suffering
> > >>> > +LDFLAGS+= ${BTXCRT}
> > >>> >
> > >>> > DPADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
> > >>> > LDADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
> > >>> >
> > >>> > Anything?
> > >>> >
> > >>> > Warner
> > >>> >
> > >>> > On Mon, Feb 22, 2021 at 4:17 PM Dean E. Weimer <
> dwei...@dweimer.net> wrote:
> > >>> >
> > >>> > > On 2021-02-22 10:53 am, Dean E. Weimer wrote:
> > >>> > > > On 2021-02-22 9:38 am, Dean E. Weimer via freebsd-stable wrote:
> > >>> > > >> On 2021-02-22 9:29 am, Warner Losh wrote:
> > >>> > > >>
> > >>> > > >>> On Mon, Feb 22, 2021 at 8:24 AM Dean E. Weimer via
> freebsd-stable
> > >>> > > >>> wrote:
> > >>> > > >>>
> > >>> > > I was able to successfully build and install BETA2 from
> source,
> > >>> > > however
> > >>> > > I am now attempting to upgrade the same machine to BETA3
> buildworld
> > >>> > > and
> > >>> > > buildkernel complete. installkernel also completes, but
> installworld
> > >>> > > fails, it appears to not find a file for i386 boot.
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> /jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/stand/i386/btx/btx/btx
> > >>> > > -l boot2.ldr -o boot2.ld -P 1 boot2.bin
> > >>> > > make[6]: exec(btxld) failed (No such file or directory)
> > >>> > > >>>
> > >>> > > >>> Does this happen every time, or only sometimes? Do you have
> the
> > >>> > > >>> complete log? Why we're trying to run btxld and objcopy in
> the
> > >>> > > >>> *INSTALL* phase is likely why (paths are different between
> the two)
> > >>> > > >>>
> > >>> > > >>> Warner
> > >>> > > >>>
> > >>> > > mail to "freebsd-stable-unsubscr...@freebsd.org"
> > >>> > > >>
> > >>> > > >> Everytime, not sure why I am trying to run btxld and objcopy
> in
> > >>> > > >> install phase, I am simply running the command make
> installworld
> > >>> > > >>
> > >>> > > >> I do use env variables to change paths, as I install to a ZFS
> clone of
> > >>> > > >> the original system dataset then change boot setting on pool
> and
> > >>> > > >> reboot.
> > >>> > > >>
> > >>> > > >> Environment Variables used during build and install, been
> doing this
> > >>> > > >> process ever since I started using ZFS boot on FreeBSD 9.2.
> > >>> > > >>
> > >>> > > >> setenv MAKEOBJDIRPREFIX /jails/devel/ROOT/usr/obj
> > >>> >
Re: How do I know if my 13-stable has security patches?
Thanks, Olivier, for the quick response. Now I don't have to do a system
build!
Neither command is what I'd call 'intuitive', so it would have taken me a
long time to find either of them. I cut and pasted the 'git branch' command
and it took me a moment to realize what that meant. Never ran "grep -l" on
a pipe, I guess.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Wed, Feb 24, 2021 at 10:06 AM Olivier Certner
wrote:
> Hi,
>
> In your base git repository, type:
> git rev-list | grep -lF
>
> This outputs something ("(standard input)") iff you have it in.
>
> In order to limit the search time in case of a false result, you'd better
> pass
> the --since= to git rev-list.
>
> There is an alternative if you have a branch pointing to your uname hash:
> git branch --contains | grep -lF
>
> Regards.
>
> --
> Olivier Certner
>
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 13-BETA3 installation from source problems.
On Wed, Feb 24, 2021 at 12:57 PM Dean E. Weimer wrote:
>
> On 2021-02-23 12:34 pm, Kyle Evans wrote:
> > The more I look at `make -dm` output, the less sense it makes. Your
> > patch is decidedly correct regardless of how this specific scenario is
> > playing out:
> >
> > 1.) As you noted, it's wrong to clean something that's built
> > elsewhere. You can reasonably expect `make clean all` to work pretty
> > much everywhere else.
> >
> > 2.) i386/loader cannot make an informed decision about whether it's
> > out-of-date, which is sufficient to tell that the existing addition to
> > OBJS was not the correct implementation in hindsight.
> >
> > 3.) The failure mode if it's *missing* is exactly the same before and
> > after your patch; file can't be found, cannot build it.
> >
> > On Tue, Feb 23, 2021 at 12:09 PM Warner Losh wrote:
> >>
> >> I'm unsure of the mechanics as well. I do know that we shouldn't
> >> delete stuff in OTHER directories, though. the btx stuff is trying to
> >> do a bit of an end run around the link only with the installed stuff
> >> here and using crt0.o as a library from the 'where it was built'
> >> directory which I think creates one too many dependencies... I've not
> >> yet puzzled through all of them to find out which one is causing us to
> >> think we need to rebuild though.
> >>
> >> Warner
> >>
> >> On Tue, Feb 23, 2021 at 9:21 AM Kyle Evans wrote:
> >>>
> >>> Hi,
> >>>
> >>> What I don't understand here is, why are these being considered
> >>> out-of-date? That seems like it is indicative of a larger problem
> >>> that
> >>> we'd surely fall over elsewhere on if not for here, that the source
> >>> tree's timestamps are post-dated w.r.t. the objdir.
> >>>
> >>> Thanks,
> >>>
> >>> Kyle Evans
> >>>
> >>> On Mon, Feb 22, 2021 at 5:52 PM Warner Losh wrote:
> >>> >
> >>> > What does this patch do for you?
> >>> >
> >>> > diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefile
> >>> > index ad95948ec50a..cbbe15bd1fc0 100644
> >>> > --- a/stand/i386/loader/Makefile
> >>> > +++ b/stand/i386/loader/Makefile
> >>> > @@ -90,7 +90,8 @@ FILES+= ${LOADER}
> >>> > FILESMODE_${LOADER}= ${BINMODE} -b
> >>> >
> >>> > # XXX crt0.o needs to be first for pxeboot(8) to work
> >>> > -OBJS= ${BTXCRT}
> >>> > +# Can't add it to OBJS w/o pain and suffering
> >>> > +LDFLAGS+= ${BTXCRT}
> >>> >
> >>> > DPADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
> >>> > LDADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
> >>> >
> >>> > Anything?
> >>> >
> >>> > Warner
> >>> >
> >>> > On Mon, Feb 22, 2021 at 4:17 PM Dean E. Weimer
> >>> > wrote:
> >>> >
> >>> > > On 2021-02-22 10:53 am, Dean E. Weimer wrote:
> >>> > > > On 2021-02-22 9:38 am, Dean E. Weimer via freebsd-stable wrote:
> >>> > > >> On 2021-02-22 9:29 am, Warner Losh wrote:
> >>> > > >>
> >>> > > >>> On Mon, Feb 22, 2021 at 8:24 AM Dean E. Weimer via freebsd-stable
> >>> > > >>> wrote:
> >>> > > >>>
> >>> > > I was able to successfully build and install BETA2 from source,
> >>> > > however
> >>> > > I am now attempting to upgrade the same machine to BETA3
> >>> > > buildworld
> >>> > > and
> >>> > > buildkernel complete. installkernel also completes, but
> >>> > > installworld
> >>> > > fails, it appears to not find a file for i386 boot.
> >>> > >
> >>> > >
> >>> > >
> >>> > > /jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/stand/i386/btx/btx/btx
> >>> > > -l boot2.ldr -o boot2.ld -P 1 boot2.bin
> >>> > > make[6]: exec(btxld) failed (No such file or directory)
> >>> > > >>>
> >>> > > >>> Does this happen every time, or only sometimes? Do you have the
> >>> > > >>> complete log? Why we're trying to run btxld and objcopy in the
> >>> > > >>> *INSTALL* phase is likely why (paths are different between the
> >>> > > >>> two)
> >>> > > >>>
> >>> > > >>> Warner
> >>> > > >>>
> >>> > > mail to "freebsd-stable-unsubscr...@freebsd.org"
> >>> > > >>
> >>> > > >> Everytime, not sure why I am trying to run btxld and objcopy in
> >>> > > >> install phase, I am simply running the command make installworld
> >>> > > >>
> >>> > > >> I do use env variables to change paths, as I install to a ZFS
> >>> > > >> clone of
> >>> > > >> the original system dataset then change boot setting on pool and
> >>> > > >> reboot.
> >>> > > >>
> >>> > > >> Environment Variables used during build and install, been doing
> >>> > > >> this
> >>> > > >> process ever since I started using ZFS boot on FreeBSD 9.2.
> >>> > > >>
> >>> > > >> setenv MAKEOBJDIRPREFIX /jails/devel/ROOT/usr/obj
> >>> > > >> setenv DESTDIR /jails/devel/ROOT
> >>> > > >> setenv __MAKE_CONF /jails/devel/ROOT/etc/make.conf
> >>> > > >> setenv SRCCONF /jails/devel/ROOT/etc/src.conf
> >>> > > >
> >>> > > > I had already started a new build specifying CPUTYPE=silvermont in
> >>> > > > make.conf, as attempt work around. It failed as well. I did check
> >>> > > > and
> >>> > > >
Re: 13-BETA3 installation from source problems.
On 2021-02-23 12:34 pm, Kyle Evans wrote:
The more I look at `make -dm` output, the less sense it makes. Your
patch is decidedly correct regardless of how this specific scenario is
playing out:
1.) As you noted, it's wrong to clean something that's built
elsewhere. You can reasonably expect `make clean all` to work pretty
much everywhere else.
2.) i386/loader cannot make an informed decision about whether it's
out-of-date, which is sufficient to tell that the existing addition to
OBJS was not the correct implementation in hindsight.
3.) The failure mode if it's *missing* is exactly the same before and
after your patch; file can't be found, cannot build it.
On Tue, Feb 23, 2021 at 12:09 PM Warner Losh wrote:
I'm unsure of the mechanics as well. I do know that we shouldn't
delete stuff in OTHER directories, though. the btx stuff is trying to
do a bit of an end run around the link only with the installed stuff
here and using crt0.o as a library from the 'where it was built'
directory which I think creates one too many dependencies... I've not
yet puzzled through all of them to find out which one is causing us to
think we need to rebuild though.
Warner
On Tue, Feb 23, 2021 at 9:21 AM Kyle Evans wrote:
Hi,
What I don't understand here is, why are these being considered
out-of-date? That seems like it is indicative of a larger problem
that
we'd surely fall over elsewhere on if not for here, that the source
tree's timestamps are post-dated w.r.t. the objdir.
Thanks,
Kyle Evans
On Mon, Feb 22, 2021 at 5:52 PM Warner Losh wrote:
>
> What does this patch do for you?
>
> diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefile
> index ad95948ec50a..cbbe15bd1fc0 100644
> --- a/stand/i386/loader/Makefile
> +++ b/stand/i386/loader/Makefile
> @@ -90,7 +90,8 @@ FILES+= ${LOADER}
> FILESMODE_${LOADER}= ${BINMODE} -b
>
> # XXX crt0.o needs to be first for pxeboot(8) to work
> -OBJS= ${BTXCRT}
> +# Can't add it to OBJS w/o pain and suffering
> +LDFLAGS+= ${BTXCRT}
>
> DPADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
> LDADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32}
>
> Anything?
>
> Warner
>
> On Mon, Feb 22, 2021 at 4:17 PM Dean E. Weimer wrote:
>
> > On 2021-02-22 10:53 am, Dean E. Weimer wrote:
> > > On 2021-02-22 9:38 am, Dean E. Weimer via freebsd-stable wrote:
> > >> On 2021-02-22 9:29 am, Warner Losh wrote:
> > >>
> > >>> On Mon, Feb 22, 2021 at 8:24 AM Dean E. Weimer via freebsd-stable
> > >>> wrote:
> > >>>
> > I was able to successfully build and install BETA2 from source,
> > however
> > I am now attempting to upgrade the same machine to BETA3 buildworld
> > and
> > buildkernel complete. installkernel also completes, but installworld
> > fails, it appears to not find a file for i386 boot.
> >
> > I do have a customized src.conf
> > WIHTOUT_FLOPPY="YES"
> > WITHOUT_FREEBSD_UPDATE="YES"
> > WITH_BSD_GREP="YES"
> > WITHOUT_BLUETOOTH="YES"
> > WITHOUT_PORTSNAP="YES"
> > WITHOUT_WIRELESS="YES"
> > WITHOUT_WPA_SUPPLICANT_EAPOL="YES"
> > WITHOUT_ATM="YES"
> > WITHOUT_LPR="YES"
> > WITHOUT_PPP="YES"
> > WITHOUT_LLDB="YES"
> > WITHOUT_FTP="YES"
> > WITHOUT_RBOOTD="YES"
> > WITHOUT_TALK="YES"
> > WITHOUT_NTP="YES"
> > WITH_ISCSI="YES"
> > WITH_REPRODUCIBLE_BUILD="YES"
> > WITHOUT_GNU_DIFF="YES"
> > WITH_KERNEL_RETPOLINE="YES"
> >
> > and customized make.conf
> > CFLAGS?= -O
> > CLFAGS+= -pipe
> > NO_CPU_CFLAGS=
> > MK_WERROR=no
> >
> > WITH_CCACHE_BUILD= YES
> > OPTIONS_SET= LIBEDIT OPTIMIZED_CFLAGS GSSAPI_NONE
> > OPTIONS_UNSET= X11 X GUI TLS_SRP AVAHI GSSAPI_BASE XPM CUPS EXAMPLES
> > DOCS
> > WRKDIRPREFIX= /var/ports
> > PACKAGES= /var/ports/packages
> > WITH_PKGNG= YES
> > DEFAULT_VERSIONS= pgsql=13 php=80 apache=2.4 perl5=5.32 bdb=6
> > mysql=105m
> > ssl=openssl python=3.9 python3=3.9 gcc=9 linux=c7 samba=4.13
> >
> > .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) &&
> > !defined(NOCCACHE)
> > CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
> > CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
> > .endif
> > .if (!empty(.CURDIR:M/jails/devel/ROOT/usr/src*) ||
> > !empty(.CURDIR:M/jails/devel/ROOT/usr/obj*)) && !defined(NOCCACHE)
> > CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
> > CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
> > .endif
> >
> > Here's the part of where it fails during the install, src tree was
> > checked out at commit 1d0d443daa570c8eaa60ec2c2accbe19554a6c12.
> >
> > ...
> > ===> stand/userboot (install)
> > ===> stand/userboot/test (install)
> > ===> stand/userboot/userboot_4th (install)
> > install -o root -g wheel -m 444 -S userboot_4th.so
> >
Re: 11.4-STABLE - libcxxrt changes (?) broke libreoffice
On 24 Feb 2021, at 16:04, Bengt Ahlgren wrote: > > After updating my laptop with 11.4-STABLE to r369345, libreoffice > (7.0.3.1_2) just exits with "Application Error". Going back to > 11.4-STABLE r369313, before the libcxxrt changes, makes the same > libreoffice binary work again. > > I build libreoffice with the KF5, QT5 and JAVA options on, in a 11.4-REL > poudriere jail. > > I didn't see any other application crashes. This is likely fixed by: https://cgit.freebsd.org/src/commit/?id=d149877758f162f0c777e7760164bf2c1f7a1bc1 for which the MFC timer will expire tomorrow, then I will commit the fix. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: How do I know if my 13-stable has security patches?
Hi,
In your base git repository, type:
git rev-list | grep -lF
This outputs something ("(standard input)") iff you have it in.
In order to limit the search time in case of a false result, you'd better pass
the --since= to git rev-list.
There is an alternative if you have a branch pointing to your uname hash:
git branch --contains | grep -lF
Regards.
--
Olivier Certner
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
How do I know if my 13-stable has security patches?
In the svn days, I could just look at my svn revision to check on whether a security patch was required. Now I have a git hash. I have no idea how to tell if my system running 13-STABLE of a few days ago has the patch. Branch/path Revision - - stable/13/ 894360bacd42f021551f76518edd445f6d299f2e releng/13.0/ 9f00cb5fa8a438e7b9efb2158f2e2edc730badd1 stable/12/r369312 releng/12.2/ r369353 Is there a git command that can confirm whether a given hash is covered in my system? -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
11.4-STABLE - libcxxrt changes (?) broke libreoffice
After updating my laptop with 11.4-STABLE to r369345, libreoffice (7.0.3.1_2) just exits with "Application Error". Going back to 11.4-STABLE r369313, before the libcxxrt changes, makes the same libreoffice binary work again. I build libreoffice with the KF5, QT5 and JAVA options on, in a 11.4-REL poudriere jail. I didn't see any other application crashes. Any clues? I can provide more info if needed. Bengt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: When did pkg(8) drop support for 12-stable?
> On Feb 23, 2021, at 9:02 PM, Chris wrote: > > On 2021-02-23 17:07, Brian W. wrote: >> 12-stable is not what you're running if you got that error. > # uname -apKU > FreeBSD fbsd12dev 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC amd64 > amd64 1201522 1201522 > Looks pretty STABLE to me. It may be -STABLE but it apparently hasn't been updated in a while. You're running FreeBSD version 1201522, which is some flavour of 12.1. As Warner pointed out, FreeBSD 12.1 has reached EOL, and is no longer officially supported by ports. By way of comparison, here is a 12-STABLE system I updated yesterday: gromit ~% uname -a FreeBSD gromit.dlib.vt.edu 12.2-STABLE FreeBSD 12.2-STABLE stable/12-n232755-dfb372f5d38c GENERIC amd64 gromit ~% uname -U 1202505 If you want to continue to use ports on that system I suggest you do a source upgrade to at least 12.2-STABLE (or else install a 12.2-STABLE snapshot). Cheers, Paul. > > --Chris >> Run freebsd-update with appropriate args to get to a later release is the >> easiest option. >> Brian >> On Tue, Feb 23, 2021, 5:04 PM Warner Losh wrote: >>> On Tue, Feb 23, 2021, 4:51 PM Chris wrote: >>> > Given this is a pkg(8) error, I brought it up on ports@ >>> > but it was suggested I (also?) bring it up here on stable@ >>> > >>> > OK awhile back I installed a copy of 12 stable from the >>> > usb stick image. I tweaked it to my wishes then got called >>> > away and haven't been able to get back to it until the other >>> > day. This is still a fresh install which has a populated /usr/src. >>> > So I >>> > svnlite co svn://svn.freebsd.org/ports/head /usr/ports >>> > followed by a >>> > cd /usr/ports/ports-mgmt/pkg/ && make install clean >>> > which returns >>> > make >>> > /!\ ERROR: /!\ >>> > >>> > Ports Collection support for your FreeBSD version has ended, and no ports >>> > are >>> > guaranteed to build on this system. Please upgrade to a supported >>> release. >>> > >>> > No support will be provided if you silence this message by defining >>> > ALLOW_UNSUPPORTED_SYSTEM. >>> > >>> > *** Error code 1 >>> > >>> > Stop. >>> > Err what? Ok while I think this was from stable 12.1, it's still still >>> 12, >>> > and it's on stable. So what gives? >>> > >>> 12.1 has reached EOL now that 12.2 has been out a while. >>> Warner >>> Thanks in advance for any enlightenment. >>> > >>> > --Chris > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
