I use the systemd initialization manager to booting the system, but it cann't enter the Getty for waiting for ttymxc0 timeout (using the serial):
[ OK ] Started Authorization Manager.
[ OK ] Started Getty on tty1.
[ OK ] Started Modem Manager.
[ OK ] Created slice system-sshd.slice.
[ OK ] Started OpenSSH Per-Connection Daemon (192.168.1.106:38772).
[ TIME ] Timed out waiting for device dev-ttymxc0.device.
[DEPEND] Dependency failed for Serial Getty on ttymxc0.
[ OK ] Reached target Login Prompts.
[ OK ] Reached target Multi-User System.
Starting Update UTMP about System Runlevel Changes...
[ OK ] Started Update UTMP about System Runlevel Changes.
But I can get into the console through ssh, also, I can get into the getty when using the init.d instead of systemd so the ttymxc0 is fine, but it just wouldn't be detected by the systemd, maybe the udev is the fault?
And the system is build using the yocto. The udevd is running.
# udevadm info /dev/ttymxc0
P: /devices/platform/soc/2000000.aips-bus/2000000.spba-bus/2020000.serial/tty/ttymxc0
N: ttymxc0
E: DEVNAME=/dev/ttymxc0
E: DEVPATH=/devices/platform/soc/2000000.aips-bus/2000000.spba-bus/2020000.serial/tty/ttymxc0
E: ID_MM_CANDIDATE=1
E: MAJOR=207
E: MINOR=16
E: SUBSYSTEM=tty
E: TAGS=:systemd:
E: USEC_INITIALIZED=11599104
I can see the udev service is started:
[ OK ] Started udev Kernel Device Manager.
Starting Update UTMP about System Boot/Shutdown...
Starting Network Time Synchronization...
[ OK ] Started Update UTMP about System Boot/Shutdown.
Also I tried to trigger a event in ssh durning the systemd is waiting for the ttymxc0, but no luck:
udevadm trigger -v --type subsystems --action add -s tty --sysname-match=ttymxc0
Hi, I'm having exactly the same issue. Did you manage to fix it?
I've asked mr google and found people saying that you have to have FHANDLE=y and IKCONFIG=y configured in the kernel but I've tried this and ti doesn't solve my problem.
Thanks.
Hello. I am having the same issue. Have you managed to find a solution? I also have FHANDLE, and IKCONFIG on in the kernel, but this keeps happening in some conditions.
I had solved this problem with another board by enabling CONFIG_FHANDLE. What kernel are you using? Also do you have CONFIG_VT enabled?
A million thanks for answering.
Yes, I have both CONFIG_FHANDLE and CONFIG_VT enabled. I have just figured out how to solve this problem in my setup.
Just in case this helps anyone else, in my case it was just a conflict between systemd and udevd.
I had some rules in udev that performed systemctl start, stop and restart of several systemd services. By adding the --no-block option I managed to avoid this problem.
Hi,
Could you please how to set CONFIG_FHANDLE and CONFIG_VT enabled?
Thanks
Yiling Xu
Hi XiongJun
what bsp used in the case, please try nxp releases described on
i.MX 6 / i.MX 7 Series Software and Development Tool|NXP
try Demo Image
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------