Well, I hoped that you'd simply change that order in the service file
(I'm new to this, do you expect me to produce patch or something like
that?). Otherwise serial comm doesn't work, at least for me.
On 1/14/21 3:06 PM, Michael Biebl wrote:
Am 19.12.20 um 16:47 schrieb Andreas Henriksson:
Control: tags -1 + moreinfo
On Wed, Dec 16, 2020 at 11:39:06PM +0100, Michael Biebl wrote:
Am 16.12.20 um 20:49 schrieb MK:
Package: systemd
Version: 241-7~deb10u5
Severity: normal
[...]
Incorrect order of arguments to agetty in the
serial-getty@ttyS0.service
unit file.
It is:
ExecStart=/sbin/agetty --autologin root -8 --keep-baud
115200,38400,9600 ttyS0 xterm-256color
While it should be like:
ExecStart=/sbin/agetty --autologin root -8 --keep-baud ttyS0 115200
xterm-256color
[...]
According to the examples in man agetty, both should work.
Andreas, can you comment here?
If what MK is saying, should the "EXAMPLE" section in man agetty be
updated?
I don't really have much prior knowledge about *getty, but in my past
experience with other util-linux tools it is often the case that
(likely for historical reasons/compatibility) the arguments that
doesn't come in a dash-form is attempted to be accepted in either
order based on guessing which one was specified. In my past experience
something that was guessable in the past might in later years become
sometimes impossible to correctly guess right, so sticking with
what synopsis describes is usually the safest as far as I'm concerned.
In the agetty case, the guessing is done here:
https://sources.debian.org/src/util-linux/2.36.1-2/term-utils/agetty.c/#L897
is_speed basically checks if the current argument only consists of
either 0-9 or ','.
It is not obvious to me how it could go wrong in the example originally
described in this bug report.
Please also note that for example sysvinit's inittab also uses getty
with arguments in both orders.
Simply it should work either way.
Please also note that the argument order is not the only thing changed.
It was also changed from specifying 3 speeds to only 1.
Maybe the real issue here is that line speed detection isn't working?
I'd appreciate if the bug reporter could dive a bit deeper into the
problem.
@MK any further feedback? Otherwise I would close this bug report.
Regards,
Michael
