Discussion:
[systemd-devel] Serial console issue.
Yann Le Mouel
2017-11-07 15:48:40 UTC
Permalink
Hello,



I've been following your guidelines (serial-console.html) about serial
console. I'm testing this function via AMT on Intel NUC'S on Centos 7.4. I'm
using AMTTERM package for the test.



I managed to get the serial working until certain point, as below, I can see
the boot which is really fast until set hostname, and then so slow, lines by
lines,



[ 1.781570] hid-generic 0003:03F0:0024.0002: input,hidraw1: USB HID v1.10
Keyboard [CHICONY HP Basic USB Keyboard] on usb-0000:00:14.0-4/input
0

[ 31.333620] systemd[1]: Set hostname to <XXXXXx>.





Then for the first time I see this message truncated "Welcome to emergive
root passo", but I don't see this message in journalctl (log are persistent)



[[[[[[[[[[Welcome to emergGive root passwo[ 4952.329920] EXT4-fs
(sda5): mounted filesystem with ordered data mode. Opts: (null)





From journactl, few logs about not being able to start ttyS1



I enabled ttyS1 as below:

systemctl enable serial-***@ttyS1.service
<mailto:serial-***@ttyS1.service>

systemctl start serial-***@ttyS1.service
<mailto:serial-***@ttyS1.service>





Nov 06 09:37:02 systemd[1]: serial-***@ttyS1.service
<mailto:serial-***@ttyS1.service> holdoff time over, scheduling restart.

Nov 06 09:37:02 systemd[1]: Started Serial Getty on ttyS1.

Nov 06 09:37:02 systemd[1]: Starting Serial Getty on ttyS1...

Nov 06 09:37:02 systemd[1]: ***@ttyS1.service <mailto:***@ttyS1.service>
has no holdoff time, scheduling restart.

Nov 06 09:37:02 systemd[1]: Started Getty on ttyS1.

Nov 06 09:37:02 systemd[1]: Starting Getty on ttyS1...

Nov 06 09:37:02 systemd[1]: serial-***@ttyS1.service
<mailto:serial-***@ttyS1.service> holdoff time over, scheduling restart.

Nov 06 09:37:02 systemd[1]: start request repeated too quickly for
serial-***@ttyS1.service <mailto:serial-***@ttyS1.service>

Nov 06 09:37:02 systemd[1]: Failed to start Serial Getty on ttyS1.

Nov 06 09:37:02 systemd[1]: Unit serial-***@ttyS1.service
<mailto:serial-***@ttyS1.service> entered failed state.

Nov 06 09:37:02 systemd[1]: serial-***@ttyS1.service
<mailto:serial-***@ttyS1.service> failed.



Are you able to help, I may have been missing something? I've been doing the
same test on SLC6, I could to a full reboot via serial console and see all
the ouput, but not getting login prompt as the end.



Hopefully you could help getting this fix, as we are going to use a lot of
Front End devices running on CC 7.4 with serial console compatibility.



Many thanks for your help.

Yann
Mantas Mikulėnas
2017-11-08 11:05:17 UTC
Permalink
*Nov 06 09:37:02 systemd[1]: Started Serial Getty on ttyS1.*
*Nov 06 09:37:02 systemd[1]: Starting Serial Getty on ttyS1...*
no holdoff time, scheduling restart.*
*Nov 06 09:37:02 systemd[1]: Started Getty on ttyS1.*
*Nov 06 09:37:02 systemd[1]: Starting Getty on ttyS1...*
*Nov 06 09:37:02 systemd[1]: start request repeated too quickly for
*Nov 06 09:37:02 systemd[1]: Failed to start Serial Getty on ttyS1.*
You have two services (getty@ and serial-getty@) fighting over the tty
device. Start by disabling the former.

(Actually, since you're getting dmesg output to the serial console, you
might even have a *third* service, console-getty, doing the same...)
--
Mantas Mikulėnas <***@gmail.com>
Lennart Poettering
2017-11-08 12:56:20 UTC
Permalink
Post by Yann Le Mouel
Hello,
I've been following your guidelines (serial-console.html) about serial
console. I'm testing this function via AMT on Intel NUC'S on Centos 7.4. I'm
using AMTTERM package for the test.
I managed to get the serial working until certain point, as below, I can see
the boot which is really fast until set hostname, and then so slow, lines by
lines,
Normally, it should suffice to set the kernel console to ttyS0 (or
whichever device you use) via the kernel cmdline. The rest should then
happen fully automatically, as systemd contains an automatic genreator
which uses this to also invoke a serial getty on the same serial port
you used for the console.

Note that if multiple processes fight for console ownership you will
experience all kinds of problems. The log you pasted shows that you
have ***@.service and serial-***@.service fighting for access to
ttyS1. That's already indication of a problem, and most likely
happened because you enabled these units manually? First of all, that
should not be necessary, as things should work automatically anyway,
as mentioned above. Moreover, enable "***@.service" (as opposed to
serial-***@.service) is incorrect anyway, as that unit is for VTs
only, not for serial ttys.

Hence, I am not entirely sure what changes you made. My recommendation
would be to undo them all, and just set console= on the kernel
cmdline, and all should be good.

Lennart
--
Lennart Poettering, Red Hat
Yann Le Mouel
2017-11-13 13:04:29 UTC
Permalink
Hello,

I rebuilt my machine just to make sure it's all clean, now the machine boot
ok with console=ttyS1 on the kernel. But now I've got no output nor login
prompt.

Dmesg | grep tyy
[ 0.000000] console [tty0] enabled
[ 0.464947] 00:01: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 0.485527] 0000:00:16.3: ttyS1 at I/O 0x30e0 (irq = 17) is a 16550A

Grub:
RUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="serial console"
GRUB_SERIAL_COMMAND="serial --speed=115200"
GRUB_CMDLINE_LINUX="biosdevname=0 net.ifnames=0 rhgb
rd.shell=0,console=ttyS1"
GRUB_DISABLE_RECOVERY="true"
GRUB_GFXMODE=text

Output from amtterm for connecting to the machine

~ # amtterm hostname
amtterm: NONE -> CONNECT (connection to host)
16994 open
amtterm: CONNECT -> INIT (redirection initialization)
amtterm: INIT -> AUTH (session authentication)
amtterm: AUTH -> INIT_SOL (serial-over-lan initialization)
amtterm: INIT_SOL -> RUN_SOL (serial-over-lan active)
serial-over-lan redirection ok
connected now, use ^] to escape
The system is powered off.
The system is powered on.
Warning, SOL device is running in loopback mode. Text input may not be
accepted
SOL device is no longer running in loopback mode

Thanks.


-----Original Message-----
From: Lennart Poettering [mailto:***@poettering.net]
Sent: 08 November 2017 13:56
To: Yann Le Mouel <***@lemouel.ch>
Cc: systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] Serial console issue.
Post by Yann Le Mouel
Hello,
I've been following your guidelines (serial-console.html) about serial
console. I'm testing this function via AMT on Intel NUC'S on Centos
7.4. I'm using AMTTERM package for the test.
I managed to get the serial working until certain point, as below, I
can see the boot which is really fast until set hostname, and then so
slow, lines by lines,
Normally, it should suffice to set the kernel console to ttyS0 (or whichever
device you use) via the kernel cmdline. The rest should then happen fully
automatically, as systemd contains an automatic genreator which uses this to
also invoke a serial getty on the same serial port you used for the console.

Note that if multiple processes fight for console ownership you will
experience all kinds of problems. The log you pasted shows that you have
***@.service and serial-***@.service fighting for access to ttyS1.
That's already indication of a problem, and most likely happened because you
enabled these units manually? First of all, that should not be necessary, as
things should work automatically anyway, as mentioned above. Moreover,
enable "***@.service" (as opposed to
serial-***@.service) is incorrect anyway, as that unit is for VTs only,
not for serial ttys.

Hence, I am not entirely sure what changes you made. My recommendation would
be to undo them all, and just set console= on the kernel cmdline, and all
should be good.

Lennart

--
Lennart Poettering, Red Hat
Yann Le Mouel
2017-11-13 16:04:39 UTC
Permalink
This post might be inappropriate. Click to display it.
Loading...