A start job is running for dev-ttys0.device


A start job is running for…ces-eth0.device or A start job is running for dev-ttys0.device
What reason is this? Who knows? tks!!!


Configuration is wrong is there?
interfaces or inittab ?
Who can tell me? tks!!!


Sorry for reviving this old post, but I too have this issue.

By looking at the Net, there seem to be quite a few people who have this issue.

In my case, I compiled kernel socfpga-4.15 (same issue with socfpga-4.13), a Ubuntu Base 16.04.3 rootfs, Denx u-Boot 2018.01 plus SPL (not the older Altera/Intel SPL), and a DTB from the kernel distribution itself (based on socfpga_cyclone5_socdk.dts, with just a few changes to make it in line with the DE1-SoC board). For the DTB, the one produced with SOPC2DTS just doesn’t work anymore (hang during the SD/MMC probe), same with the latest DE10-Standard GHRD .dtb file (which would be pretty close to the DE1-SoC, except for an extra entry for the LCD, which the DE1-SoC does not have), they all hang at the same place… But that is not the issue we are talking here :slight_smile:

According to some forums, there seem to be an issue with mixing Xenial and the latest armhf kernels. Also, the issue seems NOT to be specific to the SoC, as this popped out for other ARM devices. I have not investigated more on this yet. There may be some Ubuntu-specific patch which work around this issue (applied either to the latest kernels or the rootfs), I have not investigated much yet. Some of the things I will do though:

  • Try with Artful (17.10) base (just to test, as I really would prefer an LTS).
  • Try with older kernels
  • With the result of the above tests, try to pinpoint when this issue occurred. This could help pinpoint a possible (theoretical) fix that could have been applied.
  • Look at the Ubuntu-specific releases/commits to see if a specific patch could be involved.

If I do find a solution, I will report it here. Although this mar really be a Ubuntu and/or kernel issue (not related to RocketBoards), this could possibly be helpful.


I have looked a little further (Google), and found this thread about a similar issue https://jira.automotivelinux.org/browse/SPEC-544
This end-up concluding that this is an issue with systemd at initialization, and has success in fixing the issue they were seeing by backporting systemd commit e266c068b5597e18b2299f9c9d3ee6cf04198c41 https://github.com/systemd/systemd/commit/e266c068b5597e18b2299f9c9d3ee6cf04198c41

In other word, maybe trying to update systemd, via qemu?

Ubuntu bug #1709649

Bug was fixed in Xenial (backported the patch to systemd 229 which is used in Xenial) as of Feb 5, 2018 (a few days ago!), along with a few security update, as package systemd (229-4ubuntu21.1) xenial-security

I will try this tonight when I come back on my setup :slight_smile:



Ok, I tried with the systemd update I mentioned above, and this does not resolve the issue :frowning: The Ubuntu fix mentionned is a similar, but unrelated problem.

I think though that the edit1 above may still hold.



Finally, I have success :slight_smile:

I followed suggestions from here https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-2017-2-Ubuntu-RFS-on-Zynq-timed-out-waiting-for-device/m-p/810633

Basically, I think the main issue was that the Ubuntu Base is missing a ‘ttyS0’ link for the getty service. What I needed to do was to create a symlink, on the rootfs, as follow:

ln -s /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@ttyS0.service



Sorry again, I have yet found more info!

Actually, the above seem to be required as long as the ‘udev’ package is not installed. As soon as ‘udev’ package get installed, the above not only is no longer required, but it does render working on the serial console impossible, because you will get 2 instances of tty actually getting started on the serial console.

In other word, if you have applied the above ‘fix’, withouth ‘udev’ package installed, everything is fine. When you boot, the ttyS0 boot argument will make the system check the link you created above, and a tty is attributed to the serial console.

But, when you install ‘udev’ (or rather, as soon as it get installed, for example as a dependency to some other package), then chaos occur on subsequent boot. The above mechanism still apply, but now ‘udev’ will also, on it’s own, start a tty on the console.

The end result, at first, is that you see 2 banners right after boot. Ex:

Ubuntu 16.04.3 LTS de1-soc ttyS0

Ubuntu 16.04.3 LTS de1-soc ttyS0

localhost login: localhost login:

Then, you get 2 tty instances fighting for the input and output, ending with an unusable user interface (try to login, getting invalid password because some character end up in one instance, some character in the other instance). Really nasty (and weird feeling you get when this occurs)!

So, the best option is to install udev right away, when you build your rootfs (with qemu for example). Another option, if this is not possible (for example if you rely on a boot script to install the packages) it to do the link to the tty service when you create the rootfs, and in your boot script, install udev and delete the symlink before the next reboot.

No wonder why some people saw the issue, other did not, and why it seemed so strange to pinpoint. I guess that when you know the internals of udev, you are well aware of this. However, as usual, the challenge is to get those few persons cross those other persons who are reporting issues in the forums :smirk: