want grub composite console
In order to support flexible use of GRUB, it would be nice if there were a composite serial/BIOS console option.
Currently, GRUB allows the use of multiple terminals in its menu.lst or on the command line; however, all this does is cause a message to be emitted to each such terminal once per second for some predefined length of time. If the user presses a key on one of the terminals during this window, the terminal on which the input was received will be used for all subsequent input and output. If not, the first listed terminal is used. This approach has two major disadvantages: first, it wastes time during boot even in the common case in which the terminal(s) are not in use; second, it interacts poorly with console redirection. Most systems, when console redirection is set to "always" or similar, will cease redirecting once software uses the serial port. Systems that support a "bootloader" or "until boot" option will cease redirecting as soon as control is handed off to a ROM or boot sector. In either case, this means that if the user monitoring the console misses the opportunity to press a key, one of the terminals (BIOS console or serial) will be unusable for purposes of manipulating and observing the bootloader.
The approach iPXE takes is to do output to and accept input from every compiled-in console; unfortunately, it does not accept any runtime console configuration. Since there is no way to boot from USB once iPXE has been loaded by GRUB, it would be very useful if both GRUB and iPXE could work the same way – then either terminal will always be usable no matter which bootloader is active at the moment, even if no input has been received.
Finally, in order to get clean output on both terminals, a separate bug will cover changing the firmware configuration to use the "until bootloader" redirection setting; for reasons yet unknown, iPXE does not cause the BIOS console redirection to stop otherwise. This results in (a) terminal escape sequences being duplicated byte by byte causing garbled output, and worse (b) alternate characters to be intercepted by the BIOS redirection and passed through to the serial port buffer. The result is a system entirely unusable on any terminal.
With all of this in place, we have the following sequence:
1. Prior to the execution of GRUB stage2, all output is to the BIOS console, and the firmware handles intercepting input from either serial or keyboard and replicating output onto both VGA and serial. This allows for configuration of firmware parameters as well as use of the EFI shell if desired.
2. From the point GRUB stage2 executes, throughout GRUB and iPXE execution, bootloaders will be responsible for replicating output and for multiplexing input. This allows use of either VGA/keyboard or serial (or any combination of the two, if you're insane) for the entire boot process until control is transferred to the kernel.
3. The kernel will select a single console based on the arguments passed by the user or booter during the previous phase. Thus, there are multiple mechanisms that may be used to select the console used by the kernel regardless of which device one is actually using.
We are not, however, done yet. In order to support firmware upgrade and configuration, it's presently impossible to avoid booting DOS (yes, DOS – those born after 1985 or so are advised to consult an historical reference). DOS has no concept of consoles other than the BIOS console, which will (because we've already written to the serial port directly) always reference the VGA/keyboard terminal. An alternate solution will be required to make this work correctly, most likely using FreeDOS and ctty. This will be covered under a separate bug as well.
Updated by Electric Monk almost 5 years ago
Author: Keith M Wesolowski <firstname.lastname@example.org> 4656 want grub composite console 4657 want grub support for cross-menu OS console variable 4658 uninitialised variable trashes command line on coal Reviewed by: Dan McDonald <email@example.com> Approved by: Garrett D'Amore <firstname.lastname@example.org>