Hiya folks,

So as I see it there are two seperate problems here, one is sparc64 specific
and the other is that tty appears to retain its old session association, so
the replacement fails TIOCSCTTY with EPERM. Closing /dev/console may not close
the underlying tty while X still has it open, the consequence is getty looping
its way to narnia after init restarts it.

NetBSD addressed this in 2003, clearing the association explicitly:

        sess->s_ttyp->t_pgrp = NULL;
        sess->s_ttyp->t_session = NULL;
        SESSRELE(sess);

They changed both console close and session exit:
https://github.com/NetBSD/src/commit/401fa84c91d3dedc985d8416e5201ec76c6c77e8
https://github.com/NetBSD/src/commit/caf521f727ec3d016017d2d31f7bd7c4c4498877

OpenBSD's old SPARC X README required disabling console getty. A 2012 misc
reply pointed users to that restriction. The README was removed in 2020.

Is there a reason to retain the association after the session leader exits?
Fixing that EPERM fault should let getty recover instead of getting stuck in
a loop, although the sparc specifc keyboard input conflict would still need
addressing separately that exposed the problem in getty.

Ted