Re: [OE-core] [PATCH 2/2] systemd: use getty generators by default

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Thu, Jan 30, 2025 at 05:59:01PM +0000, Ross Burton via lists.openembedded.org wrote:
> systemd can automatically create getty service units at boot time by
> probing the hardware: if will check for a list of known hypervisor
> consoles and also spawn a getty on every active console.
> 
> However in a historical attempt to change as little behaviour as
> possible, we disabled this and instead wrote hard-coded units at build
> time that respect the SERIAL_CONSOLES variable.
> 
> This variable may be acceptable for fixed known platforms, but is not
> usable for generic machines. The genericarm64 machine for example lists
> a number of potential consoles:
> 
> - ttyAMA0: physical ARM PL011 uarts
> - hvc0: hypervisor virtual console
> - ttyS0-2: physical uarts
> 
> We have to list multiple ttyS? names because different platforms use
> different devices: specifically on the BeaglePlay the Linux console is
> ttyS2, with S0 and S1 being the uarts connecting the expansion port.
> 
> However, it's not ideal to randomly open ports and hope for the best:
> with kernel 6.7 onwards a power management/tty bug results in system
> hangs if a getty is sitting on ttyS1 (see #15704).
> 
> A better solution is to just use the getty generator in systemd: this
> will automatically spawn gettys on any hypervisor consoles found and all
> of the consoles that Linux is aware of. On the BeaglePlay this means
> it puts a getty on just ttyS2, as expected.
> 
> The fixed configuration recipe is still present for people who wish to
> have absolute control by simply disabling the serial-getty-generator
> PACKAGECONFIG.

ACK, we have also found that systemd and udev handle serial consoles
correctly when supporting multiple devices like rockpi4b, synquacer,
AMD KV260, zcu102, AVA, qemu etc from a single build. 

systemd-serialgetty did not work so well.

Cheers,

-Mikko