[systemd-devel] Please help: timeout waiting for /dev/tty* console device

[Gabriel L. Somlo]

Hi,

I'm failing to get a login prompt on the serial console of my system,
because a few steps earlier serial-getty at .service fails due to a
dependency on the actual tty device, which times out:

[ TIME ] Timed out waiting for device …ttyLXU0.device - /dev/ttyLXU0.
[DEPEND] Dependency failed for seri…ice - Serial Getty on ttyLXU0.

This eventually results in "Failed to start systemd-logind.service",
and no login prompt on the serial console.

I'm trying get a riscv64 port of fedora (systemd version 251) running
on a system that can be considered "exotic" and rather on the slow
side -- it's an FPGA soft-cpu system using the RocketChip running at
50MHz.

I got it working successfully on an older version of the fedora-riscv
port, f33, using systemd 246.

I can also get it working with the current systemd on a 4-core Rocket
chip deployed on a large enough FPGA.

It (udev?) times out on the single-core version of the design, and I'm
wondering if there are any available options to get systemd and/or
udev to be more "patient".

I tried booting with `udev.children_max=1` and `udev.event_timeout=800`
on the kernel command line.

I also tried modifying systemd-udev-settle.service like so:
	TimeoutSec=720
	ExecStart=udevadm settle --timeout=680

None of the above seem to help on the single-core 50MHz rocket-chip
system (and are not needed on the 4-core version).

Any other tricks I can use to force it to wait (or to otherwise
encourage it to find, sooner) /dev/ttyLXU0?

I can't log into this machine to run any tests. It does manage connect
to the network, start NetworkManager.service and sshd.service, but any
attempt to ssh in over the network fails (after successful auth) with
"conection closed by <ip address> port 22". Not sure if due to the
user login service having failed, or some other unrelated timeout.

I can (also) ssh into the 4-core version of the system, and can run
tests and report results from that one if it would help troubleshoot
the issue (the systems are otherwise 100% identical in terms of
"hardware" -- same HDL sources -- and only differ by the core count of
the CPU module).

Any help and/or ideas much appreciated, thanks in advance!

Best,
--Gabriel