Re: install: uexterror.3.gz: No such file or directory [still can happen unless I omit -j use]

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 27 Sep 2026 18:12:30 UTC
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.


-- 
===
Mark Millard
marklmi at yahoo.com