Date: Sat, 08 Nov 2025 20:59:49 +0200 From: Sulev-Madis Silber <freebsd-current-freebsd-org111@ketas.si.pri.ee> To: freebsd-current@freebsd.org Subject: Re: "etcupdate extract" -- Failed to build new tree. Message-ID: <2121B7E6-0DB6-427A-9C72-640A3AEE26AA@ketas.si.pri.ee> In-Reply-To: <CA%2BrGx5cw9zd8e-uwB0v7WHwzm6Dco%2BUtPWRtYikUW3aZ1fz8jw@mail.gmail.com> References: <CA%2BrGx5ekwmBNUJKoCOk1c-ts_Q_VXuRoQ4Krkuqey_c-KZbaXQ@mail.gmail.com> <86qzuo1ab1.fsf@ltc.des.dev> <CA%2BrGx5cF%2B-QTh95Jw1hs59Dsyk7TSAn%2BYBfWw_suNY98Q7i56w@mail.gmail.com> <868qgw14xj.fsf@ltc.des.dev> <CA%2BrGx5d3ZOXZM6yw4eyO-CbhjiCGu%2BZz1COmLiRDOOQEiOa1Qg@mail.gmail.com> <864irj1ett.fsf@ltc.des.dev> <CA%2BrGx5eKUx2KzfN=81pKrTkC6-3yhKiBn_2xgLqC5oADBuddSg@mail.gmail.com> <86jz0fyzjj.fsf@ltc.des.dev> <CA%2BrGx5dZgdMkW7zWsrbwLast8t_BhBZt6CF75H8VjW_Lez7cYA@mail.gmail.com> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> <CA%2BrGx5cUAo-93t1fTDhEeLxqrJ4ewb%2BriLfodOEhKAwNM6koig@mail.gmail.com> <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> <CA%2BrGx5cw9zd8e-uwB0v7WHwzm6Dco%2BUtPWRtYikUW3aZ1fz8jw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
first thing that comes to my mind... is there any other fs where noexec is used? especially on which the etcupdate actually runs on? 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! 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 >> >> >home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2121B7E6-0DB6-427A-9C72-640A3AEE26AA>