Server — Serial Console

Posted on 6 2026

Every time you SSH into a headless server, you are relying on a chain of things that have to be working: the network, the SSH daemon, the operating system, the SD card, the configuration you wrote last time. When something in that chain breaks, SSH breaks with it. The Pi sits there, completely inaccessible, and you are left staring at a connection timeout with no idea what went wrong.

The serial console breaks that dependency. It connects directly to the Pi’s hardware UART before the operating system is fully up, before the network is configured, before SSH has started. If the Pi is powered on and the bootloader is running, you can talk to it. If the kernel is panicking on startup, you will see exactly why. If you made a mistake in a config file that prevents the network from coming up, you can fix it without pulling the SD card.

It is not something you use every day. It is something you set up once and are very glad you have when you need it.

What you need

A USB to TTL serial adapter. This is a small dongle, typically USB-A on one end and a set of jumper wires on the other. The important thing is that it must operate at 3.3V. The Raspberry Pi’s GPIO pins are not 5V tolerant, and a 5V adapter will damage them. Do not skip this detail.

Common options that work reliably at 115200 baud: the Adafruit 954 USB-to-TTL Serial Cable, the DSD TECH SH-U09C5, or any CP2102 or CH340-based adapter rated at 3.3V. Avoid the very cheap generic ones with no chip branding; they tend to be unreliable at the baud rates the Pi uses.

Three jumper wires. Ground, TX, and RX. You do not need to connect power through the adapter; the Pi should be powered through its own supply as normal.

A terminal emulator on your laptop. On Linux or macOS, screen or minicom work fine. On Windows, PuTTY configured for serial is the straightforward choice.

The wiring

The Pi’s UART is on GPIO pins 14 and 15, which are physical pins 8 and 10 on the 40-pin header. Pin 6 is a ground. The pinout at pinout.xyz is the reliable reference if you want to double-check.

Connect the adapter to the Pi as follows:

AdapterPi GPIOPhysical pin
GNDGNDPin 6
TX (adapter)RX (GPIO 15)Pin 10
RX (adapter)TX (GPIO 14)Pin 8

TX and RX are crossed. The adapter’s transmit pin connects to the Pi’s receive pin, and the adapter’s receive pin connects to the Pi’s transmit pin. This is correct. A common wiring mistake is connecting TX to TX and RX to RX, which produces no output. If you get a blank terminal when you expect boot messages, check the crossover first.

Do not connect the adapter’s power pin to anything on the Pi. Power the Pi through its USB-C port as normal.

Enabling the serial console on the Pi

By default, the Pi’s UART may be assigned to Bluetooth rather than the GPIO header, depending on the model and OS version. You need to tell it explicitly to use the hardware UART for the serial console.

If you have access to the Pi right now over SSH, or you can pull the SD card and mount the boot partition on another machine, edit two files.

In /boot/firmware/config.txt, add under [all]:

enable_uart=1
dtoverlay=disable-bt

enable_uart=1 activates the hardware UART. dtoverlay=disable-bt frees it from Bluetooth, which otherwise claims the primary UART on Pi 3 and later models.

In /boot/firmware/cmdline.txt, make sure the console directive includes the serial device. The line should include:

console=serial0,115200

The full line will look something like this (all on one line, no line breaks):

console=serial0,115200 console=tty1 root=PARTUUID=... rootfstype=ext4 fsck.repair=yes rootwait

If console=serial0,115200 is already there, leave it alone. If it is missing, add it at the start of the line. cmdline.txt is a single line file; do not introduce any line breaks.

Reboot the Pi after making these changes.

Connecting from your laptop

Plug the USB adapter into your laptop. On Linux, it will appear as something like /dev/ttyUSB0 or /dev/ttyACM0. On macOS, it will be /dev/tty.usbserial-XXXX or similar. On Windows, check Device Manager for the COM port number.

To find the right device on Linux:

ls /dev/tty{USB,ACM}*

Connect with screen:

screen /dev/ttyUSB0 115200

Or with minicom:

minicom -b 115200 -D /dev/ttyUSB0

The baud rate is 115200. That is the standard for the Pi’s serial console and needs to match on both ends.

If the Pi is already running when you connect, press Enter and you should get a login prompt. If the Pi is off, power it on and you will see the boot sequence output in the terminal, including kernel messages, service startup, and any errors that occur during boot.

What you can do with it

The serial console gives you a full login shell. Anything you can do over SSH, you can do here. The difference is that it works when SSH does not.

The scenarios where it earns its place:

Misconfigured network. You edited /etc/dhcpcd.conf or set a static IP and got the subnet mask wrong. The Pi boots fine but is unreachable over the network. Log in over serial, fix the config, restart the networking service.

Failed SSH config. You made a change to /etc/ssh/sshd_config that broke the daemon. Log in over serial, revert the change, restart SSH.

Kernel panic or boot failure. The serial terminal shows the full boot output, including the point at which something went wrong. Without this, you are pulling the SD card and trying to read logs on another machine.

First boot of a new image. Before SSH is configured or the Pi has a known IP address, the serial console gives you a direct login to set things up.

A note on non-root access

On Linux, the serial device is owned by the dialout group by default. If you get a permission denied error when trying to open it, add your user to that group:

sudo usermod -aG dialout $USER

Log out and back in for it to take effect.

Leaving it set up

The adapter can stay connected permanently. It draws no meaningful power, and having it in place means you never have to go hunting for it when something goes wrong at an inconvenient moment. The cost is one USB port on your laptop and three GPIO pins on the Pi. The return is reliable out-of-band access to a machine that is otherwise headless and sitting somewhere awkward.

Set it up once, verify it works, and leave it alone. It will be there when you need it.