From nobody Sun Nov 16 09:29:00 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4d8QYk5bkPz6HLx0 for ; Sun, 16 Nov 2025 09:29:14 +0000 (UTC) (envelope-from tschweikle@gmail.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8QYj2XPMz4PVH for ; Sun, 16 Nov 2025 09:29:13 +0000 (UTC) (envelope-from tschweikle@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=UERRD2gB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of tschweikle@gmail.com designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=tschweikle@gmail.com Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-4eda6c385c0so28069901cf.3 for ; Sun, 16 Nov 2025 01:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763285352; x=1763890152; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ACZmGClVkhVe9Y6nznc4MrEJ5CL55oP2t+zzfZah8lA=; b=UERRD2gByeMxJVJs4YyC9belJObIT7Ww7znn/6yy6QyOwvJcwZ03JQSNjr3dwnHj81 wx447GOSsyxtEM0LTm+sNRp5Cf7Q4dqUQiIOD5yIoKO29K1V/LUHen8WiNSLnX3TyqzY gRPORGgpoeNd79Kl40QgAve583rfLjWchEwEcHkxu9t8XxfV5ugmpt1S5Xqzd0dYrnHP zUsi7dZnfMAQdgJvRPSA3g7s0pnYxBrRMHFc1nNDPgaxoJ1JoCpLYhQGn7C3h0tdQPBZ eJzFxrEmaRZ5HZqv9a/6uzfG/nRcCg2SXZYiiTM8h9bT2jbGpejUjuJ17BfXostDYTUV 7eDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763285352; x=1763890152; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ACZmGClVkhVe9Y6nznc4MrEJ5CL55oP2t+zzfZah8lA=; b=Y8bE/vbirNilIBlAznCmzZ31dSppRdkWeJL9NjjfzAcoCjsRlOeCM3y7eF7YLGA5jf Wkj8ViQ/afRz0ZE93UdcbxJ7ZW7jK3PM3kSv0eXwRLbyeezX8dNtvGPw4b4SwMg4guOb n7vZh7xyaN+RI3aE/nenkOYLnNN3E8TMH6nWFZ4wVJ1VT0OoVk2tPXFSWbNCUJ9sHMEu 9KIbXPUNxEQBqQxQ8sKxdMMnGZwBITV1ueDO20c2aje3+nx/gWvSixb9uxVndUHKTyWV DlyLbV7tmKoifv6Z+7PZkB5YkpIR2O9P238n9Pwy28d6izWE2oMxVdYNwUJCgoh1iCll RQYw== X-Gm-Message-State: AOJu0YzZ8AucnbgQcZhGS1Ks7TF1KHP42wWVinnavQXuPHALir0JgWPf NUBGbXeNQQFEkfcWpLI4Z6yf8WQmI+NYgiWM5N1Vu52xsh32YyvDgHspMx7YUSBQsfOqyKwD3cz gxuhndt42VTtIoEvon2bFZtIcdH4au8qWOQ== X-Gm-Gg: ASbGncvS7SHUFUa0xaOBaf7GQB09MfkJ8D+Y7eONntar5fvC1ItYSM3ATOtCF/uR95t e8mk2Qa6fq2j9+9SBR2zXkmWECVF+lGVKHfeu/JdV5DAtM+dF8q2xWR8VbZkhJK94yCWpRC3o/n /YXKSxhfE9bsUeMGwifoT69IPw8yt/epNA1ZTIdjycVCwSGrRtPGy/RKfuI9Ds9hp9CVPWZpCkF mHEj8thhMfu3eO/oL3lG/9GDq4SH1WCj1nSxnVQO2Ph8Llj1BE/qNHaDWiuot7KKncDVqtIUjNJ LBIzPcPQ0Bv26fHrU1kFFYwfj+ae X-Google-Smtp-Source: AGHT+IFfsI69yApYBpymcRBGBxaP/CbmRzHzqNLJPV1S7I81ApGfo/45q+ib4qDJFdK56Z7qMu9LPZyWA7pZo2m1RYE= X-Received: by 2002:a05:622a:14d4:b0:4ec:f29f:d95d with SMTP id d75a77b69052e-4edf210f4camr115782671cf.58.1763285351693; Sun, 16 Nov 2025 01:29:11 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> <2121B7E6-0DB6-427A-9C72-640A3AEE26AA@ketas.si.pri.ee> In-Reply-To: From: Thomas Schweikle Date: Sun, 16 Nov 2025 10:29:00 +0100 X-Gm-Features: AWmQ_bnzuwM6N034E0hYJvuoFNhe8GA7pi1tnRur8gHL99ixC5l5V6PULrdhTRo Message-ID: Subject: Re: "etcupdate extract" -- Failed to build new tree. To: Sulev-Madis Silber Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000683510643b2ddc1" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.71 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; NEURAL_HAM_SHORT(-0.75)[-0.749]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::835:from] X-Rspamd-Queue-Id: 4d8QYj2XPMz4PVH --0000000000000683510643b2ddc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Seems like someone "optimized" "./mk_cmds" by changing permissions to "chmod 0755 m/mk_cmds*", then directly calling "./mk_cmds". Within older versions of "etcupdate" it was executed by "/bin/sh ./mk_cmds". "/bin/sh ./mk_cmds" circumvents "noexec". But it makes it possible to compile sources without executing anything within /usr/src directly. But: while /usr/src is mounted zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) /usr/obj is mounted zroot/usr on /usr (zfs, local, nfsv4acls) And both mounts are what FreeBSD on zfs with GPT ( https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot) expects (copied right from the handbook pages): zfs create -o mountpoint=3D/tmp -o exec=3Don -o setuid=3Doff zroot/= tmp zfs create -o canmount=3Doff -o mountpoint=3D/usr zroot/us= r zfs create zroot/usr/ho= me zfs create -o exec=3Doff -o setuid=3Doff zroot/us= r/src zfs create zroot/usr/ob= j zfs create -o mountpoint=3D/usr/ports -o setuid=3Doff zroot/us= r/ports zfs create -o exec=3Doff -o setuid=3Doff zroot/usr/ports/distfiles zfs create -o exec=3Doff -o setuid=3Doff zroot/usr/ports/packages zfs create -o canmount=3Doff -o mountpoint=3D/var zroot/va= r zfs create -o exec=3Doff -o setuid=3Doff zroot/va= r/audit zfs create -o exec=3Doff -o setuid=3Doff zroot/va= r/crash zfs create -o exec=3Doff -o setuid=3Doff zroot/va= r/log zfs create -o atime=3Don -o exec=3Doff -o setuid=3Doff zroot/= var/mail zfs create -o exec=3Don -o setuid=3Doff zroot/va= r/tmp Since "etcupdate" worked about four months ago, then it started to stop working, something has changed with how it works. For me it looks like there creating mk_cmds within /usr/src, instead within /usr/obj. This was ok as long as mk_cmds was called with "/bin/sh ./mk_cmds". As soon as this was changed to "chmod 0755 mk_cmds*; ./mk_cmds" it broke. I've tested a lot last days. It is not "noexec" set for "/usr/src". It is something changed just before forking "stable/15". Going back to this makes it working again (as it does copying "etcupdate" from "stable/14". On Sun, Nov 9, 2025 at 2:49=E2=80=AFAM Sulev-Madis Silber < freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > > > On November 8, 2025 10:36:43 PM GMT+02:00, Thomas Schweikle < > tschweikle@gmail.com> wrote: > >On Sat, Nov 8, 2025 at 8:00=E2=80=AFPM Sulev-Madis Silber < > >freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > > > >> first thing that comes to my mind... > >> > >> is there any other fs where noexec is used? > >> > >The other systems are set up the same way, mounting /usr/src > >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > > > > > >> especially on which the etcupdate actually runs on? > >> > >It runs on three other systems: > >- stable/13 > >- stable/14 > >and a pre stable/15 (before ALPHA was out and the branch done). > > > >It does not run if executed on a > >- stable/15 > >- current > > > >in both cases "make buildetc" works as expected if not called from insid= e > >"etcupdate". > > > > > >> i haven't so far studied the whole thing but if you have put noexec > >> everywhere, including tmp dirs or whatever etcupdate uses, it could be > it! > >> > >noexec does not touch "root", but standard users. Does etcupdate switch = to > >some other user while executing? Does it do so before branching stable/1= 5? > > unfortunately noexec don't even let root execute anything directly > > read works, shell scripts, makefiles > > if you have other fses in that very same machine mounted noexec then this > code will fail. and it indeed does give permission denied > > i don't know where mk_cmds is. perhaps in obj? i'm currently not debuggin= g > this > > whether it should be able to run noexec, no idea, not everything can be > > noexec is there by purpose i assume, but maybe it could be temporary > disabled > > btw noexec as a security measure can be also bypassed > > tell us if disabling noexec on fses helped > > that's also fun thing, that not many add, or if they do, they know what > happens. many building type tasks like to execute something in dirs > > you didn't tell that you had noexec on and nobody asked either so maybe > it's noexec for all that time and you had to do manual work > > i hope it's fixed now!!! > > > > >And just switching into /usr/src, then executing "make etcupdate" does > call > >"./mk_cmds" and it does not fail because it is forbidden to run -- it > runs. > > > >just a wild guess. noexec is not always used and it often blows up rando= m > >> thing unexpectedly. others have it disabled and therefore don't see it > >> > >> > >> > >> On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle < > >> tschweikle@gmail.com> wrote: > >> >Looking at the log from etcupdate I found it failing with > >> > > >> >chmod 755 mk_cmds > >> >rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h > >> >cp /usr/src/crypto/krb5/src/util/ss/ss_err.et et-h-ss_err.et > >> >compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mit-krb5 > >> >et-h-ss_err.et > >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk > >> >'outfile=3Det-h-ss_err.h' et-h-ss_err.et > >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk > >> >'outfile=3Det-h-ss_err.c' 'textdomain=3Dmit-krb5' 'localedir=3D' > et-h-ss_err.et > >> >mv et-h-ss_err.h ss_err.h > >> >rm -f et-h-ss_err.et et-h-ss_err.h > >> >./mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs.ct > >> >make[4]: exec(./mk_cmds): Permission denied > >> >*** Error code 1 > >> > > >> >Stop. > >> >make[4]: stopped making "all" in /usr/src/krb5/util/ss > >> >*** Error code 1 > >> > > >> >Stop. > >> >make[3]: stopped making "bootstrap-tools" in /usr/src > >> > 10.16 real 8.75 user 1.04 sys > >> >*** Error code 1 > >> > > >> >Stop. > >> >make[2]: stopped making "_bootstrap-tools" in /usr/src > >> >*** Error code 1 > >> > > >> >Stop. > >> >make[1]: stopped making "buildetc" in /usr/src > >> >*** Error code 1 > >> > > >> >Stop. > >> >make: stopped making "buildetc" in /usr/src > >> > > >> >It fails, because it is not allowed to "exec ./mk_cmds", after settin= g > >> >"chmod 0755" for "mk_cmds"? Within "/usr/src" "mk_cmds" just does not > >> exist > >> >=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*' -print" would = be able to > >> >find it: > >> >/usr/src # find . -iname '*/mk_cmds/*' > >> >/usr/src # > >> > > >> >"/usr/src" is mounted > >> >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > >> > > >> >AND what makes it even more mysterious: > >> ># cd /usr/src > >> ># make buildetc > >> > > >> >works without reporting any error. If called from "etcupdate extract" > it > >> >fails. > >> > > >> >It works for FreeBSD: > >> >- stable/13 > >> >- stable/14 > >> > > >> >but not for: > >> >- stable/15 > >> > > >> >Full log is attached. > >> > > >> >On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber < > >> >freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > >> > > >> >> something bad clearly happened in that machine if it's able to > selfhost > >> >> build itself and work, except etcupdate. and that for a long time > >> >> > >> >> i don't see any reason getting pissed about his machine mysteriousl= y > not > >> >> working, despite i haven't broken any machine myself since i > installed > >> >> first fbsd, 4.6 > >> >> > >> >> unsure how to go from here. unsure if src.conf or make.conf matters > here > >> >> > >> >> if this happens in currently actively supported fbsd release, maybe > >> >> etcupdate needs a bugfix to cleanup for edge cases > >> >> > >> >> if it's in unsupported, that should not cause any "pissages" either= . > fix > >> >> is somewhere > >> >> > >> >> so, the admin updated files manually because he was not able to get > it > >> >> working? i bet you can recreate it and fix it for future cases > >> >> > >> >> since i haven't ever broken etcupdate, i don't know which data it > uses > >> as > >> >> input. but seems like it reads wrong data out of somewhere. and > entire > >> >> machine works, except this? > >> >> > >> >> i mean if this was bad upgrade leftover, how to fix? i mean doesn't > >> >> etcupdate get rework now, for pkgbase. while we do that, maybe it > could > >> be > >> >> made to handle this. or maybe even given non-destructive nuke mode = so > >> >> people can start clean > >> >> > >> >> i don't think it's really entirely user error, considering he didn'= t > >> break > >> >> the machine > >> >> > >> >> i'm curious too. at worst you could do other install in another > machine > >> >> and compare dirs as something must differ there. then, according to > >> >> findings, fix the old machine. maybe while doing this, some new > bugfix > >> idea > >> >> appears > >> >> > >> >> but hell with getting mad over machine. he's pissed too, everyone's > >> >> pissed, server is not working and no productive work have been done > here > >> >> > >> >> maybe something got lost in translation too > >> >> > >> >> > >> > > >> > >> > > > > --=20 Thomas --0000000000000683510643b2ddc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seems like someone "optimized" "./mk_cmds&q= uot; by changing permissions to "chmod 0755 m/mk_cmds*", then dir= ectly calling "./mk_cmds". Within older versions of "etcupda= te" it was executed by "/bin/sh ./mk_cmds". "/bin/sh ./= mk_cmds" circumvents "noexec". But it makes it possible to c= ompile sources=C2=A0without executing anything within /usr/src directly.
But: while /usr/src is mounted
zro= ot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls)
=

/usr/obj is mounted
zroot/usr on /usr (zfs, local, nfsv4acls)
<= br>
And both mounts are what FreeBSD on zfs with GPT (https://wi= ki.freebsd.org/RootOnZFS/GPTZFSBoot) expects (copied right from the han= dbook pages):
zfs create -o mountpoint=3D/tmp  -o exec=3Do=
n      -o setuid=3Doff   zroot/tmp
zfs create -o canmount=3Doff -o mountpoint=3D/usr                  zroot/us=
r
zfs create                                                     zroot/usr/ho=
me
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/us=
r/src
zfs create                                                     zroot/usr/ob=
j
zfs create -o mountpoint=3D/usr/ports            -o setuid=3Doff   zroot/us=
r/ports
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/us=
r/ports/distfiles
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/us=
r/ports/packages
zfs create -o canmount=3Doff -o mountpoint=3D/var                  zroot/va=
r
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/va=
r/audit
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/va=
r/crash
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/va=
r/log
zfs create -o atime=3Don         -o exec=3Doff     -o setuid=3Doff   zroot/=
var/mail
zfs create                     -o exec=3Don      -o setuid=3Doff   zroot/va=
r/tmp

Since "etcupdate" worked abo= ut four months ago, then it started to stop working, something has changed = with how it works. For me it looks like there creating mk_cmds within /usr/= src, instead within /usr/obj. This was ok as long as mk_cmds was called wit= h "/bin/sh ./mk_cmds". As soon as this was changed to "chmod= 0755 mk_cmds*; ./mk_cmds" it broke.

I've= tested a lot last days. It is not "noexec" set for "/usr/sr= c". It is something changed just before forking "stable/15".= Going back to this makes it working again (as it does copying "etcupd= ate" from "stable/14".

On Sun, Nov 9, 2025 at 2:49=E2= =80=AFAM Sulev-Madis Silber <freebsd-current-freebsd-org111@ket= as.si.pri.ee> wrote:


On November 8, 2025 10:36:43 PM GMT+02:00, Thomas Schweikle <tschweikle@gmail.com>= wrote:
>On Sat, Nov 8, 2025 at 8:00=E2=80=AFPM Sulev-Madis Silber <
>freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote:<= br> >
>> first thing that comes to my mind...
>>
>> is there any other fs where noexec is used?
>>
>The other systems are set up the same way, mounting /usr/src
>zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls)
>
>
>> especially on which the etcupdate actually runs on?
>>
>It runs on three other systems:
>- stable/13
>- stable/14
>and a pre stable/15 (before ALPHA was out and the branch done).
>
>It does not run if executed on a
>- stable/15
>- current
>
>in both cases "make buildetc" works as expected if not called= from inside
>"etcupdate".
>
>
>> i haven't so far studied the whole thing but if you have put n= oexec
>> everywhere, including tmp dirs or whatever etcupdate uses, it coul= d be it!
>>
>noexec does not touch "root", but standard users. Does etcupd= ate switch to
>some other user while executing? Does it do so before branching stable/= 15?

unfortunately noexec don't even let root execute anything directly

read works, shell scripts, makefiles

if you have other fses in that very same machine mounted noexec then this c= ode will fail. and it indeed does give permission denied

i don't know where mk_cmds is. perhaps in obj? i'm currently not de= bugging this

whether it should be able to run noexec, no idea, not everything can be

noexec is there by purpose i assume, but maybe it could be temporary disabl= ed

btw noexec as a security measure can be also bypassed

tell us if disabling noexec on fses helped

that's also fun thing, that not many add, or if they do, they know what= happens. many building type tasks like to execute something in dirs

you didn't tell that you had noexec on and nobody asked either so maybe= it's noexec for all that time and you had to do manual work

i hope it's fixed now!!!

>
>And just switching into /usr/src, then executing "make etcupdate&q= uot; does call
>"./mk_cmds" and it does not fail because it is forbidden to r= un -- it runs.
>
>just a wild guess. noexec is not always used and it often blows up rand= om
>> thing unexpectedly. others have it disabled and therefore don'= t see it
>>
>>
>>
>> On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle < >> tschweik= le@gmail.com> wrote:
>> >Looking at the log from etcupdate I found it failing with
>> >
>> >chmod 755 mk_cmds
>> >rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h
>> >cp /usr/src/crypto/krb5/src/util/ss/ss_err.et et-h-ss_err.et
>> >compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mi= t-krb5
>> >et-h-ss_err.et
>> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk >> >'outfile=3Det-h-ss_err.h' et-h-ss_err.et
>> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk >> >'outfile=3Det-h-ss_err.c' 'textdomain=3Dmit-krb5&#= 39; 'localedir=3D' et-h-ss_err.et
>> >mv et-h-ss_err.h ss_err.h
>> >rm -f et-h-ss_err.et et-h-ss_err.h
>> >./mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs.ct
>> >make[4]: exec(./mk_cmds): Permission denied
>> >*** Error code 1
>> >
>> >Stop.
>> >make[4]: stopped making "all" in /usr/src/krb5/util/= ss
>> >*** Error code 1
>> >
>> >Stop.
>> >make[3]: stopped making "bootstrap-tools" in /usr/sr= c
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A010.16 real=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A08.75 user=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.04 sys
>> >*** Error code 1
>> >
>> >Stop.
>> >make[2]: stopped making "_bootstrap-tools" in /usr/s= rc
>> >*** Error code 1
>> >
>> >Stop.
>> >make[1]: stopped making "buildetc" in /usr/src
>> >*** Error code 1
>> >
>> >Stop.
>> >make: stopped making "buildetc" in /usr/src
>> >
>> >It fails, because it is not allowed to "exec ./mk_cmds&qu= ot;, after setting
>> >"chmod 0755" for "mk_cmds"? Within "/= usr/src" "mk_cmds" just does not
>> exist
>> >=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*= ' -print" would be able to
>> >find it:
>> >/usr/src # find . -iname '*/mk_cmds/*'
>> >/usr/src #
>> >
>> >"/usr/src" is mounted
>> >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4ac= ls)
>> >
>> >AND what makes it even more mysterious:
>> ># cd /usr/src
>> ># make buildetc
>> >
>> >works without reporting any error. If called from "etcupd= ate extract" it
>> >fails.
>> >
>> >It works for FreeBSD:
>> >- stable/13
>> >- stable/14
>> >
>> >but not for:
>> >- stable/15
>> >
>> >Full log is attached.
>> >
>> >On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber <=
>> >freebsd-current-freebsd-org111@ketas.si.pri.ee>= ; wrote:
>> >
>> >> something bad clearly happened in that machine if it'= s able to selfhost
>> >> build itself and work, except etcupdate. and that for a l= ong time
>> >>
>> >> i don't see any reason getting pissed about his machi= ne mysteriously not
>> >> working, despite i haven't broken any machine myself = since i installed
>> >> first fbsd, 4.6
>> >>
>> >> unsure how to go from here. unsure if src.conf or make.co= nf matters here
>> >>
>> >> if this happens in currently actively supported fbsd rele= ase, maybe
>> >> etcupdate needs a bugfix to cleanup for edge cases
>> >>
>> >> if it's in unsupported, that should not cause any &qu= ot;pissages" either. fix
>> >> is somewhere
>> >>
>> >> so, the admin updated files manually because he was not a= ble to get it
>> >> working? i bet you can recreate it and fix it for future = cases
>> >>
>> >> since i haven't ever broken etcupdate, i don't kn= ow which data it uses
>> as
>> >> input. but seems like it reads wrong data out of somewher= e. and entire
>> >> machine works, except this?
>> >>
>> >> i mean if this was bad upgrade leftover, how to fix? i me= an doesn't
>> >> etcupdate get rework now, for pkgbase. while we do that, = maybe it could
>> be
>> >> made to handle this. or maybe even given non-destructive = nuke mode so
>> >> people can start clean
>> >>
>> >> i don't think it's really entirely user error, co= nsidering he didn't
>> break
>> >> the machine
>> >>
>> >> i'm curious too. at worst you could do other install = in another machine
>> >> and compare dirs as something must differ there. then, ac= cording to
>> >> findings, fix the old machine. maybe while doing this, so= me new bugfix
>> idea
>> >> appears
>> >>
>> >> but hell with getting mad over machine. he's pissed t= oo, everyone's
>> >> pissed, server is not working and no productive work have= been done here
>> >>
>> >> maybe something got lost in translation too
>> >>
>> >>
>> >
>>
>>
>



--
Thomas
--0000000000000683510643b2ddc1--