Console is stuck before login prompt

After adding the mods to the kernel, this seems to have helped my situation. This driver seems to be trying to load before the usb is ready and causing some problems.

# /etc/udev/rules.d/90-rtl8821cu.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0bda", ATTR{idProduct}=="0811", RUN+="/sbin/modprobe rtw88_8821cu"

Replace idVendor/idProduct with the values from lsusb

2 Likes

Which is always funny, as it’s built-in!! :wink: oh the hacks we have to do!

Regards,

This problem came back darn it. Thought I had it fixed. Seems to only happen once in 20 boots. Seems serial-getty@ttyGS0.service is looking for /dev/ttyGS0 but it’s not there yet on boot. Is this your take on this?

So I’m trying this.

sudo systemctl edit serial-getty@ttyGS0.service

[Service]
ExecStart=
ExecStart=/usr/local/bin/wait-for-ttyGS0.sh
Restart=always

Helper script to wait for /dev/ttyGS0

#!/bin/sh
# Wait until ttyGS0 is ready
for i in $(seq 1 20); do
    echo "$(date): checking for /dev/ttyGS0" >> /var/log/ttyGS0.log
    if [ -c /dev/ttyGS0 ]; then
        # Try opening it non-blocking to see if it's ready
        if stty -F /dev/ttyGS0 >/dev/null 2>&1; then
            echo "$(date): ttyGS0 ready, starting agetty" >> /var/log/ttyGS0.log
            exec /sbin/agetty -o '-p -- \u' --keep-baud 115200,38400,9600 ttyGS0 vt100
        fi
    fi
    sleep 0.5
done
echo "$(date): ttyGS0 not ready, exiting" >> /var/log/ttyGS0.log
exit 1

Logging is not working for some reason

Exactly, it use to wait and not ā€˜block’ but in Debian 13 it’s now blocking… Make sure it’s disabled by default:

systemctl disable serial-getty@ttyGS0.service

This makes sure it doesn’t auto-start on bootup..

Then i have it only ā€˜starting’ in the the gadget script:

		# Create Serial function.
		mkdir $CONFIGFS/g_multi/functions/acm.usb0 || echo "${log} Couldn't create $CONFIGFS/g_multi/functions/acm.usb0"

		# Link the Serial instance to the configuration
		ln -s $CONFIGFS/g_multi/functions/acm.usb0 $CONFIGFS/g_multi/configs/c.1 || echo "${log} Couldn't symlink acm.usb0"

Then enabled after gadget is fully enabled:

		echo "$(ls /sys/class/udc)" > $CONFIGFS/g_multi/UDC || echo "${log} Couldn't write UDC"

		echo "${log} start serial-getty@ttyGS0.service"
		systemctl start serial-getty@ttyGS0.service || true

but lets also add a pure disable…

Regards,

1 Like

[Service]
ExecStart=
ExecStart=/usr/local/bin/wait-for-ttyGS0.sh
Restart=always
StandardOutput=journal
StandardError=journal

Adding: usb-gadget: allow diable of ttyGS0 Ā· beagleboard/customizations@ba1a002 Ā· GitHub

and: bb-usb-gadgets (1.20260427.0) Ā· beagleboard/repos-armhf@17061f0 Ā· GitHub

set, this in: /etc/default/bb-boot

USB_SERIAL_GADGET_DISABLED=yes

Regards,

I’ll check my set up tomorrow on arch linux, iirc this has come up correctly every time, and I think I’m doing exactly what is described hear.

I checked my set up - think critically my serial-getty service is different from yours - I just used the system standard, so looks like you have written your own service, to my mind its best to use the script that comes with systemd, and it you write your own give it a different name.

Anyway the cutical lines in my file are:

[Unit]
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service getty-pre.target

I got this from /usr/lib/systemd/system/serial-getty@.service

Suggest you check

man 8 systemd-getty-generator

Thanks for looking, mine looks the same.

[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=https://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service getty-pre.target
After=rc-local.service

The name shown above is

/usr/local/bin/wait-for-ttyGS0.sh

Interesting. Then I’m not sure what I’m doing differently - for me the UART comes up reliably - and I’m not doing anything special, just using the standard systemd way of doing things. Don’t know if the issue is that systemd is a complicated beast, and finding the right bit documented correctly has never been easy …