Unscrewing lightbulbs

Giving lightbulbs a MAC address was a mistake that I’m living with.

I’m literally unscrewing lightbulbs to renew their DHCP lease

@dbushell.com - Bluesky

Instead of enjoying the bank holiday Monday I updated my homelab software. I was ‘inspired’ by the Copy Fail Linux bug to run full distro upgrades. This is my self-hosted update for Spring 2026 (rough documentation to give future me a chance).

Monday’s fun risked a week of pain. I do have backups but restoring them on a broken LAN is tricky. I have an ISP provided wifi router to dust off in an emergency. Along with an absurdly long 15 metre HDMI cable I do not care to unravel. My winter update added a hardware fallback but that too requires careful rejigging.

Debian Trixie

I have Proxmox hosts, virtual machines, and Raspberry DietPis. They were all on Debian 12 (Bookworm) with a kernel potentially susceptible to the bug.

Minimal Debian installs are perfect because I run everything in Docker anyway. Data volumes are easy to backup or network mount. I can change host at will for any service. Debian is just sensible, well documented no-fuss Linux.

Virtual machine upgrades

I updated most of my VMs first because they’re easy to restore if anything fails. I followed Lubos Rendek’s guide. Start with a full package update and then change the package sources before running another step-by-step upgrade.

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
find /etc/apt/sources.list.d -name "*.list" -exec sed -i 's/bookworm/trixie/g' {} \;

The only non-Debian sources I have are Docker and Tailscale. Yes that means I run Docker inside Proxmox VMs — and you can’t stop me! That’s not even my worse crime…

After the Trixie upgrade I found VMs were failing to obtain a LAN IP address. The virtual network device had been renamed from enp6s18 to ens18. I edited interfaces and just changed the reference.

# /etc/network/interfaces
allow-hotplug ens18
iface ens18 inet dhcp

There is surely a better/more predictable fix but this was the quickest. The same name was used across all VMs so I guess 18 is the magic number.

Everything has been stable so far. If issues arise I’ll just nuke and pave from a Debian 13 ISO. Docker config and volumes are backed up independently of the VM images.

DietPi upgrades

DietPi has a long Trixie upgrade post I didn’t read. I just curled to bash:

sudo bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-trixie-upgrade')"

I gave the script a cursory glance before hitting enter. I have a Pi 4 running failover DNS and a Pi 5 running my public Forgejo instance. DietPi is ideal because of the tiny footprint; I run Docker here too. Raspberry Pi still hasn’t merged upstream Copy Fail fixes. I’m already in trouble if this bug can be exploited but I did the temporary fix out of caution.

Proxmox 8 to 9

I wasn’t going to bother with Proxmox 9 but after a GUI update I was informed version 8 “end of life” was August 2026. That is soon! I followed the official upgrade guide on my Mini-ITX server. Proxmox has a tool to check compatibility.

pve8to9 --full

I saw no red lights so I stopped all VMs, updated package sources to Trixie, and ran the upgrade. It is critical to run pve8to9 again before rebooting. I ran into the systemd-boot issue. Apparently if this is not removed the system fails to boot. If my particular box fails to boot I’m in big trouble because I broke video output and have yet to fix it.

The worst crime

I have another Proxmox machine running virtualised OPNsense for my home router. I can’t stop the OPNsense VM and upgrade the host to Proxmox 9 because the host would have no network access. I had two options:

1. Use my failover VM
2. YOLO it live

I specifically set up option 1 for such a purpose. I went with option 2.

I figured any software running in memory is still alive until I reboot, right? I didn’t question whether Proxmox would kill any processes itself (it didn’t). The update was suspiciously fast. I ran pve8to9 again and saw a lot of yellow warnings. Yikes. Eventually I noticed I’d failed to update some sources to Trixie and I’d installed a franken-distro.

After fixing mistakes all I could do was reboot and pray for an agonising two minutes.

Request timeout for icmp_seq 107
ping: sendto: Host is down
Request timeout for icmp_seq 108
ping: sendto: Host is down
Request timeout for icmp_seq 109
ping: sendto: Host is down
64 bytes from 192.168.1.1: icmp_seq=110 ttl=64 time=6.039 ms
64 bytes from 192.168.1.1: icmp_seq=111 ttl=64 time=4.834 ms

OPNsense upgrade

OPNsense is the only non-Debian operating system in my homelab. I manage it entirely via the web GUI. The 26.1 update had quite a few significant changes. My DHCP setup was considered “legacy” and my firewall rules required a manual migration.

Despite dumbening my smart home my lightbulbs still demand a WiFi connection. I program them myself to avoid Home Assistant and proprietary apps. Turns out I hard-coded IP addresses (discovery protocols are a joke.) Despite having dynamic IPs they remained stable until the OPNsense 26.1 DHCP update.

I had no easy way to identify each light. Why would they name themselves anything useful? That’s how I ended up unscrewing the bulbs one by one to see which MAC address fell off the network. I gave them static IPs on a VLAN for future me to appreciate.

And with that, my home network is up to date!

Edit: you know what maybe I should follow this advice: “Maybe you shouldn’t install new software for a bit.”

Thanks for reading! Follow me on Mastodon and Bluesky. Subscribe to my Blog and Notes or Combined feeds.