Re: "etcupdate extract" -- Failed to build new tree.
Date: Sun, 09 Nov 2025 01:49:23 UTC
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 PM 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? 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 debugging 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 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=et-h-ss_err.h' et-h-ss_err.et >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk >> >'outfile=et-h-ss_err.c' 'textdomain=mit-krb5' 'localedir=' 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 >> >– 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 PM 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 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.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 >> >> >> >> >> > >> >> >