Re: install: uexterror.3.gz: No such file or directory [still can happen unless I omit -j use]
Date: Sun, 27 Sep 2026 18:51:01 UTC
On 9/27/26 11:12, Mark Millard wrote: > On 8/24/26 05:45, Brooks Davis wrote: >> On Sat, Aug 22, 2026 at 10:35:21AM -0700, bob prohaska wrote: >>> An armv7 P2 stopped installworld with >>> .... >>> install -o root -g wheel -m 444 uexterr_gettext.3.gz /usr/share/man/man3/ >>> install -o root -g wheel -m 444 uexterror.3.gz /usr/share/man/man3/ >>> install: uexterror.3.gz: No such file or directory >>> *** [realmaninstall-MAN] Error code 71 >>> >>> The host is at: >>> >>> FreeBSD www.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #56 n287675-95439b803fce-dirty: Mon Jul 27 07:53:39 PDT 2026 bob@www.zefox.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7 1600019 1600019 >>> >>> and the sources were updated last night, 8/21/26. The -dirty flag is related to kernel patches >>> and isn't obviously involved. >>> >>> A re-run of git pull reporated no updates that looked related. The machine is >>> running buildworld again in hopes the problem goes away. >> >> I'm confused. I added lib/libc/gen/uexterror.3 on the 20th in commit >> 95e33099c74d, but botched the MAN= entry, naming it uexterr.3 in >> lib/libc/gen/Makefile.inc due to having decided to rename it at the last >> minute. I then fixed the name later that day in commit 2ff0ca5272c8 so >> I'm confused how you could have a tree with the file missing, but the >> makefile updated. If you're still seeing issues, what commit is your >> tree at? >> >> -- Brooks >> >> > > > I've gotten this problem repeatedly when I had -j in use for the > installs (my normal scripting does that). The context happens to be > aarch64. I've no clue if that is contributing in some way. > > But as soon as I tried without the -j usage the installs instead ran to > completion and worked for each target tree (but took longer than the -j > usage would have). > > I expect some sort of race condition but I've no specific evidence about > what layer(s) of the tools or system are involved in the race(s). I make > no claim that the problem is specific to uexterror.3* handling, although > that is what showed up in my normal -j based examples. > > UFS context. > > I just tried the amd64 ZFS context with its normal -j usage for the installworld and it worked. But that is weak evidence for the issue. Bob P.'s context was armv7 instead of aarch64. I would guess UFS but do not know. For both aarch64 and amd64, the context is builds and installs of personal dirty builds of alternate (non-pkgbase) kernels and chroot/jail directory tree worlds. The boot world is an official pkgbase distribution install. I can boot the pkgbase kernels instead of my personal kernel builds but my personal updates normally are based on somewhat more recent of a source tree than the pkgbase installation is when I'm using the personal builds. So I normally run a personal-kernel if I'm going to use a personal-world based chroot/poudriere-jail. # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ aef4c3eb31d9 (HEAD -> main, freebsd/main, freebsd/HEAD) mana: Initialize ports with the common RSS key Author: Kevin Bowling <kbowling@FreeBSD.org> Commit: Kevin Bowling <kbowling@FreeBSD.org> CommitDate: 2026-09-18 23:01:09 +0000 branch: main merge-base: aef4c3eb31d9c29c6aeb08023b1c9d2457d817e3 merge-base: CommitDate: 2026-09-18 23:01:09 +0000 n289448 (--first-parent --count for merge-base) # uname -apKU FreeBSD aarch64-main-pbase 16.0-CURRENT FreeBSD 16.0-CURRENT #12 main-n289448-aef4c3eb31d9-dirty: Sat Sep 19 12:58:23 PDT 2026 root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76 arm64 aarch64 1600026 1600026 # uname -apKU FreeBSD 7950X3D-ZFS 16.0-CURRENT FreeBSD 16.0-CURRENT #18 main-n289448-aef4c3eb31d9-dirty: Sat Sep 19 08:03:12 PDT 2026 root@7950X3D-ZFS:/usr/obj/BUILDs/main-ZNV4-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1600026 1600026 So it is not the kind of "just official" context that I prefer to report problems based on. I do not know of any simple, guaranteed-reproduction context. The update started from my prior (late July) update. -- === Mark Millard marklmi at yahoo.com