Re: serial console device, and installboot vs. /boot.cfg

[Steve Rikli <sr%genyosha.net@localhost>]

On Thu, Feb 08, 2024 at 12:43:14PM -0800, Greg A. Woods wrote:
> At Thu, 8 Feb 2024 09:31:27 -0800, Steve Rikli <sr%genyosha.net@localhost> wrote:
> Subject: Re: serial console device, and installboot vs. /boot.cfg
> >
> > Well, what I really want :-) is to be able to switch between a COM serial
> > port and a Pc keyboard without re-configuring NetBSD, and that's what I
> > was hoping for with auto.
> 
> Do you mean (also) for boot, or just for normal logins?

Also for boot. To be clear, this is really "wish list" rather than a
showstopper for me; what I have now is already pretty functional.

> Personally I find having a permanent serial console ideal, and I then
> configure logins on Kbd+VGA for normal use when in front of the physical
> machine (if the machine has such hardware).

Yes, it sounds like you operate much as I prefer to do. My somewhat
real-world scenario is serial console for nearly all admin and
maintenance activities where rebooting or single-user or
out-of-(network-)band troubleshooting is required.

But I would ideally also like to be able to wheel a PC keyboard+VGA
crash cart up to the rack if the system / hardware is truly out in the
weeds, and triage the rig from there as a bone fide system console,
without having to re-config NetBSD.

> However I do have my serial ports "permanently" connected to a terminal
> server (which are then managed by conserver), so I always have logs of
> everything on the console (as well as easy access to the console port
> via any other local system on my LAN).

Yes, agreed. This is pretty similar to my setup.

> This is also what I used to do with my older Sun and DEC Alpha systems
> as well, i.e. those that also had a framebuffer and keyboard.

My older NetBSD Suns, DECs and SGI had framebuffers, but all were
permanently serial console. I did keep a keyboard set around for each of
them, but generally it was not connected full-time.

> Terminal servers were ultra-cheap back when small ISPs were either
> turning off their modem banks, and/or being absorbed by giant ISPs.
> There are still lots available on eBay, for example, but they're not
> quite as low-priced as they were when the market was flooded.

More's the pity. I have shopped occasionally for new units, if only to
have some idea what I might do when my serial terminal server dies at
some point, if my spares aren't sufficient to resurrect or replace it.
Unfortunately pickings were slim and expensive, so it will likely be
something on the used market when the day comes.

> > "auto" activates the serial console in my config, but the Pc keyboard+VGA
> > sees no boot messages or menus, which feels like "auto" and "com0" are
> > effectively the same in my setup. More experiments warranted.
> 
> See x86/boot_console(8).
> 
> Auto tries to use the first working COM port, and if they all fail it'll
> resort to "consdev=PC".

Yes, I read that part, but I couldn't replicate the described behavior.

What constitutes a "fail" for the COM port? Iirc the man page said
"outputs a character" to each COM port, and if it succeeds then that's
the console; else it goes to the PC keyboard for console.

So I unplugged my terminal server cable and db9 hood from the COM port
of the PC, rebooted the PC, and watched VGA+keyboard for activity; after
BIOS post, I never saw loader banner or boot messages etc. there,
nothing until a ttyE1 login: prompt. After that I plugged serial cable
back into the COM port, saw the expected login: prompt, and dmesg still
reported com0 as the console.

On this particular subject, boot_console(8) describes that behavior for
CONSDEV_AUTO used as the policy for the SUPPORT_SERIAL=policy option.
When I mentioned "auto" above, I was referring to using it as an option
in the installboot(8) command to re-write the bootstrap with serial
console settings, e.g.

installboot -v -o console=auto,speed=115200 /dev/wd0a /usr/mdec/bootxx_ffsv2

It seems like those are related, maybe two different documentation
sources for the same mechanism? In any case, I couldn't get the console
to "fail over" from disconnected serial port to keyboard. Maybe I'm not
properly causing a COM port "failure" in my experiment.

Thanks,
sr.