From nobody Sat Nov 08 20:36:43 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 4d3nly2pCpz6GXy8 for ; Sat, 08 Nov 2025 20:37:02 +0000 (UTC) (envelope-from tschweikle@gmail.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 4d3nly146rz4J8x for ; Sat, 08 Nov 2025 20:37:02 +0000 (UTC) (envelope-from tschweikle@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-4edb2eef810so1062311cf.0 for ; Sat, 08 Nov 2025 12:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762634216; x=1763239016; 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=I+QUvibj8npzhh/zNetpLMC5q7YGk8A7tGB6rW8zrLE=; b=eaRlXHu9k3X86CUAElfNbXSNGY1+u9Qc4c+6NfwaRSsi/hgq9gPIwz6dizW/g6Ob5r mSs8AE1s9WjR4NIYznGXRv2mitD0tY0S1MNpZNkvD6KRM/GxUCBZKZS9PCXg0H4vX+0D Tgoa95lZplO67077vytiDHYuFdZTdTgERis/ARh0QUpS8WosM57teKTWEZ8UCYYDuksV Z2RkACLXvJDXo8zIAolER8eJAx/857ndfWW/uQ6j1510rdrneZgrd/IiW/cuGHV/AUK2 SFLoNA6ttUtsLOLHqc5usFXcacqdhNnpPE3BKkOfscB5NgtUCCfHsqUftOwdw2lYycop KFHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762634216; x=1763239016; 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=I+QUvibj8npzhh/zNetpLMC5q7YGk8A7tGB6rW8zrLE=; b=mCwh19dE6PaBIyM5MBkUyE5q9iNR7VdiaowiKTKo/2O8CwH8VPHjjwYQTW+NghssSg 0cnp6//CYrGPAA5fERcq+FQWi1BfuuHYykb4aUM/0WnPMf0YN2/ZJuwJCJKSWrvMDmXY lwzT2IDzJfXbfROm6zal3ZDJXFGUkeJBv2rRdWzAnpgNpbm99vQLlVR6j7N3fEoR+RN/ 8ejznDg17muHAejIQhNn0btvtP5Nb0Oyp9g5Og7JbTGftDYmyNWkRuflROuqFI+p56FI 35kHOzVEUR5saNuRHnTAJTb0x/0Pedcu/z6v8o1TMh5FKiiRcxg+6mUjLnYdHaIFxe9+ 5v6Q== X-Gm-Message-State: AOJu0Yxo/cJXe3MmzErS9hrcEeL8jsqknph0mViq/NfqzIZSmLF0h1L0 Lh21sid3lLfSNKJwXZnZ5bxe2MjZhGuV0RuHsL+h1Q+rJbt+q3fQfbkxzRqFfkfTLTsAfwheVBv Kwt2mIMnO4MArryNWcbPc0GJocazEzcVrhc+3 X-Gm-Gg: ASbGncsYEBXNQeLyKmo0RsTxM+3DFW+vIhP+iDQxpd24yQRsmORcBLrGxMoaCj4uyBn 9OnUk0gbok0oaBCzFMOZHkFVSRhH97yjZvwyhaA0eWZjxxMWvlLY2VdrExMfVDW66qaetkZZD93 snYE74+wejrt2sDpHXOA/W2NluYnDGKelJHdVx6GNel6D5czPQYIGzBvtSfGMT7t5CZlE87J3/C lv9jjrh0CbEoQFXECM50nynsRrypQFl20fccNXo43T/dCB6XrTuof6AeKw/F8kZ4OfXHSwf69gG RPJ9Lbc8a+jJyOdWRhyJlQRtqPBt/SciJv6rLLcOaMG/ X-Google-Smtp-Source: AGHT+IFYcVhmYD6ykSck0UayROYkXnGha3ADamIHLxLw09/bQeW5/SQm7cEdIl8sQv+OUsPySYoZuUWNvSegHlcPZvQ= X-Received: by 2002:a05:622a:2d5:b0:4ed:69c2:3b13 with SMTP id d75a77b69052e-4eda4e7e348mr45287781cf.9.1762634215803; Sat, 08 Nov 2025 12:36:55 -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: <2121B7E6-0DB6-427A-9C72-640A3AEE26AA@ketas.si.pri.ee> From: Thomas Schweikle Date: Sat, 8 Nov 2025 21:36:43 +0100 X-Gm-Features: AWmQ_blo3oyROmZt-Dzij3mG6WkHOtHLnpk7CnFWbsjj8sPeoxFgkxiEcrwVsHo 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="0000000000004d4ceb06431b42ea" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d3nly146rz4J8x --0000000000004d4ceb06431b42ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 inside "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/15? 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 random > 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 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, 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 selfhos= t > >> build itself and work, except etcupdate. and that for a long time > >> > >> i don't see any reason getting pissed about his machine mysteriously n= ot > >> 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 he= re > >> > >> 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. f= ix > >> 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 coul= d > 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 machin= e > >> 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 he= re > >> > >> maybe something got lost in translation too > >> > >> > > > > --=20 Thomas --0000000000004d4ceb06431b42ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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)
=C2=A0
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
- sta= ble/15
- current

in both cases "mak= e buildetc" works as expected if not called from inside "etcupdat= e".
=C2=A0
i haven't so far studied the whole thing but if you have put noexec eve= rywhere, including tmp dirs or whatever etcupdate uses, it could be it!
=
noexec does not touch "root", but standard user= s. Does etcupdate switch to some other user while executing? Does it do so = before branching stable/15?

And just switching int= o /usr/src, then executing "make etcupdate" does call "./mk_= cmds" and it does not fail because it is forbidden to run -- it runs.<= /div>

just a wild guess. noexec is not always used and it often blows up random t= hing 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
>=C2=A0 =C2=A0 =C2=A0 =C2=A010.16 real=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 8.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/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", afte= r setting
>"chmod 0755" for "mk_cmds"? Within "/usr/src&q= uot; "mk_cmds" just does not exist
>=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*' -pr= int" 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 extra= ct" 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:<= br> >
>> 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<= br> >>
>> i don't see any reason getting pissed about his machine myster= iously not
>> working, despite i haven't broken any machine myself since i i= nstalled
>> first fbsd, 4.6
>>
>> unsure how to go from here. unsure if src.conf or make.conf matter= s here
>>
>> if this happens in currently actively supported fbsd release, mayb= e
>> etcupdate needs a bugfix to cleanup for edge cases
>>
>> if it's in unsupported, that should not cause any "pissag= es" either. fix
>> is somewhere
>>
>> so, the admin updated files manually because he was not able to ge= t 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 en= tire
>> machine works, except this?
>>
>> i mean if this was bad upgrade leftover, how to fix? i mean doesn&= #39;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 anothe= r machine
>> and compare dirs as something must differ there. then, according t= o
>> findings, fix the old machine. maybe while doing this, some new bu= gfix idea
>> appears
>>
>> but hell with getting mad over machine. he's pissed too, every= one's
>> pissed, server is not working and no productive work have been don= e here
>>
>> maybe something got lost in translation too
>>
>>
>



--
Thomas
--0000000000004d4ceb06431b42ea--