== A surprise: you can only have one Linux kernel serial console One of Linux's nice features is that not only does it support [[serial consoles SerialConsoleLove]], but you can have the conventional video console too. This is important for us because [[often we want to use the video console ../sysadmin/DroppingSerialConsoles]]. The video console is where we usually interact with the system in person, while the serial console goes to [[our console server ../sysadmin/ConsoleServerSetup]] for logging. (Logging in over the serial console remains somewhat useful if the system's networking isn't working for some reason, and [[systemd makes it easy SystemdSerialPortsFixedBaud]].) However, recently I discovered a limitation of Linux's serial console support, which is that you can only have one serial console, or to put it another way you can only have kernel messages going to one serial port, not two or more ([[this is one of the several 'consoles' that Linux has ManyConsolesOfLinux]]). This is relevant (at least to us) because many servers today have two serial ports you might want kernel messages to go to; one physical one, which you can connect to your console server, and one virtual one supplied by the [[BMC ../tech/IPMIAndBMCTerminology]], which you can connect to over IPMI or sometimes see (perhaps including some scrollback) on the BMC's web interface. (This limitation is spelled out in a short sentence in [[the kernel's serial console documentation https://www.kernel.org/doc/html/latest/admin-guide/serial-console.html]], where it says '[n]ote that you can only define one console per device type (serial, video)'.) In theory perhaps you could do everything over the IPMI and not use the physical serial console; [[conserver https://www.conserver.com/]] supports 'Serial over LAN', for example. In practice, [[servers don't always have dedicated BMC network ports ../sysadmin/IPMISharedInterfaceProblem]] and 'Serial over LAN (IPMI)' has a lot more complexity and thus things that can go wrong as compared to simple physical serial consoles. If my goal is to capture as much as possible if the system goes into a terrible state or bits of the network start having problems, serial consoles are generally the best option. (For capturing kernel messages there's also the kernel's [[netconsole https://www.kernel.org/doc/html/latest/networking/netconsole.html]] system. I have [[mixed views on it NetconsoleMixedViews]] that are outside the scope of this entry.) PS: If you list multiple serial ports in console= kernel command line arguments, I believe the kernel uses the first one and ignores the rest. I further believe that systemd behaves the same way as far as its automatic serial getty support goes. You can directly enable a serial getty yourself, of course.