On Fri, Jan 06, 2023 at 07:15:14PM -0500, Gabriel L. Somlo wrote: > Hi, > > I'm failing to get a login prompt on the serial console of my system, > because a few steps earlier serial-getty@.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. Turns out it was just really slow loading bash :) After a while, I did manage to log in and obtain a root shell over ssh. From there I did: udevadm trigger --type=devices --action=add udevadm trigger --type=subsystems --action=add which had no visible effect. After that, I did: systemctl restart serial-getty@ttyLXU0.service which resulted in a login prompt showing up on the serial console! I *can* run any tests y'all might suggest to further debug the state of the system. But at this point I really do believe there is (or should be :) a way to extend the timeout during initial boot to force the system to wait for /dev/ttyLXU0 to become available (via udev?). Thanks much, --Gabriel