14375 2021-05-03 14:59:49 +0000 serial-getty@.service fails on gadget serial port ttyGS0 2026-06-03 12:53:09 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 3.3 Other arm RESOLVED FIXED Low normal 6.1 1 marc.ferland marc.ferland Ahmed.Hossam ccasciato jason.wessel jon.mason meta.mr.watcher meta.watcher Qi.Chen randy.macleod richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 90229 0 marc.ferland 2021-05-03 14:59:49 +0000 I have a system here that exposes a virtual serial device on a micro-USB port. This device appears as /dev/ttyGS0 on the embedded system. Enabling getty on this virtual serial port using the SERIAL_CONSOLES variable in my mahcine.conf ultimately fails with: * serial-getty@ttyGS0.service - Serial Getty on ttyGS0 Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled; vendor> Active: inactive (dead) Condition: start condition failed at Mon 2021-05-03 14:24:45 UTC; 51s ago `- ConditionPathExists=/dev/ttyGS0 was not met I understand this happens because of a previous commit ( adc496081689e1d8b8bf3bbf21efec675450edb2) which changed the BindsTo to a combination of PartOf and ConditionPathExists. Replacing the PartOf/ConditionPathExists to BindsTo on my setup fixes the issue but I understand this might break other configurations like qemuarm64. I honestly don't know how to elegantly solve this issue. Maybe adding a 'dev_wait' parameter to the SERIAL_CONSOLES console definition would help in generating a compatible service file? For example: SERIAL_CONSOLES = "115200;ttyGS0;dev_wait 115200;ttymxc1" This could help toggle between the two implementation. 90281 1 randy.macleod 2021-05-06 14:51:24 +0000 This isn't so much a bug as a request for help in developing your system. Can you ask your question on the yocto email list? If no one answers ping this defect. Patches would also be welcome if the issue is resolved. 90292 2 marc.ferland 2021-05-06 15:17:21 +0000 Thanks for the feedback. Well, the service file generated by the systemd-serialgetty.bb recipe does not work as expected. Some service files will fail based on the type of serial device that's being used. I think this could be considered as a bug. I will try to gather comments/ideas by asking on the mailing list. 91855 3 randy.macleod 2021-10-28 17:31:21 +0000 Marc, Any update on this issue? 91860 4 marc.ferland 2021-10-29 13:42:41 +0000 Hi Randy, no updates. I tried asking on IRC but was unsuccessful. I have a couple of ideas on how to solve it though: - Add a third parameter to the SERIAL_CONSOLES arguments. For example: "115200;ttyGS0;dev_wait" to indicate that the serial-console service _must_ wait for this device (i.e.: use BindsTo). Without this parameter, we default to the current, fast fail, poky implementation (PartOf + ConditionPathExists); - Use the name of the tty (ttyGS0, ttyUL0, ttyFB0, ttyS0, ttyAMA0, etc.) to determine if we should use a BindsTo or a PartOf/ConditionPathExists (seems brittle); - Use BindsTo and a _shorter_ timeout value, something like 5-10 seconds instead of the default 90 seconds; Does that make sense? I'll also try with the mailing list. 91864 5 richard.purdie 2021-10-29 16:48:47 +0000 Add Jason Wessel and Qi Chen who wrote those changes in case they have insight and can help 91867 6 Qi.Chen 2021-11-01 01:56:20 +0000 @Marc IMHO, a third parameter seems reasonable. When 'dev_wait' is available, put a drop-in configuration (e.g. dev-wait.conf) in /etc/systemd/system/serial-getty@ttyXXX.service.d/ directory which specifies BindsTo. Could you please try if this works? I don't have environment and am not sure if this will work. As a quick tryout, you can create /etc/systemd/system/serial-getty@ttyGS0.service.d/dev-wait.conf with the following contents and then reboot the target. [Unit] BindsTo=dev-%i.device Regards, Qi 91886 7 marc.ferland 2021-11-03 18:50:34 +0000 @Chen Thank you for your comments. I'll try to cook something up in the next few weeks and test it on a board I have here. 92987 8 randy.macleod 2022-04-11 21:45:51 +0000 Marc, any news? I'll move this to 3.6( soon to be 4.1) for now. 93006 9 marc.ferland 2022-04-12 15:00:55 +0000 Hi Randy, unfortunately I've been very busy lately and I haven't been able to put much effort on this task. I'm not giving up though! 93010 10 randy.macleod 2022-04-12 15:37:23 +0000 Thanks for the update Marc. We look forward to you making time for this work at some point. 97162 11 randy.macleod 2023-10-30 15:37:33 +0000 Build move to 5.0 -- ../Randy 98825 12 randy.macleod 2024-04-25 01:13:53 +0000 Bulk move of 5.0 medium importance issues to 5.99. Move to 5.1 if you want to actively work on an issue. 101812 13 randy.macleod 2025-05-01 14:07:07 +0000 Bulk move of all unassigned 5.2 medium importance bugs to 5.3. 104744 14 randy.macleod 2026-03-19 15:24:58 +0000 Ross Burton did quite some work on tty management so with newer versions of systemd and that work, this may just work now. Marc, can you retest using master or the 6.0 release when it's available in a month and let us know ? 104888 15 marc.ferland 2026-04-01 01:41:04 +0000 (In reply to Randy MacLeod from comment #14) > Ross Burton did quite some work on tty management so with newer versions of > systemd and that work, this may just work now. > > Marc, can you retest using master or the 6.0 release when it's available in > a month and let us know ? Interesting, I'll have a look thanks! 104936 16 randy.macleod 2026-04-02 15:05:52 +0000 Thanks Marc, I've put the bug in your name and accepted. 105702 17 marc.ferland 2026-06-03 12:53:09 +0000 Did some tests with QEMU and everything looks good. I wasn't able to reproduce the issue. I configured multiple gettys with SERIAL_CONSOLES and each one came up as expected. Tested with wrynose (6.0).