Hello all,
Yesterday I was attempting to install Adelie on a PCEngines APU3. This
board has no video output, but it does have a serial console, which is
the method that the manufacturer expects users to use to install and
manage their devices with.
I wrote an Adelie Live Beta4 ISO to a USB stick, booted up, and edited
the kernel command line to include "console=ttyS0,115200". The kernel
began booting as expected and spitting out kernel logs to the serial
console; it started services, and then failed to spawn a getty on the
serial console.
Looking into this issue on IRC, some contributors and I noticed that
while there are some config options specified for ttyS0 and ttyS1
devices in /etc/conf.d/gettys, neither will spawn a getty by default.
The live media should absolutely support installation via a serial
console. This is a use case that we should expect our users and
customers to need at some point, especially considering that devices
like I described in the first paragraph of this email actually exist.
After some further discussion in IRC, the community has come up with 3
possibilities for handling this situation:
1. Configure /dev/ttyS0 to be a serial console by default with no
further checks.
My thoughts: I am personally opposed to this solution. It was
mentioned in IRC that VirtualBox (and some other systems) might take
issue with the OS assuming that ttyS0 should be a system console. I also
think that it is bad for user choice.
2. Parse the Linux kernel CLI parameters for "console=" being specified,
and use the device listed.
My thoughts: This solution seems fairly reasonable to me. Some users
brought up potential issues with this solution, and I welcome them to
elaborate further on these issues in the discussion to follow this email.
3. Parse the Linux kernel CLI parameters for a custom key, such as
"getty=", and spawn a console on the specified device.
My thoughts: This solution also seems fairly reasonable to me. It
seems like the best option for user choice, but it has the downside of
being "non-standard" in terms of what a Linux user might expect. Users
would have to be aware of this functionality by reading the system
documentation or otherwise.
I'm bringing this to the mailing list in the hopes of fostering
discussion on this issue within the community, and coming up with the
best solution that we can come up with. Feel free to comment on the
options that we've come up with, or propose your own if you can think of
something that outweighs the benefits and pitfalls of the already
proposed solutions.
Thanks!
Received on Sun Sep 08 2019 - 00:38:38 UTC