CentOS7 – Serial Console And Flow Control
Hello List,
I’m ironing out details to upgrade a few systems to CentOS7.
My servers have BMC with Serial over LAN support. In C5 and C6, I
determined how to have BIOS/POST, kernel, and serial console access. I’m reading up on the method to accomplish the pieces with C7.
Presently SoL output works, so I see BIOS/POST messages and the GRUB boot list. My changes to enable serial redirection for the kernel do not appear to work.
I’ve made the following changes to GRUB2’s /etc/grub/default config file:
— removed rhgb
— added the console= settings to GRUB_CMDLINE_LINUX
— added the last two lines related to serial as detailed here [0].
* Is there an option to enable hardware flow control?
I recall having to turn on flow control (agetty -h) to make it behave. No mention of flow control at [1] or [2]. Nor does RHEL7 doc [3] mention it.
I’ve already tweaked the systemd service I generated for ttyS1 (I’m using COM2 for SoL) and added the agetty “-h” option (for hardware flow control). Despite modifying the baud rate to reflect the BMC’s settings, I only get symbols (so the console settings are amiss).
Would anyone be so kind as to share their experience?
What has worked for your BMC/SoL configurations?
[0] https://fedoraproject.org/wiki/GRUB_2#Enable_Serial_Console_in_Grub
[1] http://www.gnu.org/software/grub/manual/grub.html#Serial-terminal
[2] http://www.gnu.org/software/grub/manual/grub.html#serial
[3]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-GRUB_2_over_Serial_Console.html
[4] https://lists.CentOS.org/pipermail/CentOS/2014-October/146719.html
9 thoughts on - CentOS7 – Serial Console And Flow Control
I have a C7 server with a physical RS-232 console, but the config should be similar. I did not have to generate a systemd service for this;
systemd saw the console line and automatically started the getty without me having to generate a .service file (as far as I recall all I had to do was generate the proper /etc/default/grub, and then run
‘grub2-mkconfig -o /boot/grub2/grub.cfg’ and it Just Worked).
Now, I have the system set for console on both the VGA and on ttyS0, and I am not using flow-control. Here’s what I have that works (again with a physical ttyS0):
[root@backup670 ~]# cat /etc/default/grub GRUB_TIMEOUT=5
GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_SERIAL_COMMAND=”serial –unit=0 –speed
Mike – st257 wrote:
determined how to have BIOS/POST, kernel, and serial console access. I’m reading up on the method to accomplish the pieces with C7. boot list. work. file: — removed rhgb
You did take out “quiet”, too?
mark
I did not. I would expect what shows up on the VGA console to be identical on the serial console.
I’ll give that a shot today.
To make matters more complex, this is an offsite box for which I’ve implemented full disk encryption. And if I don’t get the LUKS passphrase prompt on the serial console, well I’m in a bind…
For the LUKS prompt to show in text mode you do have to remove the quiet. I’d be interested in finding out if the /etc/default/grub that I
posted works for you (with the proper change in UUID’s of course).
The key things for me to get this working was getting the bit rate correct (the GRUB serial port settings do not propagate to the kernel;
you have to set all the serial port settings on the kernel command line); you have to make sure the bit rate of the kernel’s serial console and your SoL BMC are the same (and your original problem description made it sound like they were not set up the same); the documentation to set this up is found in
/usr/share/doc/kernel-doc-3.10.0/Documentation/serial-console.txt which is part of the kernel-doc package.
For hardware (RTS) flow control at the kernel (and assuming your SoL
uses 115200 for the bit rate, and assuming you want the VGA to still be a console), you might want the parameters:
console=ttyS0,115200n8r console=tty0
You don’t actually have to keep the VGA as a console, incidentally, for either GRUB or the kernel. I have run a machine that way before. I
personally am not a fan of using flow control on a console; I tend to just set the bit rates lower (I have gotten burned before by RTS/CTS
flow control on a device console). But that’s just my personal preference; the ‘r’ at the end of the parameters for the serial console selects RTS/CTS flow control.
By default the kernel will set up the serial console for 9600n8
operation, regardless of what you set it for GRUB or the serial console redirect in your BMC setup.
I’ll reiterate that systemd does the Right Thing for the case of a serial console, and spawns a getty with the same parameters as you set on the kernel’s console line; you do not need to create a separate
.service file for the serial console’s getty, in my experience.
Replying to myself with a correction to my statement and a clarification…. while it is documented this way, I do remember having a bit rate mismatch without specifying a bit rate of 9600, so it’s possible the default bit rate was changed upstream. And it’s possible I
that I am remembering incorrectly, and just put the parameter there anyway.
I started to compose this message, then got busy with other work… Hopefully I’ll have better details by the end of today.
Thanks Lamar!
I didn’t have Term Output specified as you do. Probably the biggest problem right there, g’ah!
( will know when I have a moment to test )
I didn’t have the option to disable Plymouth.
I see you don’t have flow control enabled, otherwise you’d have 9600n8r I’ll try it without n8r.
The baud rate I used is not specified in any of the service files systemd generates. But as you’ve said I should _not need_ a service file (which is much like CentOS6 behaved with serial kernel params).
Mike – st257 wrote:
Do. That hides everything before the o/s switches root. It’s *possible*
that it’s hiding where you’re being prompted for the LUKS password. Personally, I’d have left / unencrypted….
mark
I’ve been doing some testing now that it works and “quiet” did not hide the LUKS passphrase prompt on the serial console. (More details in a future message.)
I appreciate the suggestion because it very well could have. Another one of those “shouldn’t but did cause X problem” ;-)
While my environment is not entirely hostile, it is one where I cannot control physical access. So while the thought crossed my mind to leave rootfs unencrypted, I opted not to (but to encrypt!).
Huge thanks to those who chimed in. An issue of PEBKAC on my part (but I was soooo close!).
I’m using COM2 (ttyS1) and leaving the physical COM1 (ttyS0) alone so it could be used with null modem or Cisco console cables. Slight difference, nothing that makes them wildly different.
I didn’t need GRUB_SERIAL_COMMAND, but… I have “Redirection After Boot” enabled in my BIOS for the serial console, which is how I’m still able to see the GRUB prompt. And likely why I can omit the GRUB_SERIAL_COMMAND line.
I also read about but did not need GRUB_TERMINAL=serial
I got away with keeping the default of:
GRUB_TERMINAL_OUTPUT=”console”
I found things functioned fine _with_ “quiet” and without rd_NO_PLYMOUTH
*hangs head* My PEBKAC was on the serial device … I had /dev/ttyS1
instead of just _ttyS1_ … my bad.
GRUB_CMDLINE_LINUX=”rd.luks.uuid=luks-1ad0ae71-75fa-46cf-aa5b-70e63c51a485
rd.lvm.lv=storage0/rootfs rd.lvm.lv=storage0/swap crashkernel=auto quiet console=tty0 console=ttyS1,57600n8r”
You are absolutely right, no need to modify service files (just like was the case with Upstart in EL6).
~]# cat /etc/default/grub GRUB_TIMEOUT=5
GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT=”console”
GRUB_CMDLINE_LINUX=”rd.luks.uuid=luks-1ad0ae71-75fa-46cf-aa5b-70e63c51a485
rd.lvm.lv=storage0/rootfs rd.lvm.lv=storage0/swap crashkernel=auto quiet console=tty0 console=ttyS1,57600n8r”
GRUB_DISABLE_RECOVERY=”true”