Re: aarch64 (not armv7) kyua run on main [so: 14]: sys/net/if_lagg_test:status_stress got "Fatal data abort" panic [14.0-ALPHA1 snapshot panic submitted to bugzilla]
On Aug 9, 2023, at 22:30, Mark Millard wrote: > The context is on a Windows Dev Kit 2023, using a bectl based boot/root disk: > > # uname -apKU > FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400094 #9 > main-n264643-0befc55cdf4b-dirty: Wed Aug 9 14:23:48 PDT 2023 > root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-dbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-DBG-CA78C > arm64 aarch64 1400094 1400094 > > I only do bugzailla submittals based on just my > own builds as a means of last resort: I try to > use official builds for such. The: > > main-n264491-8a5c836b51ce: Thu Aug 3 > > snapshot did not panic on the RPi4B that I > tried it with. We will see for the next > snapshot at some point. > > Both the non-debug and the debug kernels panic. > I saw no evidence of the debug kernel reporting > anything. > > Note the: > > 0xdeadc0dedeadc0de (2 examples) > and: > 0xfefefefefefefeff (1 example) > > that may have some significance. > > . . . > sys/net/if_gif:basic -> passed [0.195s] > sys/net/if_lagg_test:create -> passed [0.125s] > sys/net/if_lagg_test:create_destroy_stress -> skipped: Skipping this test > because it easily panics the machine [0.022s] > sys/net/if_lagg_test:lacp_linkstate_destroy_stress -> passed [60.048s] > sys/net/if_lagg_test:set_ether -> passed [0.090s] > sys/net/if_lagg_test:status_stress -> > > <6>lagg0: link state changed to DOWN > Fatal data abort: > x0: 0x000186c82858 (_DYNAMIC + 0x271e46b8) > x1: 0x0001 > x2: 0xdeadc0dedeadc0de > x3: 0x005b68c0 (ifdead_ioctl + 0x0) > x4: 0xa000a8ba305e > x5: 0xa00023d932fa > x6: 0x6767616c > x7: 0x6e6d760070617401 > x8: 0x030c > x9: 0x00210005 > x10: 0x0800 > x11: 0xfefefefefefefeff > x12: 0x0008 > x13: 0x > x14: 0x0001 > x15: 0x0001 > x16: 0x0001 > x17: 0x0007 > x18: 0x000186c82520 > <6>ue0: link state changed to DOWN > (_DYNAMIC + 0x271e4380) > x19: 0x000186c82858 (_DYNAMIC + 0x271e46b8) > x20: 0xa000a8ba3000 > x21: 0xa000a8ba3058 > x22: 0x000c > x23: 0x0005 > x24: 0x > x25: 0x00c7a000 (keysw + 0xb8) > x26: 0x > x27: 0x00cf9000 (sdta_vfs_vop_vop_spare4_return1 + 0x18) > x28: 0x0008 > x29: 0x000186c82540 (_DYNAMIC + 0x271e43a0) > sp: 0x000186c82520 > lr: 0x006a0b50 (dump_iface + 0x2c0) > elr: 0x006a124c (dump_sa + 0x1c) > spsr: 0x00400045 > far: 0xdeadc0dedeadc0df > esr: 0x9604 > timeout stopping cpus > panic: vm_fault failed: 0x006a124c error 1 > cpuid = 2 > time = 1691642123 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x13c > panic() at panic+0x44 > data_abort() at data_abort+0x358 > handle_el1h_sync() at handle_el1h_sync+0x14 > --- exception, esr 0x9604 > dump_sa() at dump_sa+0x1c > dump_iface() at dump_iface+0x2bc > dump_cb() at dump_cb+0x18 > if_foreach_sleep() at if_foreach_sleep+0x208 > rtnl_handle_getlink() at rtnl_handle_getlink+0xec > rtnl_handle_message() at rtnl_handle_message+0x19c > nl_taskqueue_handler() at nl_taskqueue_handler+0x5f4 > taskqueue_run_locked() at taskqueue_run_locked+0x1a4 > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 > > This was from: > > # /usr/bin/kyua test -k /usr/tests/Kyuafile > > But the earlier part of the run is not > needed to get the panic. Booting, logging > in as root, and doing: > > # /usr/bin/kyua test -k /usr/tests/Kyuafile sys/net/if_lagg_test:status_stress > > is sufficient to get the panic in my context. > > > For reference for the RPi4B not getting the panic: > > Trying on an RPi4B with a somewhat older snapshot did not panic: > > # uname -apKU > you have mail > FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400093 #0 > main-n264491-8a5c836b51ce: Thu Aug 3 12:10:50 UTC 2023 > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > aarch64 1400093 1400093 > > # /usr/bin/kyua test -k /usr/tests/Kyuafile sys/net/if_lagg_test:status_stress > sys/net/if_lagg_test:status_stress -> passed [60.371s] > > Results file id is usr_tests.20230804-151402-553517 > Results saved to /root/.kyua/store/results.usr_tests.20230804-151402-553517.db > > 1/1 passed (0 failed) I replicated the panic via an 14.0-ALPHA1 snapshot dd'd to USB media then used to boot and operate a Windows Dev Kit 2023. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273081 === Mark Millard marklmi at yahoo.com
ssh 9.4 fails to build
Hi, I get this error while building world. NB: I'm building with llvm15 from a pkg. But I don't think that should make a difference. ld.lld: error: undefined symbol: Fssh_lib_contains_symbol referenced by ssh-pkcs11.c:1538 (/usr/src/crypto/openssh/ssh-pkcs11.c:1538) ssh-pkcs11.o:(Fssh_pkcs11_add_provider) git reset --hard fixes the build for me. Regards, Ronald.
Re: ZFS deadlock in 14
The poudriere build machine building amd64 packages also panicked. But with:
Dumping 2577 out of 8122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91
%
__curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:59
59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu
,
(kgdb) #0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:5
9
#1 doadump (textdump=textdump@entry=1)
at /opt/src/git-src/sys/kern/kern_shutdown.c:407
#2 0x806c10e0 in kern_reboot (howto=260)
at /opt/src/git-src/sys/kern/kern_shutdown.c:528
#3 0x806c15df in vpanic (
fmt=0x80b6c5f5 "%s: possible deadlock detected for %p (%s),
blocked
for %d ticks\n", ap=ap@entry=0xfe008e698e90)
at /opt/src/git-src/sys/kern/kern_shutdown.c:972
#4 0x806c1383 in panic (fmt=)
at /opt/src/git-src/sys/kern/kern_shutdown.c:896
#5 0x8064a5ea in deadlkres ()
at /opt/src/git-src/sys/kern/kern_clock.c:201
#6 0x80677632 in fork_exit (callout=0x8064a2c0 ,
arg=0x0, frame=0xfe008e698f40)
at /opt/src/git-src/sys/kern/kern_fork.c:1162
#7
(kgdb)
This is consistent with PR/271945. Reducing -J to 1 or 5:1 circumvents this
panic.
This is certainly a different panic from the one experienced on the
poudriere builder building i386 packages. Both machines run in amd64 mode.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
Cy Schubert writes:
> This is new. Instead of affecting the machine with poudriere building amd64
> packages, it affected the other machine with poudriere building i386
> packages. This is new since the two recent ZFS patches.
>
> Don't get me wrong, the two new patches have resulted in I believe better
> availability of the poudriere machine building amd64 packages. I doubt the
> two patches caused this but they may have exposed this problem, probably
> fixed by another patch or two.
>
> Sorry, there was no dump produced by this panic. I'll need to check the
> config of this machine, swap is a gmirror, which it doesn't like to dump
> to. Below are serial console messages captured by conserver.
>
> panic: vm_page_dequeue_deferred: page 0xfe00028fb0d0 has unexpected
> queue state^M
> cpuid = 3^M
> time = 1691807572^M
> KDB: stack backtrace:^M
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe00c50bc600^M
> vpanic() at vpanic+0x132/frame 0xfe00c50bc730^M
> panic() at panic+0x43/frame 0xfe00c50bc790^M
> vm_page_dequeue_deferred() at vm_page_dequeue_deferred+0xb2/frame
> 0xfe00c50bc7a0^M
> vm_page_free_prep() at vm_page_free_prep+0x11b/frame 0xfe00c50bc7c0^M
> vm_page_free_toq() at vm_page_free_toq+0x12/frame 0xfe00c50bc7f0^M
> vm_object_page_remove() at vm_object_page_remove+0xb6/frame
> 0xfe00c50bc850^M
> vn_pages_remove_valid() at vn_pages_remove_valid+0x48/frame
> 0xfe00c50bc880^M
> zfs_rezget() at zfs_rezget+0x35/frame 0xfe00c50bca60^M
> zfs_resume_fs() at zfs_resume_fs+0x1c8/frame 0xfe00c50bcab0^M
> zfs_ioc_rollback() at zfs_ioc_rollback+0x157/frame 0xfe00c50bcb00^M
> zfsdev_ioctl_common() at zfsdev_ioctl_common+0x612/frame
> 0xfe00c50bcbc0^M
> zfsdev_ioctl() at zfsdev_ioctl+0x12a/frame 0xfe00c50bcbf0^M
> devfs_ioctl() at devfs_ioctl+0xd2/frame 0xfe00c50bcc40^M
> vn_ioctl() at vn_ioctl+0xc2/frame 0xfe00c50bccb0^M
> devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfe00c50bccd0^M
> kern_ioctl() at kern_ioctl+0x286/frame 0xfe00c50bcd30^M
> sys_ioctl() at sys_ioctl+0x152/frame 0xfe00c50bce00^M
> amd64_syscall() at amd64_syscall+0x138/frame 0xfe00c50bcf30^M
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00c50bcf30^M
> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x20938296107a, rsp =
> 0x209379aeee18, rbp = 0x209379aeee90 ---^M
> Uptime: 42m33s^M
> Automatic reboot in 15 seconds - press a key on the console to abort^M
> Rebooting...^M
> cpu_reset: Restarting BSP^M
> cpu_reset_proxy: Stopped CPU 3^M
>
>
> --
> Cheers,
> Cy Schubert
> FreeBSD UNIX: Web: https://FreeBSD.org
> NTP: Web: https://nwtime.org
>
> e^(i*pi)+1=0
>
>
> Cy Schubert writes:
> > I haven't experienced any problems (yet) either.
> >
> >
> > --
> > Cheers,
> > Cy Schubert
> > FreeBSD UNIX: Web: https://FreeBSD.org
> > NTP: Web: https://nwtime.org
> >
> > e^(i*pi)+1=0
> >
> >
> > In message c
> > om>
> > , Kevin Bowling writes:
> > > The two MFVs on head have improved/fixed stability with poudriere for
> > > me 48 core bare metal.
> > >
> > > On Thu, Aug 10, 2023 at 6:37=E2=80=AFAM Cy Schubert t.
> > =
> > > com> wrote:
> > > >
> > > > In message ai
> > =
> > > l.c
> > > > om>
> > > > , Kevin Bowling writes:
> > > > > Possibly https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049
> b4
> > =
> > > 0bd4=3D
> > > > > 42eb
Re: The future for support of BeagleBone Black and its variants
i wonder what's the latest point in repository that DOES work? my bbb runs current from year 2014, it does run well and off emmc. it's awfully crap compared to my h3 but i would still like to have something on it. when i started working with embedded hw again, i took that out of box too, expected to seamlessly run latest current on that still, only to found out that doesn't work... On Thursday, August 10, 2023, George Abdelmalik wrote: > Hi David, > > The problems are kernel related. If I understand correctly it's in the area of clock definitions I think but I've not properly studied the patches. > > DTC is good. > > Regards, > George. > > > On 10/8/23 14:52, David Chisnall wrote: >> >> Hi, >> >> What are the changes to the DTS files? If there are problems with DTC handling the new files, please can you raise issues here: https://github.com/davidchisnall/dtc/issues >> >> If there are problems with the kernel’s handling of the dtb, please ignore me. >> >> David >> >>> On 10 Aug 2023, at 13:24, George Abdelmalik wrote: >>> >>> Hi all, >>> >>> For a long while now CURRENT has not been working on the BBB due to incompatible upstream changes in vendor DTS files. I know there are some patches available which at least get FreeBSD running but those have yet to be incorporated into the project's repository. >>> >>> This leaves me with the feeling that BBB support in FreeBSD is on the path to being dropped. Is there someone from the FreeBSD project that could speak directly to this? >>> >>> As a user it would be helpful to know if I should be searching of an alternate SBC platform or another OS for my projects. >>> >>> If it still remains the plan to keep supporting BBB into 14.0 and beyond then I'd like to know what work is missing to make that happen. I'm willing and able to help. >>> >>> Regards, >>> George. >>> >>> >>> > >
Re: New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f)
On Fri, Aug 11, 2023 at 08:53:12PM +, Glen Barber wrote: [...] > FreeBSD/aarch64 UFS EC2 AMIs are available in the following regions: > [...] > > FreeBSD/aarch64 ZFS EC2 AMIs are available in the following regions: > [...] It was discovered that due to human error (my own) the arm64 are, as Colin put it very politely, are "lacking 'arminess'". So, unfortunately the arm64 AMIs for 14.0-ALPHA1 are incorrectly uploaded as amd64. But you will receive a message stating it is the incorrect architecture, which is better than passively failing. Apologies for the inconvenience. Glen signature.asc Description: PGP signature
Re: problem with poudriere && port ftp/curl
On Fri, Aug 11, 2023 at 3:00 PM Jan Beich wrote:
> Matthias Apitz writes:
>
> > I have the following problem with poudriere on 14-CURRENT and ports from
> > git head: every time when I start poudriere-bulk it removes a port
> > already compile fine (and all its dependent ports) with the message:
> >
> > ...
>
> > The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE.
> > I have not set anything about
> > this in the port's options or jail's make.conf.
> >
> > What can I do to fix this?
>
> Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} == base :?BASE
> :NONE}
> in OPTIONS_DEFAULT due ssl!=base in DEFAULT_VERSIONS via make.conf(5).
> Try filing a bug against ftp/curl.
>
> $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty make -V
> '${OPTIONS_DEFAULT:M*GSS*}'
> GSSAPI_BASE
> $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty DEFAULT_VERSIONS=ssl=openssl
> make -V '${OPTIONS_DEFAULT:M*GSS*}'
> GSSAPI_NONE
>
> See also
> https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=6d324c1f70c9
>
> I can't reproduce on -CURRENT when only using base OpenSSL 3.0.
>
There are several ports with this problem. Since VirtualBox (and
libvncserver) need openssl31, I now delete openssl31, upgrade ports as
required, and then "package add
/usr/ports/packages/All/openssl31-3.1.2.pkg" when finished.
Just today I hit openldap-client trying to use openssl31 even though
make.conf does not define it as default. Several other ports also don't
honor the fairly new USES=openssl and, if they find an openssl installed,
will use it. Since Aug. 1, I have had several other ports hit this issue.
You really, really don't want ports using openssl31 unless you are sure
that they or any port which they depend on are also using openssl31. If you
get shareable libraries with conflicts, it is a pain to clean them up.
Maybe a message to all committers that they need to be sure that
OPENSSLBASE is not used without USES=openssl. (At least I believe that is
the case.)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
Resent. Not yet sent from ML but later one was sent.
Adding @freebsd.org address of Enji, as gmail does not accept mails
from dec.sakura.ne.jp, which has neither DKIM functionality nor SPF
record.
On Thu, 10 Aug 2023 16:32:32 -0700
Enji Cooper wrote:
> > On Aug 10, 2023, at 4:00 PM, Tomoaki AOKI wrote:
> >
> > On Thu, 10 Aug 2023 18:09:54 -0400
> > Charlie Li wrote:
> >
> >> Enji Cooper wrote:
> >>> Hmm… All lang/python27 requiring ports should be marked BROKEN and
> >>> removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/.
> >> We can't entirely do that yet. Unfortunately, moinmoin, original mailman
> >> and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this.
> >> It was the case that Chrom{e,ium} and qt-webengine still had Python 2
> >> build bits but they've since migrated off.
> >>
> >> --
> >> Charlie Li
> >> …nope, still don't have an exit line.
> >
> > Can lang/tauthon used instead of lang/python27?
> > It's a fork of python27 and maintained (slowly) like [1].
>
> Lang/tauthon probably could be used instead.
Even if original upstream is abandoned, maintained fork would better be
allowed. If tauthon can be considered "well maintained", consumers of
python27 which is enough compatible with tauthon can switch to tauthon
and un-deprecated.
> > I don't use python nor tauthon directly, though.
> > I dislike languages killing backward compatibility... :-(
> >
> > I love C as even recent llvm/clang has an ability to compile K&R
> > codes, if proper options are set. This is how ALL computer languages
> > SHALL BE.
>
> The problem that python2 -> python3 was trying to solve was multifold: there
> were a variety of issues with the language, as defined in python2, which made
> the syntax changes going from 2 to 3 necessary.
>
> That being said, the whole “python2 is going away in 2020” was advertised
> well in advance (several years). If projects hadn’t done the work of getting
> off python2 by 2020, it’s their fault in not prioritizing that effort.
>
> The problem with packages like MoinMoin, etc, is that unless they’re
> completely isolated (vendor and provide all of their dependencies), they are
> likely developing pieces of software on vulnerable versions of third-party
> packages since many packages started yanking python2 support in the past
> couple years. Yanking python2 support allows third-party projects to be
> developed with more modern syntax niceties like the walrus operator, type
> hints, asyncio, etc. It’s not logical for pieces of software to not improve.
>
> Python is not C or Perl; the transition from 2 to 3 was particularly painful,
> but the changes were based on development that was over a decade in the
> making.
If I'm the project owner of python, I would have been decided to
abandon python and switch to different name because of backward
incompatibility. But unfortunately, they didn't do so.
If the software itself runs on python, I think you're completely right.
It should be rewritten.
But for softwares which uses python only on build time, staying on
python27 should be allowed.
In small projects, if the person who built the building environment
retired from the project and noone else can understand / maintain the
build system, the only selection is "stay there until someone who can
construct new build environment pops in". This could happen here and
there, unfortunately.
For example,
*Consider python27 and required py-* as bootstrapping tool.
*Build python27 and required py-* everytime the port is built
and cleanup afterwards, INSIDE PORTS WORKDIR.
*python27 and required py-* are listed in distinfo of each port which
requires python27 on build time only.
would allow lang/python27 to be deleted, if possible.
>
> Cheers,
> -Enji
--
Tomoaki AOKI
Re: problem with poudriere && port ftp/curl
Matthias Apitz writes:
> I have the following problem with poudriere on 14-CURRENT and ports from
> git head: every time when I start poudriere-bulk it removes a port
> already compile fine (and all its dependent ports) with the message:
>
> ...
> [00:00:40] Sanity checking the repository
> [00:00:40] Checking packages for incremental rebuild needs
> [00:00:43] Deleting curl-8.2.1.pkg: changed options
> [00:00:43] Pkg: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG
> -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER -GSSAPI_BASE
> -GSSAPI_HEIMDAL -GSSAPI_MIT +GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6
> -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL
> -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER
> +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD
> [00:00:43] New: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG
> -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER +GSSAPI_BASE
> -GSSAPI_HEIMDAL -GSSAPI_MIT -GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6
> -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL
> -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER
> +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD
>
> The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE.
> I have not set anything about
> this in the port's options or jail's make.conf.
>
> What can I do to fix this?
Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} == base :?BASE :NONE}
in OPTIONS_DEFAULT due ssl!=base in DEFAULT_VERSIONS via make.conf(5).
Try filing a bug against ftp/curl.
$ env -i __MAKE_CONF= PORT_DBDIR=/var/empty make -V '${OPTIONS_DEFAULT:M*GSS*}'
GSSAPI_BASE
$ env -i __MAKE_CONF= PORT_DBDIR=/var/empty DEFAULT_VERSIONS=ssl=openssl make
-V '${OPTIONS_DEFAULT:M*GSS*}'
GSSAPI_NONE
See also https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=6d324c1f70c9
I can't reproduce on -CURRENT when only using base OpenSSL 3.0.
New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f)
us-west-1 region: ami-0787e6281242abf6d us-west-2 region: ami-03cefc407842a342d af-south-1 region: ami-0c68744a09255cd6f eu-north-1 region: ami-03a8c5c6c975c21fe eu-west-3 region: ami-01628f4d91cd27838 eu-west-2 region: ami-048d52773d4c5951b eu-west-1 region: ami-08509c5c80c3f76de ap-northeast-3 region: ami-0f019caa2553e9e32 ap-northeast-2 region: ami-0530b6be4cc4aacb5 me-south-1 region: ami-0da15198205cfcbb5 ap-northeast-1 region: ami-085265d27a19ac1ed sa-east-1 region: ami-088793629d946492c ap-east-1 region: ami-08fb95cb26081ad70 ap-southeast-1 region: ami-0a93baf040c66ef6f ap-southeast-2 region: ami-01930838e9e02af78 ap-southeast-3 region: ami-0782f3c0b864440cb us-east-1 region: ami-05797b4ce30086ec8 us-east-2 region: ami-09d9ba200a69fdf4b These AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/amd64/base/ufs/14.0/ALPHA1 /aws/service/freebsd/amd64/base/zfs/14.0/ALPHA1 FreeBSD/aarch64 UFS EC2 AMIs are available in the following regions: ap-south-2 region: ami-0ad26c712ed21703e ap-south-1 region: ami-0d78067468fd0bcb6 eu-south-1 region: ami-0cd527d17120c6a90 eu-south-2 region: ami-01e65abee965e2db3 me-central-1 region: ami-0b9681861b9588a8c ca-central-1 region: ami-04d70ff4e96cbabc4 eu-central-1 region: ami-0f73415dc20c6a31b eu-central-2 region: ami-01c7c57fe8abaf3c3 us-west-1 region: ami-0d2a710906f75e8fa us-west-2 region: ami-081d8d32425e7a28b af-south-1 region: ami-020d95d6e12d5228b eu-north-1 region: ami-0a2046fc7bc924564 eu-west-3 region: ami-0e0820c7749bfb908 eu-west-2 region: ami-0cbae742029679a9b eu-west-1 region: ami-0ad7c9aad58a8ac60 ap-northeast-3 region: ami-038711def088bcc40 ap-northeast-2 region: ami-00c433eb5dfe51112 me-south-1 region: ami-05b716323f0d55a7d ap-northeast-1 region: ami-022a84a4bfb0eb57d sa-east-1 region: ami-0822c15bb844d501e ap-east-1 region: ami-07a476ee87b72b1db ap-southeast-1 region: ami-0a2b7f01594d3ddb3 ap-southeast-2 region: ami-0ebaa7495854d4149 ap-southeast-3 region: ami-0514e4d6e0b84c914 us-east-1 region: ami-0ef708c0543ef4e6d us-east-2 region: ami-0e6e30278f31e5199 FreeBSD/aarch64 ZFS EC2 AMIs are available in the following regions: ap-south-2 region: ami-017996823c96c9035 ap-south-1 region: ami-0b8ec2a97a04cf114 eu-south-1 region: ami-0a88a8c75e26a2163 eu-south-2 region: ami-06089c0a441283ec2 me-central-1 region: ami-05ab9bd2e9caa5163 ca-central-1 region: ami-05e29a10630656ec5 eu-central-1 region: ami-0bbc32820ccd9eaf3 eu-central-2 region: ami-05d6f8668eccef473 us-west-1 region: ami-0423b0ea5cb89d6db us-west-2 region: ami-09be1d7239500a0a4 af-south-1 region: ami-0582848dd402096ef eu-north-1 region: ami-0618b6ec751174e99 eu-west-3 region: ami-0a872817804a19b65 eu-west-2 region: ami-0c92d5475acf1b7d3 eu-west-1 region: ami-07570666ee48d199d ap-northeast-3 region: ami-0a3f1176c4b18e6aa ap-northeast-2 region: ami-0df2f3300043f8de5 me-south-1 region: ami-055b235d5a9509fea ap-northeast-1 region: ami-00b49714687388a53 sa-east-1 region: ami-0601e5e031c1a39c6 ap-east-1 region: ami-0ab9eadc1b93ccbb8 ap-southeast-1 region: ami-0448869593edac054 ap-southeast-2 region: ami-09599cff050b820db ap-southeast-3 region: ami-062bca65e04891708 us-east-1 region: ami-02a253c3b2fe8d11c us-east-2 region: ami-04424d02986e5e8fc These AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/arm64/base/ufs/14.0/ALPHA1 /aws/service/freebsd/arm64/base/zfs/14.0/ALPHA1 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-14.0-ALPHA1 % vagrant up == ISO CHECKSUMS == o 14.0-ALPHA1 amd64 GENERIC: SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-bootonly.iso) = b1f5b188c1ed61bc1210ac237dbfd8baabad94fc2b6f67a7f2f16f2c592404e05be5aee8a28e7f9facf9ae2ae3acec4695794d99a264b80bc3cf69da5f17c6d3 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-bootonly.iso.xz) = 70c4bce755511e2da2f21c9c90344ffe56accdc8a0b416956e837055072027b8558478dd446a7080a43aaac32887635cd4dda451158e0b3cb417ee8320e14f96 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-disc1.iso) = 7b9ec31a1e497b28b9df7f97ee7f55965892c0a2a8a1f44430bbf3a82d007c90a6f94ffc9606d41d5e5c7123111a9b879521394857015922c35fef1804d30e06 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-disc1.iso.xz) = 50506b103ed71e381d5dafcb7c9f3b157325fcd933b204bbd480376b8b1581ebe5386ce4e07385548b02a8ce2aa0e9ce46e91184f829a9254512ddabbd42a9eb SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-memstick.img) = e4b4207f3899b1ee117fb373057433977ca2c0afab3d7a957cbca3ce39d87b815ceb0d05e33cc7155c6d2afc1a70f317fdbac2e8c7cb20d04114c2992132f69
problem with poudriere && port ftp/curl
I have the following problem with poudriere on 14-CURRENT and ports from git head: every time when I start poudriere-bulk it removes a port already compile fine (and all its dependent ports) with the message: ... [00:00:40] Sanity checking the repository [00:00:40] Checking packages for incremental rebuild needs [00:00:43] Deleting curl-8.2.1.pkg: changed options [00:00:43] Pkg: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER -GSSAPI_BASE -GSSAPI_HEIMDAL -GSSAPI_MIT +GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6 -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD [00:00:43] New: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER +GSSAPI_BASE -GSSAPI_HEIMDAL -GSSAPI_MIT -GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6 -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE. I have not set anything about this in the port's options or jail's make.conf. What can I do to fix this? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Has the update procedure changed?
On Fri, 11 Aug 2023 15:27:46 +0200 Dag-Erling Smørgrav wrote: > Tomoaki AOKI writes: > > This can help new installation using release tarballs (official or > > locally built) or upgrading with overwriting using said tarballs, but > > how does freebsd-update? > > freebsd-update uses the same release process. > > DES > -- > Dag-Erling Smørgrav - d...@freebsd.org Ah, thanks! So just anyone running through source update like us are possibly bitten. -- Tomoaki AOKI
periodic daily produces ridiculously huge report files
Hi, I recently upgraded from 13-STABLE to MAIN, now at FreeBSD 14.0-ALPHA1 amd64 1400094 #12 main-n264689-580cadd6a5f0, a custom kernel compiled *without* IPv6 (WITHOUT_INET6=yes). Ever since either upgrading to MAIN or WITHOUT_INET6=yes [1] I noticed that periodic daily still runs in the morning failing to mail ridiculously huge report files (>= 90 *GB*). [1] Can't remember when this started. I believe to have found the step in periodic daily causing these huge files, but I do not know why: 1) I used to run default daily_status_network_netstat_flags="-d -W" in /etc/periodic.conf This normally produces an output like: MWN> netstat -i -d -W -n NameMtu NetworkAddress Ipkts Ierrs IdropOpkts Oerrs Coll Drop vtnet0 1490fa:16:3e:37:a7:35 963666 0 0 1145053 0 0 0 vtnet0- 1.2.3.4/32 1.2.3.4 859598 - - 1068898 - - - vtnet0- 10.20.30.40/32 10.20.30.40 12176 - -0 - - - vtnet0- 50.60.70.80/32 50.60.70.80 0 - -0 - - - vtnet0- 100.100.100.10/32 100.100.100.105200 - -0 - - - vtnet1*1500fa:16:3e:58:c8:c90 0 00 0 0 0 lo0 16384lo0 20 0 0 20 0 0 0 lo0 -- - -- - - - lo0 -- - -- - - - lo0 - 127.0.0.0/8127.0.0.1 20 - - 20 - - - bridge0149058:9c:fc:00:61:18 186483 0 0 173172 0 0 0 bridge0 - 10.2.2.0/2410.2.2.2546625 - - 6698 - - - bridge0 - 10.2.2.199/32 10.2.2.1995198 - -0 - - - bridge0 - 10.2.2.220/32 10.2.2.220 363021 - -0 - - - ipsec0 1400ipsec0 852284 0 0 1035859 0 0 0 ipsec0- 10.2.2.0/2410.2.2.250 391221 - - 941898 - - - pflog033152pflog0 0 0 049185 0 0 0 epair201a 149002:0a:28:51:b5:0a33154 0 032531 0 0 0 epair203a 1490 02:0b:44:a0:f4:0a 2807 0 0 2567 0 0 0 epair2a1490 02:22:d3:ae:82:0a 7635 0 0 5435 0 0 0 epair1a1490 02:61:a8:aa:89:0a 142474 0 0 132256 0 0 0 epair6a1490 02:b4:4a:c7:dd:0a 228 0 0 213 0 0 0 epair5a1490 02:ba:52:8a:6d:0a 185 0 0 170 0 0 0 But pretty often "netstat -i -d -W -n" produces garbage like spaces or "0". This fills /tmp pretty fast (luckily a compressed zfs filesystem) and my mta still tries to mail in the morning. 2) I modified /etc/periodic.conf to daily_status_network_netstat_flags="-d -W -4" This produces an output like: MWN> netstat -i -d -W -n -4 Name Mtu NetworkAddress Ipkts Ierrs Idrop Opkts Oerrs Coll Drop vtnet0 - 1.2.3.4/32 1.2.3.4 859590 - - 1068102 - - - vtnet0 - 10.20.30.40/32 10.20.30.40 11592 - - 0 - - - vtnet0 - 50.60.70.80/32 50.60.70.80 0 - - 0 - - - vtnet0 - 100.100.100.10/32 100.100.100.10 5192 - - 0 - - - lo0 - 127.0.0.0/8127.0.0.120 - - 20 - - - bridge0 - 10.2.2.0/2410.2.2.254 6623 - - 6696 - - - bridge0 - 10.2.2.199/32 10.2.2.199 5196 - - 0 - - - bridge0 - 10.2.2.220/32 10.2.2.220 363021 - - 0 - - - ipsec0 - 10.2.2.0/2410.2.2.250 391221 - - 941898 - - - This fixed my issue with periodic daily. But I would like to know, if this has to do with WITHOUT_INET6=yes or FreeBSD 14? Or something different ... Did someone of you experiences equal behaviour of "netstat -i -d -W"? Anyone with WITHOUT_INET6=yes willing to test this? Regards, Michael
Re: Has the update procedure changed?
Tomoaki AOKI writes: > This can help new installation using release tarballs (official or > locally built) or upgrading with overwriting using said tarballs, but > how does freebsd-update? freebsd-update uses the same release process. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: ps(1) bugs and problems
"Piotr P. Stefaniak" wrote: > I thought about this more and the change I proposed in > https://reviews.freebsd.org/D41231 seems unnecessarily complicated, > regardless of which characters will be chosen to denote going up and > down the process tree. ps -D'^$' suggests there are possibly more > characters to use and maybe even some kind of DSL is available. > > So a simpler option is to keep the new aspect of -d (that it traverses > the tree down, even if ps is given a list of PIDs) and add a -D that > would work the same, but the other direction. That is indeed cleaner, and whilst the new "-D" option would cover the particular use case I mentioned, the old sorting method with arbitary, and specific PIDS is still useful. How about reverting '-d', and adding "-D" for descending, and "-A" for ascending? Cheers, Jamie
