pi os

Resolving 'Temporary failure in name resolution' on Pi OS 12 Bookworm

Raspberry Pi OS version 12 (based on Debian 12 Bookworm) uses NetworkManager instead of dhcpcd for managing network connections, DNS resolution settings, DHCP, etc.

I've already mentioned using nmcli and nmtui for managing WiFi settings, but I ran into a strange issue after installing Docker on a fresh Raspberry Pi OS installation today. Suddenly DNS stopped working.

Trying to ping anything on the Internet gave me:

$ ping www.google.com
ping: www.google.com: Temporary failure in name resolution

As always, It was DNS. It was like DNS just gave up the ghost! Trying to change settings via nmtui seemed to not work (I tried DHCP for IPv4 with manual DNS, and that wasn't working).

Luckily, I found this post and followup comments mentioning the proper nmcli incantation to override DNS settings for an interface, so here it is (assuming built-in Ethernet):

nmcli for WiFi on Raspberry Pi OS 12 'Bookworm'

If you haven't already, check out my full video on the Raspberry Pi 5, which inspired this post.

Raspberry Pi 5 at an angle

Raspberry Pi OS 12 'Bookworm' is coming alongside the release of the Raspberry Pi 5, and with it comes a fairly drastic change from using wpa_supplicant for WiFi interface management to everything network-related running through nmcli, or NetworkManager.

nmcli is widely adopted in Linux these days, and it makes managing WiFi, LAN, and other network connections much simpler.

Install Raspberry Pi OS's desktop environment over a Lite install

Almost every time I set up a Raspberry Pi these days, I use the 'Lite' version of Raspberry Pi OS. That version doesn't come with a GUI, it just boots to the console. It's much smaller in size and contains most things you'd need for a 'headless' Pi setup.

And if you know your way around the command line, it's not daunting to plug in a monitor, keyboard, and mouse, and explore via the shell if you need to.

But every so often, I've had a Lite install that I wanted to switch to GUI, but I'm too lazy to pull the Pi out of wherever it's installed, pull the microSD card, and re-flash it with the full OS, and then re-run my automation on it to set up whatever I had running before.

And that's why it's nice to be able to just install the GUI on top of an existing Lite install!

To do that (assuming you're running the latest Pi OS version, Bullseye as of this writing), just install Xorg and the Raspberry Pi 'PIXEL' environment:

Three more graphics cards on the Raspberry Pi CM4

Last year I tested two older graphics cards—a Radeon 5450 and a GeForce GT710—on a Raspberry Pi Compute Module 4.

Jeff Geerling holds NVidia and ASRock Rack GPU and Raspberry Pi Compute Module 4 with quizzical look

This year, I've been testing three more graphics cards—a GeForce GTX 750 Ti, a Radeon RX 550, and the diminutive ASRock Rack M2_VGA.

The Compute Module 4, if you didn't know already, exposes the BCM2711's single PCI express lane, and the official IO Board has a nice, standard, 1x PCIe slot into which you can plug any PCI express device.

The Raspberry Pi can boot off NVMe SSDs now

When the Compute Module 4 was released (see my CM4 review here), I asked the Pi Foundation engineers when we might be able to boot off NVMe storage, since it was trivially easy to use with the exposed PCIe x1 lane on the CM4 IO Board.

The initial response in October 2020 was "we'll see". Luckily, after more people started asking about it, beta support was added for direct NVMe boot just a couple weeks ago.

MirkoPC with SN750 WD_BLACK NVMe SSD and Raspberry Pi Compute Module 4

Setting 9000 MTU (Jumbo Frames) on Raspberry Pi OS

Raspberry Pi OS isn't really built to be a server OS; the main goals are stability and support for educational content. But that doesn't mean people like me don't use and abuse it to do just about anything.

In my case, I've been doing a lot of network testing lately—first with an Intel I340-T4 PCIe interface for 4.15 Gbps of networking, and more recently (yesterday, in fact!) with a Rosewill 2.5 GbE PCIe NIC.

And since the Pi's BCM2711 SoC is somewhat limited, it can't seem to pump through many Gbps of bandwidth without hitting IRQ limits, and queueing up packets.

In the case of the 2.5G NIC, I was seeing it max out around 1.92 Gpbs, and I just wouldn't accept that (at least not for a raw benchmark). Running atop, I noticed that during testing, the IRQ interrupts would max out at 99% on one CPU core—and it seems like it may be impossible to distribute interrupts across all four cores on the BCM2711.