> > I would be entirely happy to have no FB whatsoever, even if there is
> > video chip on the motherboard.
> >
> > The ONLY time I need to see the video is for BIOS settings when first
> > configuring a system. I have no interest whatsoever in the BIOS if
> > Linuxbios can do everything I want. Consoles on the serial line is the
> > most "standard" way, but others like USB or ssh are all viable.
>
> What does SSH have to do with the console at boot time and what would
> it take to use USB as a "serial console" once legacy UARTs are extinct?
OK, didn't make myself clear. :)
The point I was trying to make is not "let's use SSH to monitor
Linuxbios"; I was trying to say "using Linuxbios removes the need to
support an unnecessary video console, since our cluster nodes only ever
use it for the vendor BIOS" and agreeing with the observation that Linux
and LILO can use any serial-line like entity for a console.
I use "console" here in the UNIX sense of "the character device which
gets the kernel messages"; I have to remind myself that in today's
world, "console" frequently means "the cathode ray tube in front of
which I sit and the keyboard where I enter Ctrl-Alt-Del").
The original context was...
> Doesn't that mean that you don't get any video until after linuxbios+linux
> has booted? Wouldn't most people like to see progress messages during the
> kernel boot?
It's very tempting fallacy to think that because something like a video
console is easy and convenient for ME, it must be easy and convenient
for YOU. Yes, I want to see the messages but NOT VIA THE VIDEO. Why?
Because I can't grep video. If the machine is question is in rack slot
#374 of a hosting center in another timezone, it's completely bloody
useless to the sysadmin.
Please understand that I do not wish to prevent anyone who wishes to use
a keyboard/screen console from using one - I'm simply making the point
that for us, video consoles actually get in the way. Even if 90% of
users want a video console, that's no reason to force the remaining 10%
to do so. I have tried to explain this with hardware and BIOS vendors,
and (predictably) got nowhere.
I would vastly prefer that Linuxbios...
(a) does not depend on the presence of a video card
(b) can completely ignore a video card even if one exists
...because I don't want...
(a) Linuxbios code to be bigger than necessary
(b) Linuxbios development to depend on support for hardware I don't need
(c) To enable any hardware I'm not actually using
These principles apply to any hardware, so substitute read "hardware I
don't need" for "a video card" above. I'm being defensive - we are
interested in resilient clusters, and so as far as possible I want to
reduce complexity.
I then reacted to...
> >> Not necessarily. One of the most amazing things about Linuxbios is
> >> that it may be possible to watch boot progress over SSH, or the serial
> >> port, or something else like that.
Not really "amazing"; you can watch it over a serial line now, but
that's thanks to LILO and Linux, not Linuxbios per se. The only reason
you can't do everything you want over a serial line is the braindead
vendor BIOS we all get in standard PC kit.
Obviously SSH is only any use once there's an IP stack, though it's
clearly still useful to follow the progress of the rest of the boot
without needing any other hardware. As to USB, I know that keyboards can
be plugged into it, so presumably the UART migrates from the motherboard
to a USB dongle.
We can generalise this to "the console can be use any hardware with
which a driver and protocol that can provide a suitable Linux char
device".
