I seem to have fixed the issue by running
sudo systemctl mask serial-getty@ttyGS0.service.
This obviously is not ideal as this disables the USB gadget ACM serial console.
There is some kind of race between USB ACM and the debug UART initialization. I am assuming, but have not checked, that the login prompt either shows up on one or the other, but not both at once.
I am using the BBAI64 Debian Trixie image from 2026-02-12.
Instead of auto enabling serial-getty@ttyGS0.service and waiting for the libcomposit stack to enable it.. .we just enable serial-getty@ttyGS0.service after the driver is loaded..
basicly after it’s enabled: repos-arm64/bb-usb-gadgets/suite/trixie/debian/bb-start-acm-ncm-rndis-old-gadget at main · beagleboard/repos-arm64 · GitHub
Regards,
1 Like
I just did it like this:
ln -s /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@ttyGS0.service
So this only starts getty (by systemd) when the ttyGS0 device appears.
Don’t see why you can’t do that with all UARTs, e.g. just decide which ones you want getty running on - and then just set up systemd to do all the work.
To my mind this is the point of the init process, in this case systemd. It is meant to make things easier - so just use it to set up devices …
And just check what is set up on my PB2 which is running the BeagleBoard.org Debian distribution.
The ttyGS0.service is linked to serial-getty@.service, whereas I use getty@.service. Hmm - not much difference between those two - and I should probably be using serial-getty@.service …
Anyway on my set up - the getty waits until the device exists, which takes some time via libcomposite.
Haha, now you’re being funny!
systemd – Let’s make things easier.
Faster maybe, but certainly not easier…