Hi, Am 28.04.2014 09:17, schrieb Thomas Blume:
On Sun, 27 Apr 2014, Alexander Graf wrote:
Am 27.04.2014 um 08:16 schrieb Andreas Färber
: Am 26.04.2014 18:52, schrieb Andreas Färber:
[ 10.900000] systemd[1]: Expecting device dev-ttySAC3.device... Expecting device dev-ttySAC3.device... [...] [ TIME ] Timed out waiting for device dev-ttySAC3.device. [DEPEND] Dependency failed for Serial Getty on ttySAC3.
I've now encountered this phenomenon on yet another board, the Vybrid based armStoneA5 with downstream 3.0.15 kernel.
Running `yast services` via ssh, selecting serial-getty@ttymxc1.service and invoking "Start/stop" followed by "OK" temporarily fixes serial login until reboot, whereas a simple `systemctl restart serial-getty@ttymxc1.service` times out as before.
No such problems on my IFC6410 (APQ8064 based) with ttyHSL0 and same Factory.
Thomas, do you have an idea what's happening here?
The above message suggests that the device ttySAC3 is not present. What serial device name has been specified on the kernel command line? Only this one will be set up automatically. Otherwise, you will need to configure serial-getty@.service manually, see:
http://0pointer.de/blog/projects/serial-console.html
section: Serial Terminals
for details.
If ttymxc1 works in the running system but not after reboot, maybe the name/number of the serial device has changed?
I'm attaching my original message for your convenience. The device is there at ssh login time, and yet systemctl-restart'ing the service at that time still times out, not finding it. So it seems that systemd is caching things or not getting file system change notifications? How do these dev-foo.device thingies get created, and can I inspect them through some command or in some log? What exactly does YaST do differently when I ask to start the service there? I've seen a similar timeout issue once I assigned a mount point /boot to a partition residing on an SD card (/dev/mmcblk0p1), dropping me into the dracut rescue shell after timeout. Not using an initrd, this was at a point where /dev/mmcblk0p2 was being used as root already. So there must be a mismatch between /dev devtmpfs and systemd's view of it. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg