On 2026/03/11 09:42, 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.
> 

The command where behaviour changes is diff.

~sthen/kdump.diff.mfs
~sthen/kdump.diff.nomfs

With the MFS it tries to stat conftest.out and gets ENOENT, without the
MFS it succeeds.

Reply via email to