Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
On 26/11/24 18:29, Doug Moore wrote: I think @kib has found the source of the problem. I've attached an attempt to fix it. Thanks for your work! I have noticed this is already in base and upgraded successfully, issue is now solved for me. Sorry for the delay in reporting this. -- Guido Falsi
Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
On 26/11/2024 17:52, Mark Millard wrote: libsass.so.1.0.0 still has .got.plt starting with (this time): 2bed60 2bed70 2bed80 2bed90 . . . 2bffc0 2bffd0 2bffe0 2bfff0 2c 96cb2a00 a6cb2a00 ..*...*. 2c0010 b6cb2a00 c6cb2a00 ..*...*. 2c0020 d6cb2a00 e6cb2a00 ..*...*. 2c0030 f6cb2a00 06cc2a00 ..*...*. . . . FWIW, I am not sure if it's relevant but I am seeing a similar pattern of corruption on tmpfs although in a different context, on FreeBSD 13.3. Details: https://lists.freebsd.org/archives/freebsd-fs/2024-November/003855.html -- Andriy Gapon
Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
Andriy Gapon writes: > FWIW, I am not sure if it's relevant but I am seeing a similar pattern > of corruption on tmpfs although in a different context, on FreeBSD > 13.3. Not relevant at all. In this case the file is not actually corrupted but `install(1)` skips over some of it when copying because `SEEK_DATA` is implemented incorrectly. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
On 28/11/2024 13:42, Dag-Erling Smørgrav wrote: Andriy Gapon writes: FWIW, I am not sure if it's relevant but I am seeing a similar pattern of corruption on tmpfs although in a different context, on FreeBSD 13.3. Not relevant at all. In this case the file is not actually corrupted but `install(1)` skips over some of it when copying because `SEEK_DATA` is implemented incorrectly. Still could be relevant... I don't know the "true state" of my corrupted files, I only observe the consequences. And the files get some post-processing, then they are uploaded and originals are removed. So, the problem could be not during the write phase, but during the read phase of post-processing. -- Andriy Gapon
Re: Anybody seeing NextCloud crash?
Am 2024-11-15 16:13, schrieb Miroslav Lachman: On 15/11/2024 12:08, Alexander Leidinger wrote: Am 2024-11-15 11:14, schrieb Moin Rahman: Just for everyone else in the list, I have gone through some discussion with the original author of the mail and it seems to have some sort of regression with graphics/pecl-imagick. Whenever this php module is loaded php-fpm crashes on at least php82 and maybe later. This module actually may not support php82 and later. Or maybe there was some sort of new regression with some other commits down the line of ImageMagic. I can report that commenting out the imagick extension in LOCALBASE/etc/ php/ext-20-imagick.ini fixes the SIGILL I noticed after an pkg update (in my case I see it with www/piwigo). I am the maintainer of pecl-imagick port but I don't have pecl-imagick under PHP-FPM. I received similar report of crash few days ago privately (with PHP 8.3), but I really don't know what is going on here. There are some problems with recent updates of ImageMagick after which rebuild of pecl-imagick was required (revision bump needed). Can somebody of you test the rebuild of pecl-imagick from ports if it helps or not? Maybe another revision bump is required again. A bit late... I forgot about this. I can report that a rebuild and reinstall of pecl-imgick seems to fix my issue with piwigo (or whatever it tried to do before disabling pecl-imagick it doesn't try to do again now). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Request for Test: mail/milter-manager: Update to 2.2.7
Hello,
I don't know why but I have updated mail/milter-manager several times
regerdless of the fact that I myself don't use it at all.
And once again I happened to find newer version is released.
So I created patch to update mail/milter-manager to latest version
2.2.7.
But I can't test if it works fine because I don't know how to use it.
Then would someone please test attached patch?
Best Regards.
>From 4a6429a4ebc71eeb6c1eb58723cc3f6d1512f48c Mon Sep 17 00:00:00 2001
From: Yasuhiro Kimura
Date: Fri, 29 Nov 2024 08:56:57 +0900
Subject: [PATCH] mail/milter-manager: Update to 2.2.7
ChangeLog: https://github.com/milter-manager/milter-manager/releases
---
mail/milter-manager/Makefile | 14 ++---
mail/milter-manager/distinfo | 6 +++---
mail/milter-manager/files/patch-Makefile.in | 14 ++---
mail/milter-manager/files/patch-configure | 20 +-
.../files/patch-libev-4.19__ev.c | 18
mail/milter-manager/pkg-plist | 21 +++
6 files changed, 34 insertions(+), 59 deletions(-)
delete mode 100644 mail/milter-manager/files/patch-libev-4.19__ev.c
diff --git a/mail/milter-manager/Makefile b/mail/milter-manager/Makefile
index 94cb968a6772..44a376c1c382 100644
--- a/mail/milter-manager/Makefile
+++ b/mail/milter-manager/Makefile
@@ -1,6 +1,5 @@
PORTNAME= milter-manager
-DISTVERSION= 2.1.6
-PORTREVISION= 2
+DISTVERSION= 2.2.7
CATEGORIES=mail ruby
MASTER_SITES=
https://github.com/${PORTNAME}/${PORTNAME}/releases/download/${DISTVERSION}/
@@ -23,30 +22,21 @@ USE_LDCONFIG= yes
USE_RC_SUBR= milter-manager
GNU_CONFIGURE= yes
-GNU_CONFIGURE_MANPREFIX=${PREFIX}/share
CONFIGURE_ARGS=--with-html-dir=${DOCSDIR} \
--with-libev \
--with-package-platform=freebsd
INSTALL_TARGET=install-strip
-CFLAGS+= -fdeclspec
-
PORTDOCS= *
PORTEXAMPLES= *
OPTIONS_DEFINE=DOCS EXAMPLES
-.include
-
-.if ${COMPILER_TYPE} == clang
-CFLAGS+= -Wno-error=incompatible-function-pointer-types
-.endif
-
post-patch:
@${FIND} ${WRKSRC} -type f -name Makefile.in -exec \
${REINPLACE_CMD} -e "s#\$$(datadir)/@PACKAGE@#${DATADIR}#" \
-e "s#\$$(datarootdir)/\$$(PACKAGE)#${DATADIR}#" {} +
@${REINPLACE_CMD} -e "s#\$$(pkgdatadir)/sample#${EXAMPLESDIR}#"
${WRKSRC}/configure
-.include
+.include
diff --git a/mail/milter-manager/distinfo b/mail/milter-manager/distinfo
index 23d7e7f80a0f..dad7854b5039 100644
--- a/mail/milter-manager/distinfo
+++ b/mail/milter-manager/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP = 1644938800
-SHA256 (milter-manager-2.1.6.tar.gz) =
3e656abd3d60677b68a02e35b31d9f7b1d0939fe47dd38425618458b5a5e703f
-SIZE (milter-manager-2.1.6.tar.gz) = 6086564
+TIMESTAMP = 1732749037
+SHA256 (milter-manager-2.2.7.tar.gz) =
f5dc1bc5240856b68c50af164c5e1d90fba3dd7a55c7e8f5d45bfe8ea0858f7a
+SIZE (milter-manager-2.2.7.tar.gz) = 5278536
diff --git a/mail/milter-manager/files/patch-Makefile.in
b/mail/milter-manager/files/patch-Makefile.in
index f9ae17b5bbe1..7facf144d7d5 100644
--- a/mail/milter-manager/files/patch-Makefile.in
+++ b/mail/milter-manager/files/patch-Makefile.in
@@ -1,11 +1,11 @@
Makefile.in.orig 2018-03-18 11:34:18 UTC
+--- Makefile.in.orig 2024-11-21 01:59:51 UTC
+++ Makefile.in
-@@ -510,7 +510,7 @@ SUBDIRS = $(am__append_1) milter libmilt
- data test po build doc html license package vendor
+@@ -512,7 +512,7 @@ pkgconfig_DATA = milter-core.pc milter-client.pc milte
+
pkgconfigdir = $(prefix)/libdata/pkgconfig
pkgconfig_DATA = milter-core.pc milter-client.pc milter-server.pc \
-- milter-manager.pc libmilter.pc $(am__append_2)
-+ milter-manager.pc $(am__append_2)
+- milter-manager.pc libmilter.pc $(am__append_1)
++ milter-manager.pc $(am__append_1)
EXTRA_DIST = \
- autogen.sh \
- gpg_uid \
+ NEWS\
+ NEWS.ja \
diff --git a/mail/milter-manager/files/patch-configure
b/mail/milter-manager/files/patch-configure
index ba66440dbb59..888c5683d98d 100644
--- a/mail/milter-manager/files/patch-configure
+++ b/mail/milter-manager/files/patch-configure
@@ -1,11 +1,11 @@
configure.orig 2017-06-28 06:21:45 UTC
+--- configure.orig 2022-09-28 02:08:37 UTC
+++ configure
-@@ -14803,7 +14803,7 @@ fi
- end
- end
- ruby_glib2_path = ruby_glib2_gem.full_gem_path
-- print("-I ", File.join(ruby_glib2_path, "ext", "glib2"))')
-+ print("-I ", File.join(ruby_glib2_path, "lib"))')
- if test $? -eq 0; then
- CFLAGS="$CFLAGS $RUBY_GLIB2_CFLAGS"
- else
+@@ -14423,7 +14423,7 @@ fi
+
+ ruby_glib2_gem_dir="$($RUBY -rglib2 -e
'print(Gem::Specification.find_by_name(%(glib2)).gem_dir)')"
+ if test -d "$ruby_glib2_gem_di
Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
On Nov 28, 2024, at 04:19, Andriy Gapon wrote: > On 28/11/2024 13:42, Dag-Erling Smørgrav wrote: >> Andriy Gapon writes: >>> FWIW, I am not sure if it's relevant but I am seeing a similar pattern >>> of corruption on tmpfs although in a different context, on FreeBSD >>> 13.3. >> Not relevant at all. In this case the file is not actually corrupted >> but `install(1)` skips over some of it when copying because `SEEK_DATA` >> is implemented incorrectly. > > Still could be relevant... > I don't know the "true state" of my corrupted files, I only observe the > consequences. And the files get some post-processing, then they are uploaded > and originals are removed. So, the problem could be not during the write > phase, but during the read phase of post-processing. First an FYI for why I started with 2bed60 instead of a page boundry: 2bed60 was the start of .got.plt, which is what was involved in the program crash. In every case, it seems likely that the whole page containing that start was zero, no matter if it should have been at the page start or not. The page start is just not what I was focused on for reporting. So I expect a "tail of page is all zero but should not be, start of page was a normal not-all-zero" problem would be a distinct problem. Or are you always seeing the problem as a full page of zeros instead of just the tail of that page (that should not be all zero)? In Dag-Erling's wording, "this case" refers to the context I was gathering investigative data for, not your context, as I understand it. [I've referenced: https://lists.freebsd.org/archives/freebsd-fs/2024-November/003855.html ] As for: "The writes are done by appending variable sized records to a file. There are no seeks or overwrites.": Am I to interpret that as: ) New file with just sequential writes that are variable sized? vs. ) Appending to a pre-existing file? (That would involve seeking and typically merging new data with old data from the original last-page-with-data and writing that update back out.) === Mark Millard marklmi at yahoo.com
New port devel/py-gql #281910 looking for commit
Would it be possible for someone to review and commit the following? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281910 As of 33d3fd27d7 this patch builds with the same `make test` with extra warnings.
Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
On Thu, 28 Nov 2024, Mark Millard wrote:
Sean C. Farley wrote on
Date: Thu, 28 Nov 2024 18:16:16 UTC :
On Mon, 25 Nov 2024, Mark Millard wrote:
On Nov 25, 2024, at 18:05, Mark Millard wrote:
Top posting going in a different direction that
established a way to control the behavior in my
context . . .
For folks new to the discoveries: the context here
is poudriere bulk builds, for USE_TMPFS=all vs.
USE_TMPFS=no . My test context is amd64 on a
7950X3D system with 192 GiBytes of RAM. Others have
other contexts, including an Intel system.
*snip*
System setup:
- FreeBSD 14.2-STABLE
The context that I investigated --and what was fixed by a commit only
applies to-- main [so; 15 as stands], not stable/14 .
stable/14 has no commits mentioning "tmpfs" after 2024-Jun-04.
Thank you. That was my mistake. I will continue searching for an
answer. Once I find a way to more consistently trigger it, it will be
much easier.
I ran all of the tmpfs*.sh tests from HEAD which all pass except for
tmpfs24.sh.
$ ./all.sh -o tmpfs24.sh
20241128 22:33:38 all: tmpfs24.sh
Min hole size is 4096, file size is 524288000.
data #1 @ 0, size=4096)
hole #2 @ 4096, size=4096
data #3 @ 8192, size=4096)
hole #4 @ 12288, size=4096
data #5 @ 16384, size=4096)
hole #6 @ 20480, size=524267520
--- /tmp/tmpfs24.exp2024-11-28 22:33:40.222199000 -0500
+++ /tmp/tmpfs24.log2024-11-28 22:33:40.225048000 -0500
@@ -5,4 +5,3 @@
hole #4 @ 12288, size=4096
data #5 @ 16384, size=4096)
hole #6 @ 20480, size=524267520
-<>
FAIL tmpfs24.sh exit code 1
- i7-14700K (latest BIOS which *should* fix Intel power-related bugs)
- 128 GiB RAM
- ZFS (mirrored drives)
The primary test context was ZFS but no redundancy or such. (Only
really used for bectl activity.) But testing on a UFS copy of
the live directory tree also got the problem. The actual problem
was in tmpfs support.
That was what I thought from what I read, but I wanted to make sure I
did not leave out an important detail.
- 2 encrypted swap partitions (64 GiB each, lightly used)
No encryption involved in my context at all.
- Lightly undervolted (-0.06 offset to Global Core SVID Voltage)
Nothing analogous in my context.
- /tmp is tmpfs
I have no default areas that are tmpfs: so only what
poudriere temporarily created during the bulk builds.
- ${HOME}/.cache is tmpfs
No use of ccache or the like.
- Poudriere:
- USE_TMPFS=all
I also use TMPFS_BLACKLIST .
My personal environment causes use of -gline-tables-only as
debug information normally. (That option is clang/clang++
specific. gcc* and clang* do not seem to have a common
notation for analogous settings on the command line.)
- ccache
No use of ccache or the like.
- jail version in sync with host
True for my context. But the issue that was fixed was
in the kernel code, not the world code.
- /usr/ports is mounted with nullfs
Also true for my context.
I appreciate that information.
*snip build failure*
None of this is directly stable/14 : all main
[so: 15 as stands].
stable/14 has no commits mentioning "tmpfs" after 2024-Jun-04. So
none of these changes are involved for stable/14 .
It was a long shot on my part anyway. :)
Sean
--
s...@freebsd.org
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/intel-graphics-compiler | 1.0.12504.5 | v2.1.12 +-+ devel/pycharm-pro | 2024.2.3| 2024.2.5 +-+ japanese/mecab-ipadic-eucjp | 2.7.0-20070801 | 4.0.0- +-+ japanese/mecab-ipadic-sjis | 2.7.0-20070801 | 3.0.0- +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
On Nov 28, 2024, at 19:54, Sean C. Farley wrote: > On Thu, 28 Nov 2024, Mark Millard wrote: > >> . . . > >>> System setup: >>> - FreeBSD 14.2-STABLE >> >> The context that I investigated --and what was fixed by a commit only >> applies to-- main [so; 15 as stands], not stable/14 . >> >> stable/14 has no commits mentioning "tmpfs" after 2024-Jun-04. > > Thank you. That was my mistake. I will continue searching for an answer. > Once I find a way to more consistently trigger it, it will be much easier. > > I ran all of the tmpfs*.sh tests from HEAD which all pass except for > tmpfs24.sh. Did you notice: Thu, 28 Nov 2024 . . . • git: 2e2699c48a7e - main - stress2: Added new tmpfs test scenarios Peter Holm that added: stress2: Added new tmpfs test scenarios --- tools/test/stress2/misc/tmpfs26.sh | 179 + tools/test/stress2/misc/tmpfs27.sh | 49 ++ tools/test/stress2/misc/tmpfs28.sh | 61 + 3 files changed, 289 insertions(+) ? > $ ./all.sh -o tmpfs24.sh > 20241128 22:33:38 all: tmpfs24.sh > Min hole size is 4096, file size is 524288000. > data #1 @ 0, size=4096) > hole #2 @ 4096, size=4096 > data #3 @ 8192, size=4096) > hole #4 @ 12288, size=4096 > data #5 @ 16384, size=4096) > hole #6 @ 20480, size=524267520 > --- /tmp/tmpfs24.exp2024-11-28 22:33:40.222199000 -0500 > +++ /tmp/tmpfs24.log2024-11-28 22:33:40.225048000 -0500 > @@ -5,4 +5,3 @@ > hole #4 @ 12288, size=4096 > data #5 @ 16384, size=4096) > hole #6 @ 20480, size=524267520 > -<> > FAIL tmpfs24.sh exit code 1 > >>> . . . === Mark Millard marklmi at yahoo.com
Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
On Mon, 25 Nov 2024, Mark Millard wrote:
On Nov 25, 2024, at 18:05, Mark Millard wrote:
Top posting going in a different direction that
established a way to control the behavior in my
context . . .
For folks new to the discoveries: the context here
is poudriere bulk builds, for USE_TMPFS=all vs.
USE_TMPFS=no . My test context is amd64 on a
7950X3D system with 192 GiBytes of RAM. Others have
other contexts, including an Intel system.
I have been seeing some odd behavior from Firefox as well as with
poudriere builds on my system. Both of which are touching a tmpfs
system as I have setup /tmp as tmpfs, which Firefox uses, and
USE_TMPFS=all.
The system has been an experiment, for me, with undervolting. I have
been attributing any flakiness to the undervolting, but I have reduced
that a lot while the instability has been consistent as in it has stayed
rare. I cannot tell how many times I have run memtest86 on this system.
System setup:
- FreeBSD 14.2-STABLE
- i7-14700K (latest BIOS which *should* fix Intel power-related bugs)
- 128 GiB RAM
- ZFS (mirrored drives)
- 2 encrypted swap partitions (64 GiB each, lightly used)
- Lightly undervolted (-0.06 offset to Global Core SVID Voltage)
- /tmp is tmpfs
- ${HOME}/.cache is tmpfs
- Poudriere:
- USE_TMPFS=all
- ccache
- jail version in sync with host
- /usr/ports is mounted with nullfs
I have wondered if it was swap-related, but recently I noticed a build
failure with games/veloren-weekly where swap was available but zero
bytes were used. The system was under little load at the time so less
chance of undervolting being an issue.
Build failure:
-
portpicker = { path =
'/wrkdirs/usr/ports/games/veloren-weekly/work/portpicker-rs-df6b37872f3586ac3b21d08b56c8ec7cd92fb172'
}
===> Updating Cargo.lock
error: checksum for `windows_x86_64_msvc v0.42.2` changed between lock files
this could be indicative of a few possible errors:
* the lock file is corrupt
* a replacement source in use (e.g., a mirror) returned a different checksum
* the source itself may be corrupt in one way or another
unable to verify that `windows_x86_64_msvc v0.42.2` is the same as when the
lockfile was generated
*** Error code 101
-
Restarting the build finished successfully.
I changed USE_TMPFS=all to USE_TMPFS=no :
USE_TMPFS=all gets the failure
*snip*
vs.
USE_TMPFS=no works just fine
So it is a FreeBSD system error associated with
use of tmpfs .
Recent work on tmpfs includes:
Mon, 09 Sep 2024
• git: 8fa5e0f21fd1 - main - tmpfs: Account for whiteouts during rename/rmdir
Jason A. Harmening
Fri, 04 Oct 2024
• git: 75734c4360fc - main - tmpfs: check residence in data_locked Doug Moore
Sun, 13 Oct 2024
• git: ec22e705c266 - main - tmpfs: remove duplicate flags check in tmpfs_rmdir
Alan Somers
Thu, 24 Oct 2024
• git: db08b0b04dec - main - tmpfs_vnops: move swap work to swap_pager Doug
Moore
swap_pager (given the reference to it above):
Tue, 08 Oct 2024
• git: d0b225d16418 - main - swap_pager: use iterators in
swp_pager_meta_build Doug Moore
Fri, 11 Oct 2024
• git: 1107834090be - main - swap_pager: swapoff detecting object death Doug
Moore
Thu, 24 Oct 2024
• git: 34951b0b9e78 - main - swap_pager: move scan_all_shadowed, use
iterators Doug Moore
• git: 02e85d1c8a41 - main - swap_pager: fix assert in seek_data Doug Moore
• git: faa9356f97d2 - main - swap_pager: fix seek_hole assert Doug Moore
Sat, 26 Oct 2024
• git: 39f6d1e7f835 - main - swap_pager: iter in haspage, lookup, getpages
Doug Moore
Wed, 13 Nov 2024
• git: d11d407aee48 - main - swap_pager: Ensure that swapoff puts swapped-in
pages in page queues Mark Johnston
I do not know at this time when the corruptions started. The
above is only suggestive.
Thank you for listing those.
I need to find some time to look over those changes although I am no
kernel guru by a long shot. However, I see now that it looks like much
more knowledgeable people are already looking on the current mailing
list at the issue.
Sean
--
s...@freebsd.org
Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]
Sean C. Farley wrote on
Date: Thu, 28 Nov 2024 18:16:16 UTC :
> On Mon, 25 Nov 2024, Mark Millard wrote:
>
> > On Nov 25, 2024, at 18:05, Mark Millard wrote:
> >
> >> Top posting going in a different direction that
> >> established a way to control the behavior in my
> >> context . . .
> >
> > For folks new to the discoveries: the context here
> > is poudriere bulk builds, for USE_TMPFS=all vs.
> > USE_TMPFS=no . My test context is amd64 on a
> > 7950X3D system with 192 GiBytes of RAM. Others have
> > other contexts, including an Intel system.
>
> I have been seeing some odd behavior from Firefox as well as with
> poudriere builds on my system. Both of which are touching a tmpfs
> system as I have setup /tmp as tmpfs, which Firefox uses, and
> USE_TMPFS=all.
>
> The system has been an experiment, for me, with undervolting. I have
> been attributing any flakiness to the undervolting, but I have reduced
> that a lot while the instability has been consistent as in it has stayed
> rare. I cannot tell how many times I have run memtest86 on this system.
>
> System setup:
> - FreeBSD 14.2-STABLE
The context that I investigated --and what was fixed by a commit only
applies to-- main [so; 15 as stands], not stable/14 .
stable/14 has no commits mentioning "tmpfs" after 2024-Jun-04.
> - i7-14700K (latest BIOS which *should* fix Intel power-related bugs)
> - 128 GiB RAM
> - ZFS (mirrored drives)
The primary test context was ZFS but no redundancy or such. (Only
really used for bectl activity.) But testing on a UFS copy of
the live directory tree also got the problem. The actual problem
was in tmpfs support.
> - 2 encrypted swap partitions (64 GiB each, lightly used)
No encryption involved in my context at all.
> - Lightly undervolted (-0.06 offset to Global Core SVID Voltage)
Nothing analogous in my context.
> - /tmp is tmpfs
I have no default areas that are tmpfs: so only what
poudriere temporarily created during the bulk builds.
> - ${HOME}/.cache is tmpfs
No use of ccache or the like.
> - Poudriere:
> - USE_TMPFS=all
I also use TMPFS_BLACKLIST .
My personal environment causes use of -gline-tables-only as
debug information normally. (That option is clang/clang++
specific. gcc* and clang* do not seem to have a common
notation for analogous settings on the command line.)
> - ccache
No use of ccache or the like.
>- jail version in sync with host
True for my context. But the issue that was fixed was
in the kernel code, not the world code.
> - /usr/ports is mounted with nullfs
Also true for my context.
> I have wondered if it was swap-related, but recently I noticed a build
> failure with games/veloren-weekly where swap was available but zero
> bytes were used. The system was under little load at the time so less
> chance of undervolting being an issue.
>
> Build failure:
> -
>
> portpicker = { path =
> '/wrkdirs/usr/ports/games/veloren-weekly/work/portpicker-rs-df6b37872f3586ac3b21d08b56c8ec7cd92fb172'
> }
> ===> Updating Cargo.lock
> error: checksum for `windows_x86_64_msvc v0.42.2` changed between lock files
>
> this could be indicative of a few possible errors:
>
> * the lock file is corrupt
> * a replacement source in use (e.g., a mirror) returned a different checksum
> * the source itself may be corrupt in one way or another
>
> unable to verify that `windows_x86_64_msvc v0.42.2` is the same as when the
> lockfile was generated
>
> *** Error code 101
>
> -
>
> Restarting the build finished successfully.
>
> >> I changed USE_TMPFS=all to USE_TMPFS=no :
> >>
> >> USE_TMPFS=all gets the failure
>
> *snip*
>
> >> vs.
> >> USE_TMPFS=no works just fine
> >>
> >> So it is a FreeBSD system error associated with
> >> use of tmpfs .
> >
> > Recent work on tmpfs includes:
None of this is directly stable/14 : all main
[so: 15 as stands].
stable/14 has no commits mentioning "tmpfs" after 2024-Jun-04. So
none of these changes are involved for stable/14 .
> >
> > Mon, 09 Sep 2024
> > • git: 8fa5e0f21fd1 - main - tmpfs: Account for whiteouts during
> > rename/rmdir Jason A. Harmening
> > Fri, 04 Oct 2024
> > • git: 75734c4360fc - main - tmpfs: check residence in data_locked Doug
> > Moore
> > Sun, 13 Oct 2024
> > • git: ec22e705c266 - main - tmpfs: remove duplicate flags check in
> > tmpfs_rmdir Alan Somers
> > Thu, 24 Oct 2024
> > • git: db08b0b04dec - main - tmpfs_vnops: move swap work to swap_pager
> > Doug Moore
> >
> > swap_pager (given the reference to it above):
> >
> > Tue, 08 Oct 2024
> > • git: d0b225d16418 - main - swap_pager: use iterators in
> > swp_pager_meta_build Doug Moore
> > Fri, 11 Oct 2024
> > • git: 1107834090be - main - swap_pager: swapoff detecting object death
> > Doug Moore
> > Thu, 24 Oct 2024
> > • git: 34951b0b9e78 - main - swap_pager: move scan_all_shadowed, use
> > iterators Doug Moore
> > • git: 02e85d1c8a41 - main - swap_pager: fix assert in seek_data Doug
> > M
