Re: port-vax/60478: releng testbed is busted on VAX

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-vax/60478; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, campbell+netbsd%mumble.net@localhost
Subject: Re: port-vax/60478: releng testbed is busted on VAX
Date: Sat, 25 Jul 2026 08:43:01 +0700

     Date:        Fri, 24 Jul 2026 13:01:06 +0300
     From:        Andreas Gustafsson <gson%gson.org@localhost>
     Message-ID:  <27235.14306.517467.218498%guava.gson.org@localhost>
 
   | That is probably the wrong question to ask.  When tests fail on the
   | testbed, in the vast majority of cases, it means the testbed has found
   | a bug in NetBSD (or in this case, more than one), not that NetBSD has
   | found a bug in the testbed.
 
 Agreed, though in this case it wasn't tests failing, but the install.
 
 I also didn't believe there was any bug in the testbed, I just want to
 (if I can) try and work out what the differences are between the i386
 (and perhaps others) versions and the amd64 (and clearly vax) version,
 so I can understand better why the latter hit the bug I inserted into
 sh, and the former did not.    Something different is happening there,
 but I am not suggesting that difference is a bug - I'd like to know what
 it is so I can make sure that sh (which has one bug, or a different one,
 at the minute) can get correctly fixed.
 
 [Aside to anyone reading this for fun: the sh bugs I mention aren't ones
 you are going to encounter accidentally, you have to work fairly hard to get
 things into a state where anything will go wrong, and right now, the
 "wrong" tends to be just an inconvenience in most cases ... it was slightly
 worse during the brief period my "fix" was installed.]
 
   | And when different ports behave differently, it's usually because
   | of actual differences between the ports that will also manifest
   | outside the testbed environment.
 
 It could be that, but this all failed very early in the install process
 (as in, nothing really ever got installed).
 
   | This, too, probably means NetBSD/i386 and NetBSD/amd64 behave
   | differently, not that anita tests them differently.
 
 It could be indeed. The issue (for me) is that there are 4 different
 ways that sh can run processes depending upon its state at the time.
 For non-interactive non-job control (just running a simple script) it
 is all quite simple (and that part works fine).  With both interactive
 and job control enabled (a typical sh terminal session) it also works.
 An interactive shell without job control (something very rare these
 days, but which was, long ago, the normal state) setup is also quite simple,
 and probably still works as well as it ever did.
 
 Non-interactive shells using job control are where the issue arises, there
 is currently an easily demonstrable bug in the way that works (easy to show,
 but it takes a weird script to cause it), which is what I was attempting to
 fix (but the "fix" was clearly a little too easy ... it involved a minor
 change to the condition on exactly 1 "if" statement).
 
 The change could only have affected a non-interactive shell using job
 control - so what I am trying to understand is the mechanism by which
 the amd64 and vax installs get into that state (it isn't something most
 normal shells ever achieve) whereas the i386 one does not.   Generally
 job control is just on by default in an interactive shell (where it all
 works) and off in non-interactive ones (and none of this would happen).
 
   | I believe we are dealing with two different bugs.
 
 I agree.
 
   | If your sh change was fully reverted,
 
 It was, as far as code was concerned - there was also a semi-related
 man page update, "semi-related" just because I noticed the wording in
 one section (related to the "-i" (interactive) option) could be improved,
 and altered that at the same time, nothing really related to the code change,
 and that (man page change) I did not revert.   That could not sanely
 be related (and I have seen your later mail, and know it wasn't).
 
   | it can't be the cause of the ongoing vax breakage.
 
 No, I didn't really think it would be.   The PR kind of suggested it was,
 but that made no sense to me, and so thanks for taking the time to find
 out what it was.   The current issue was from enabling DEBUG in ld.elf_so
 which turned on all the assert()s - some of which were broken.   It will be
 interesting to discover if it is still broken now, after (it is at least
 believed) that all of the broken ones of those have been fixed.
 
   | The install console logs show different error messages before and after
   | the reversion:
   |
   | https://releng.netbsd.org/b5reports/vax/2026/2026.07.19.16.16.04/install.log
   |
   | init: kernel security level /install.sh: Cannot set tty process group (Bad file descriptor) at 1462
 
 Yes, that one was mine change.   The "bad file descriptor" is that for
 the controlling tty, which will be -1, as this is a non-interactive shell
 which should have no (relevant) controlling tty (if it were interactive it
 would have one, and all would be OK, but non-interactive shells shouldn't be
 doing anything to any controlling tty, whether the process has one or not).
 
 Clearly the shell shouldn't be attempting to set process groups on ttys it
 doesn't possess, and that I will fix, but I'd really like to find whatever
 it is that is causing job control to be enabled -- if it wasn't on, nothing
 would be doing anything with process groups - everything just remains in
 whichever one the kernel (or its parent) assigned to the shell itself.
 
 
   | https://releng.netbsd.org/b5reports/vax/2026/2026.07.21.04.05.06/install.log
   |
   | [   1.0700030] kern.module.path=/stand/vax/11.99.7/modules
   | [   1.0800030] WARNING: preposterous TOD clock time
   | [   1.0800030] WARNING: using default initial time
   | Fatal error
   | Enter pathname of shell or RETURN for /bin/sh:
 
 And yes, ld.elf_so calling abort() because of an assert failure (in init
 or sh) is a very good candidate for what happened there.  (The time related
 warning messages I suspect are "normal", and unrelated.)
 
   | I have kicked off a couple of builds to narrow down when the new
   | error appeared.
 
 Thanks again for that (and as I said above, I did see the result).
 
 I'd still appreciate knowing if there is any difference at all between
 the way anita is run on amd64 (and vax perhaps) and on i386 ?   I'm not
 suggesting anything is wrong, or needs changing, I'm just looking to
 understand the code paths inside sh.   If one perhaps uses ptys and the
 other pipes or something, that might explain things - at least it would
 give me somewhere to look.   On the other hand, if the two use identical
 configs, then it must be something about the way init or /etc/rc works,
 or how the kernel sets up the state of the world when a single user shell
 is to be invoked.   But I'd prefer to work from how it all starts, and that
 is from anita.
 
 kre