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
