Hi,

 

similar to the issue reported in https://forum.armbian.com/topic/6566-le-potato-serial-getty-on-ttys0-starts-stops-restarts/ the /var/log/syslog file is being spammed with the following entries:

Jul 11 00:37:04 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart.
Jul 11 00:37:04 localhost systemd[1]: Stopped Serial Getty on ttyS0.
Jul 11 00:37:04 localhost systemd[1]: Started Serial Getty on ttyS0.
Jul 11 00:37:14 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart.
Jul 11 00:37:14 localhost systemd[1]: Stopped Serial Getty on ttyS0.
Jul 11 00:37:14 localhost systemd[1]: Started Serial Getty on ttyS0.
Jul 11 00:37:25 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart.
Jul 11 00:37:25 localhost systemd[1]: Stopped Serial Getty on ttyS0.
Jul 11 00:37:25 localhost systemd[1]: Started Serial Getty on ttyS0.

 

The only working serial interface is probably "/dev/ttyMV0" which is being brought up at boot together with "/dev/ttyS0":

[  OK  ] Found device /dev/ttyS0.
[  OK  ] Found device /dev/ttyMV0.

 

I could observe this behaviour on the following ARMBIAN, kernel and U-Boot versions:

ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.14.40-mvebu64, U-Boot 2017.03-armada-17.10.3-g06ad760-armbian (May 10 2018 - 16:45:48 +0200)

ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.17.5-mvebu64, U-Boot 2017.03-armada-17.10.3-g06ad760-armbian (May 10 2018 - 16:45:48 +0200)

 

Can this be fixed in armbian? Should I open a bug in git?

Edited July 11, 20188 yr by PelzigesOhr

4 hours ago, PelzigesOhr said:

Can this be fixed in armbian?

Adding a SERIALCON=ttyMV0 to this config https://github.com/armbian/build/blob/master/config/sources/mvebu64.conf should probably fix this problem. Test (build an image with those changes) and send a pull request.

12 hours ago, Igor said:

Adding a SERIALCON=ttyMV0 to this config https://github.com/armbian/build/blob/master/config/sources/mvebu64.conf should probably fix this problem. Test (build an image with those changes) and send a pull request.

 

I actually guessed the first part. I had already set up the build environment, updated the mvebu64.conf and tried a kernel that I built (to no avail). But now I guess the Kernel is not the relevant part, so I will have to build and flash the whole image, correct?

1 hour ago, PelzigesOhr said:

the whole image, correct?

 

Yes.

In case anyone will read this thread in the future: This has been fixed with pull request #1053.