On 2026/03/11 10:18, Theo de Raadt wrote: > Stuart Henderson <[email protected]> wrote: > > > On 2026/03/11 16:56, Claudio Jeker wrote: > > > On Wed, Mar 11, 2026 at 09:42:31AM -0600, Theo de Raadt wrote: > > > > Claudio Jeker <[email protected]> wrote: > > > > > > > > > On Wed, Mar 11, 2026 at 08:47:11AM -0600, Theo de Raadt wrote: > > > > > > Claudio Jeker <[email protected]> wrote: > > > > > > > > > > > > > On Sat, Mar 07, 2026 at 12:40:33AM +0100, Christian Weisgerber > > > > > > > wrote: > > > > > > > > -current/amd64 > > > > > > > > > > > > > > > > "make build" fails if /usr/obj is on an MFS. Specifically, > > > > > > > > configure > > > > > > > > fails in usr.sbin/nsd: > > > > > > > > > > > > > > > > $ doas mount -tmfs -o-s=1g swap /usr/obj > > > > > > > > $ cd /usr/src/usr.sbin/nsd > > > > > > > > $ make -f Makefile.bsd-wrapper obj > > > > > > > > $ make -f Makefile.bsd-wrapper > > > > > > > > ... > > > > > > > > checking for a sed that does not truncate output... configure: > > > > > > > > error: no acceptable sed could be found in $PATH > > > > > > > > *** Error 1 in /usr/src/usr.sbin/nsd (Makefile.bsd-wrapper:46 > > > > > > > > 'config.status') > > > > > > > > > > > > > > > > I suspected one of the recent pledge commits and tried to > > > > > > > > bisect, > > > > > > > > but it already fails with a kernel from 2026-01-30... and I > > > > > > > > don't > > > > > > > > think it did back then. Puzzling. > > > > > > > > > > > > > > I see the same problem on sparc64 but there the last working > > > > > > > kernel is: > > > > > > > OpenBSD 7.8-current (GENERIC.MP) #77: Mon Feb 16 19:45:43 MST 2026 > > > > > > > > > > > > > > [email protected]:/usr/src/sys/arch/sparc64/compile/GENERIC.MP > > > > > > > > > > > > > > Broken since: > > > > > > > OpenBSD 7.8-current (GENERIC.MP) #79: Wed Feb 18 18:23:56 MST 2026 > > > > > > > > > > > > > > [email protected]:/usr/src/sys/arch/sparc64/compile/GENERIC.MP > > > > > > > > > > > > > > For me this looks like a problem with the pledge commits around > > > > > > > Feb 26. > > > > > > > > > > > > Huh? 18th or 26th? > > > > > > > > > > The snap from the 18th fails for me but when I build my own kernel > > > > > on the 24th seems to work but 27th fails. Depending on the snap > > > > > installed > > > > > the behaviour is different. In other words it seems that userland > > > > > changes > > > > > are part of the reason for this strange failure. So tracking that > > > > > down is > > > > > a lot more complex since it is not a simple kernel regression. > > > > > > > > That's infuriatingly vague. > > > > > > > > ktrace or it didn't happen. > > > > > > > > Or maybe we should just remove ktrace from GENERIC because the people > > > > who > > > > KNOW it is the right tool to use don't reach for it. > > > > > > There is no smoking gun in ktrace. So yes, it is frustrating and the way > > > to reproduce it is simple. I'm actually instrumenting the configure script > > > now to see what the heck is going on. > > > > - diff "conftest.out" "conftest.nl" >/dev/null 2>&1 || break > > + ktrace -di -f ktrace.out.`date +%s`.$RANDOM diff "conftest.out" > > "conftest.nl" >/dev/null 2>&1 || break > > On Feb 18, it was changed like this: > > @@ -211,7 +211,11 @@ main(int argc, char **argv) > argc -= optind; > argv += optind; > > - if (pledge("stdio rpath tmppath", NULL) == -1) > + if (unveil("/tmp", "rwc") == -1) > + err(2, "unveil /tmp"); > + if (unveil("/", "r") == -1) > + err(2, "unveil /"); > + if (pledge("stdio rpath wpath cpath", NULL) == -1) > err(2, "pledge"); > > /* > > > I cannot think of any reason why that would fail. That's classic unveil > + pledge use. >
It's because of a stacked mount (/usr/obj MFS on top of /usr/obj disk)
