Enabling getty on a Virtual Terminal (VT)

    Hello,

    I am trying to enable a virtual terminal on a libreelec master image (PROJECT=NXP DEVICE=iMX6 ARCH=arm UBOOT_SYSTEM=cubox-q make image).

    ALT+CTRL+F3 does not work.

    The kernel seems to provide tty0..63.

    But I neither find a getty systemd service not a getty binary.

    Can anybody tell how to get this done?

    Thanks

    Rainer

    I don't think getting a virtual terminal window on most embedded builds is possible without some serious changes to LE at a core level in how it interacts with the Linux kernel because once Kodi pulls the system up and is the controlling app switching terminals or windows becomes a different thing then the simpler jeos model LE and its spin-offs used.

    I can't speak for all the various platforms that LE builds for but most embedded ones that i have looked at they all seem to be hindered with the same issue.

    Someone correct me if i am wrong tho.

    The usual suggestion if you need a terminal is to ssh into the device.

    That being said i will say from my own experiences in trying to get working/switchable terminals or windows it took some serious rethinking and understanding of how LE works within the JEOS manner to make the alterations and it was something never posted publicly as it it really breaks the ideology of LE which would not be fair to all its developers and their good work.

    • New
    Quote from buzzmarshall

    Someone correct me if i am wrong tho.

    While the usual VTY console may not be easily available, it is still possible to use the kernel serial console. This is possible with many embedded platforms such as Raspberry Pi supporting serial connection over the UART pins. To do this, just configure the kernel commandline options with the serial device name, rate, and optionally the data bits, parity, and stop bit settings:

    Code
    boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 console=ttyAMA0,115200n8 console=tty0

    In the above example on a Raspberry Pi 2B with OpenElec, the device /dev/ttyAMA0 is attached to the BCM GPIO pins: 14 & 15 (physical pin header pin numbers: 8 & 10). It's possible to set multiple outputs as in this example. The kernel commandline options tell the kernel to output boot messages to both /dev/ttyAMA0 and /dev/tty0. Omitting the usual quiet option turns off silent boot so kernel boot messages will be shown.

    For Raspberry Pi specifically, we also need to turn on the UART in config.txt:

    Code
    # enable_uart - Requests that the kernel creates a serial console, accessible
#               using GPIOs 14 and 15 (pins 8 and 10 on the 40-pin header)
enable_uart=1

    Finally, to get a tty on /dev/ttyAMA0, the init system needs to start an instance of getty on this serial device. However, the absence of the getty busybox binary on OpenElec / LibreElec presents a problem. We need to enable this during busybox build by changing busybox's target configuration to have CONFIG_GETTY=y - see target config here LibreELEC.tv/busybox-target.conf at master · LibreELEC/LibreELEC.tv · GitHub

    To have this automatically started by SystemD, you'll need to add the SystemD unit (and enable it) so getty gets started on boot. It looks like both OpenElec and LibreElec removed the getty.target as well as the [email protected] template. So, we will need to place these files back into the root filesystem again. Upstream SystemD has a double-templated version of [email protected] here, which can be used as a starting point. When placing this into the filesystem, remove the {% if ... %} ... {% endif %} sections, because these are Jinja2 template instructions used by SystemD's Meson build system. We want to make sure the resulting SystemD template service has no Jinja2 instructions, so it conforms to the usual SystemD unit syntax. Note that the .in suffix denotes that this file is a build-time template, in this case using Jinja2 syntax for use with Meson. To place it back into the file system, remove all Jinja2 syntax and edit as if you were rendering the Jinja2 template by hand, then place it in one of the SystemD unit directories with filename: [email protected]. It may help to double check the resulting SystemD unit file syntax is valid with: systemd-analyze verify /path/to/[email protected]

    The one thing I'm not sure about here is the KillMode=process option, which according to the Jinja2 template is only enabled if SystemD logind is used. Maybe someone more familiar with LibreElec system internals can clarify whether this is needed on this OS?

    Because the version of getty used is from busybox, the supported command line arguments may be slightly different. Adapt the typical (a)getty options into busybox's supported getty command options to workaround that. You can either use udev rules or a fixed device instead of a SystemD unit template (the units ending in @.service are templates). In the [Install] section, you can probably install it to multi-user.target, or try leaving it at getty.target so long as that one is copied into the root filesystem and enabled too.

    If you choose to use a /etc/udev/rules.d drop-in, make sure to tag it systemd and pass the device name for the SystemD template into systemd-escape, to avoid any issues with converting special characters into a valid SystemD unit + instance name.

    For example:

    Code
    KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", TAG+="systemd", PROGRAM="/usr/bin/systemd-escape -p [email protected] $env{DEVNAME}", ENV{SYSTEMD_WANTS}+="%c"

    This example udev rule will be used by systemd-udevd to start an instance of the [email protected] template for each device matching pattern: /dev/ttyACM[0-9]*. Alternatively, if you know that only a single serial TTY device will ever be connected to the system, you can simply convert the SystemD unit template into a static non-templated unit file, and replace the template variables (e.g. %i, %I) with the static device name: ACM0. Then just enable that SystemD unit so it will start on boot.

    Hopefully this helps those looking to get some form of serial console access working with LibreElec on these embedded platforms such as Raspberry Pi. For more help on how to actually connect with and use a serial console, see "Raspberry Pi Hacks" by Ruth Suehle, Tom Callaway, specifically the section titled: "Hack 16. Add a USB Serial Console". (Hint: Use GNU screen, minicom, picocom, PuTTY, or similar tools)