From nobody Sun Nov 09 01:49:23 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 4d3whl4L1dz6Fytd for ; Sun, 09 Nov 2025 01:49:43 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d3whj6MQnz3cv8 for ; Sun, 09 Nov 2025 01:49:41 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=WF6CVW31; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1762652965; bh=WRZ6IuhhV4CorOyuXs7VG14QGa8VN8TupAeIphjMyMA=; h=Date:From:To:Subject:In-Reply-To:References; b=WF6CVW31Q9lExnL2nOXd0XOxpHj4IZnildW4XD3Lys1sqUFB5OYnRSxlg0TkhHzex ZgPni+T+JTq/aUbTcWP2dcx76jAYo+KoHbTMqeU9lqn6NSuSzkiAkFHk05uA0vxltv guC1wax2MOd9p8q59qb4NaaQztZeZtOX/wg+8YSnmnZoKRTOrD/dGS1qCjvWs7NSdu 4+bSIzA1ui1SlJnYFr+4VuwyTbnD43E1+qxPfFwEkD7j8vtW1DkIp4K8fpRM5MlldW 2Ryz1vi/ununGshDBRrims/M4TGbWNLJO9mwX9YmmXId4KyUkTXNEXO6Fey18FSx6A ZuD5YBlS0wShtK2sgP9/ggzyVZsx5MrgcvW19I5UQ/bOLFV9Ki+KWq9ebKJ5EAsm7S X7Snol3AEtPmUBVEgflsvKb+FqwBqLxVmk+7lkoJH4b9ILV77lIB49r/02x7JoxoVU 1yIKxgEUby08gHKVWZtlXjnIlHdK5WmfNQMZvuJ3CTqBUSY8Vj8coJe3Ni9x+nItrZ fcB/4DP+rW8CTN8tYavWdQC3dJ8UXRAr48dDMfYe0RlZJurW/K6QSmspzXIHasIjtt kRGpOd7RS28/4A6dfxzUMWp1/ceRy4+smXrxMr7pCTgF5YG/iRH50bvAFpNjxx0vFi rzbijJYHIRUKJpWW13EfNYKY= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id EA0B15BFA7B for ; Sun, 09 Nov 2025 03:49:24 +0200 (EET) Date: Sun, 09 Nov 2025 03:49:23 +0200 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: "etcupdate extract" -- Failed to build new tree. User-Agent: K-9 Mail for Android In-Reply-To: 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> Message-ID: 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Spamd-Result: default: False [0.87 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_SPAM_MEDIUM(0.67)[0.671]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4d3whj6MQnz3cv8 On November 8, 2025 10:36:43 PM GMT+02:00, Thomas Schweikle wrote: >On Sat, Nov 8, 2025 at 8:00=E2=80=AFPM Sulev-Madis Silber < >freebsd-current-freebsd-org111@ketas=2Esi=2Epri=2Eee> wrote: > >> first thing that comes to my mind=2E=2E=2E >> >> 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)=2E > >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"=2E > > >> 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=2E Does etcupdate 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 = code will fail=2E and it indeed does give permission denied i don't know where mk_cmds is=2E perhaps in obj? i'm currently not debuggi= ng 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 disab= led 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 ha= ppens=2E 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 ca= ll >"=2E/mk_cmds" and it does not fail because it is forbidden to run -- it r= uns=2E > >just a wild guess=2E noexec is not always used and it often blows up rand= om >> thing unexpectedly=2E others have it disabled and therefore don't see i= t >> >> >> >> On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle < >> tschweikle@gmail=2Ecom> wrote: >> >Looking at the log from etcupdate I found it failing with >> > >> >chmod 755 mk_cmds >> >rm -f et-h-ss_err=2Eet et-h-ss_err=2Ec et-h-ss_err=2Eh >> >cp /usr/src/crypto/krb5/src/util/ss/ss_err=2Eet et-h-ss_err=2Eet >> >compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mit-krb5 >> >et-h-ss_err=2Eet >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h=2Eawk >> >'outfile=3Det-h-ss_err=2Eh' et-h-ss_err=2Eet >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c=2Eawk >> >'outfile=3Det-h-ss_err=2Ec' 'textdomain=3Dmit-krb5' 'localedir=3D' et-= h-ss_err=2Eet >> >mv et-h-ss_err=2Eh ss_err=2Eh >> >rm -f et-h-ss_err=2Eet et-h-ss_err=2Eh >> >=2E/mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs=2Ect >> >make[4]: exec(=2E/mk_cmds): Permission denied >> >*** Error code 1 >> > >> >Stop=2E >> >make[4]: stopped making "all" in /usr/src/krb5/util/ss >> >*** Error code 1 >> > >> >Stop=2E >> >make[3]: stopped making "bootstrap-tools" in /usr/src >> > 10=2E16 real 8=2E75 user 1=2E04 sys >> >*** Error code 1 >> > >> >Stop=2E >> >make[2]: stopped making "_bootstrap-tools" in /usr/src >> >*** Error code 1 >> > >> >Stop=2E >> >make[1]: stopped making "buildetc" in /usr/src >> >*** Error code 1 >> > >> >Stop=2E >> >make: stopped making "buildetc" in /usr/src >> > >> >It fails, because it is not allowed to "exec =2E/mk_cmds", after setti= ng >> >"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 b= e able to >> >find it: >> >/usr/src # find =2E -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=2E If called from "etcupdate extract= " it >> >fails=2E >> > >> >It works for FreeBSD: >> >- stable/13 >> >- stable/14 >> > >> >but not for: >> >- stable/15 >> > >> >Full log is attached=2E >> > >> >On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber < >> >freebsd-current-freebsd-org111@ketas=2Esi=2Epri=2Eee> wrote: >> > >> >> something bad clearly happened in that machine if it's able to selfh= ost >> >> build itself and work, except etcupdate=2E and that for a long time >> >> >> >> i don't see any reason getting pissed about his machine mysteriously= not >> >> working, despite i haven't broken any machine myself since i install= ed >> >> first fbsd, 4=2E6 >> >> >> >> unsure how to go from here=2E unsure if src=2Econf or make=2Econf ma= tters 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= =2E 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 us= es >> as >> >> input=2E but seems like it reads wrong data out of somewhere=2E 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=2E while we do that, maybe it = could >> be >> >> made to handle this=2E 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=2E at worst you could do other install in another ma= chine >> >> and compare dirs as something must differ there=2E then, according t= o >> >> findings, fix the old machine=2E maybe while doing this, some new bu= gfix >> idea >> >> appears >> >> >> >> but hell with getting mad over machine=2E 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 >> >> >> >> >> > >> >> >