Package: getty-run
Version: 2.2.0-3

I noticed this after a dist-upgrade to Devuan excalibur when I started
getting some kernel log spam:

serial8250 serial8250: LSR safety check engaged!

Looking at /etc/sv/getty-ttyS0/run, I first tried
echo DISABLED >/etc/sv/getty-ttyS0/env/SGETTY
– that didn't work.

So I had a closer look at the script and noticed that there's a difference between the two `grep` commands: the first one has no ‘\b’ at the start whereas the second has that ‘\b’.

My kernel command line contains “netconsole=…”, because I've occasionally found it useful for diagnosing hard hangs, but otherwise no “console=…”; so
the first `grep` was matching on that and the second one was not matching anything, meaning that $kconsole="", this later being copied into $SGETTY – which is then set to “ttyS0” if empty. Oops.

Adding that ‘\b’ to that first `grep` command is sufficient to fix this. (It looks like it's possible to reduce this to one `grep` invocation.)

Incidentally, I've now removed the symlink in /etc/service as I don't
presently need a console on a serial line.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)