The Raspberry Pi series of boards are noted for their good software support, with a continuous flow of operating system upgrades such that an original Pi from 2012 will still boot the latest Pi OS. But these upgrades are best done by writing a fresh SD card, so oddly, the Pi remains surprisingly difficult in many cases to upgrade in place. [Iustin Pop] has taken a look at the problem, and finds that though it’s not always easy it remains possible with a bit or work.
An upgrade in place of a Raspberry Pi OS install that’s running on a headless device is probably the simplest of the lot, with a relatively small set of issues. Do it on a machine using the GUI though, and the switch from x.org to Wayland makes for a whole world of pain.
Perhaps most interesting for the insight it gives us into the way Raspberry Pi OS is derived from Debian, is the crossgrade process from the ARMhf build for earlier machines to the ARM64 one for the more recent ones. Here aside from a headache of differing paths and versions, he encounters the Pi-specific compilation tweaks put in place by the developers of Raspberry Pi OS, leading to the ARMhf version being a different branch from the original Debian than the ARM64 one.
Having read his examination of in-place upgrades we have to say that simply writing a new SD card remains the most attractive option. But sometimes along comes a remote system where that’s simply not possible, and this guide might just be very useful sometime.
I’ve run Debian on my home machines for almost two decades now, and Raspbian / Raspberry Pi OS for about a decade.
I found, fairly early on, that while upgrading Debian from one major release to the next is technically possible, over time (and several upgrades), things tend to become … wonky – old configs lying around, software not quite working properly, etc. I’ve seen a number of packages break in weird and interesting ways after several in-place upgrades, and it’s just not worth the troubleshooting effort.
I’ve since switched to using LVM on my home machines. I now use a minimal root partition, with all of my data that I want to keep using after each upgrade (like /home) in a separate lv. Upgrading Debian now just involves me creating a new root lv, putting a fs on it, running debootstrap for the version I’m upgrading to, and installing packages I typically use (it’s a bit more involved than that – I have to set passwords, edit fstab, and update grub as well!), but it lets me keep my old root filesystem around for any configs which I might have missed, packages I might have forgotten to install, etc.
And, in the end, it’s a fresh install. No more unused files lying around for several upgrade cycles, no more packages breaking, etc.
Most of my Pis (I have a bit too many these days!) just receive a fresh image. A few of them, including an 8GB Pi 4, use a fairly large SD card (128GB), where I use a similar LVM setup to my x86 Debian machines. The aforementioned 8GB Pi 4 received it’s recent bookworm upgrade this way – I was able to write partition 2 of the image to a new root lv, back up the boot partition and copy the files from partition 1 on the image to the existing /boot, and make some minor tweaks, like mounting a separate data partition where /home and /opt live – and the Pi happily booted into bookworm.
In the end, things tend to just be a bit cleaner by doing a fresh install.
I use a similar structure model. I have /boot and /root on a 32gb SD card and /home on an external hard drive, mounted at boot, defined in /etc/fstab. That way I can plug the hard drive into any of my Pi’s or even any Linux computer and have the same /home environment with all my data with just a change to /etc/fstab. Moving from Bullseye to Bookworm was a relatively pain-free experience in that respect.
Sounds good, but even leaving /home unchanged has me caused problems with .config files not being compatible between versions of software which has bit me.
Me personally, every once in a while I just reinstall my os entirely and redo all the configurations as a bit of spring cleaning.
Eh, .config is easy enough to clear out if needed. No need to nuke all of /home for that!
But it can be easy to setup?
I believe many people do this. It focuses around accepting a new OS with unknowns and merging a mostly remembered snapshot of data , configuration, brute force and assertions of the packages you used and an accurately gathered uncorrupted footprint.
A book of your process, the concepts would be of good value. It could enable AIs to be built that could exceed in this task and provide the user a refresh understanding of their snapshot, mismatches and changes that may effect the user.
AIs exceed at these tasks as they don’t get bored and can cross their eyes and dot their Ts.
I went through a similar process for a long time. Eventually I ended up switching all of my machines (including SBCs) to NixOS, which completely solved this problem and created a set of new and exciting problems.
(NixOS has its own configuration language and stores all system state (including installed packages, service configuration, network config, etc) in one place. Keep the config well-commented and in a Git repo, and you never have the “what the hell did I do to set this up five years ago?” issue.)
That… sounds incredibly annoying. As an artix user, I don’t think I could ever switch away from rolling release distro
Meh, I’m using same main Debian machine, continuously upgraded, for about 17 years. If you know what you’re doing, it doesn’t keep slowing down.
I totally agree on upgrading the GUI version not being for the faint hearted.
Whenever I tried to upgrade the existing installation to a new version of Raspbian, it often ended up in a disaster.
About half of the installed applications were broken afterwards.
Back in the 90s, upgrading a PC from Windows 3.1 to Windows 95 or Me was much less of an issue, by comparison.
My philosophy with PI OS is just install newer PI OS on a brand new storage device. Take one of your RPI SBCs that you have (I am sure most of you have several in the parts bin… I know I do) and ‘build it’ with the software and data you have on the old SBC. Test it. Once satisfied, down the old SBC and attach the new storage device (whether SD card or USB drive) to it. Change the IP if static. ‘Upgrade’ complete with a nice clean system.
Ie. Always have a ‘spare’ or two RPIs available of each model :) .
Hopefully before long I can say that with RPI-5! However, right now I’d settle for just the one I’ve pre-ordered…. Ha.
” Take one of your RPI SBCs that you have (I am sure most of you have several in the parts bin… I know I do)”
Dude, there used to be a Raspberry Pi shortage not too long ago. Anything but an old Raspberry Pi was hard to get.
In the pandemic, many people desperately sold/bought Pi 3s/Pi4s for very high prices.
Then, a bit later, anything but the Pi 400 was unavailable to by new for a while. The normal Pi 4 wasn’t in production at that time.
Also, it’s a difference whether someone has a a few programs from the package manager installed or if someone has previously compiled a dozen bigger applications from source code.
Installing all the dependencies tzat come with it is quite some work, especially if they’re not part of the package manager.
Such a work may need hours to days to finish, especially if the install scripts stop each time for no apparent reason, asking for human interaction.
But yeah, if we’re talking about re-installing Minecraft and Libre Office, then a fresh installation now and then is perfectly fine. As with Windows. ;)
“Dude, there used to be a shortage” … I know but up until that point, I had bought several of each model. For example I had at least 2 RPI4s just sitting there during the shortage. Plus a RPI 400 that is still waiting in the wings for a project. Of course quite a few 3s are hanging around as they had been replaced with 4s. Now with Pico boards replacing Zeros, more Zero boards in the parts box. So it goes.
so they are emulating windoze!
Winedoze!
it’s not a great emulation though. For starters, you can’t get a virus off the print spooler. Also Edge isn’t constantly reinstalling.
Upgrade an in-field Pi? More like, try isolating it on the network best you can and then, fingers crossed nobody worms their way in.
Also, have a copy of the SD card image (or even better, a replacement SD card with the same image) ready as a swap-in replacement.
Wouldn’t want my heating system to go out in the midst of winter ;-)
i tried upgrading to bookworm last week and failed miserably, i’m glad to see i’m not the only one :)
Am I missing something ?
TFA says upgrading a headless system is easiest but goes on to say that many users will encounter a problem upgrading to Networkmanager that requires logging in locally. Not so easy on a headless system unless it defaults to having a serial console enabled (and even that requires extra hardware).
In the original author. For most headless systems, I have static IPs configured without NetworkManager or dhcpcd. That won’t hit the problem, nor will dhcp interfaces configured using /etc/network/interfaces. Only fully dynamic instances using dhcpcd will break.
Right. Because there is no longer a ‘default user’ (pi) in the bookworm install, I had to hookup a keyboard, mouse, monitor to add a user. Because I am not not familiar with network manager’s files behind the scenes, I used nmcli to configure the network(s) from a gui terminal… Finally I unhooked monitor, keyboard, and mouse and started using via ssh from a desktop now that network and user was configured :rolleyes: . So to me it is a lot more work to setup an RPI with PI OS Bookworm.
I might be missing something here, I have half dozen Pi running different things, I never ever had re-flash an SD. I upgrade the OS the same way as anything else based on Debian, with apt. Even with older Pi’s changing the version in sources.list + update + upgrade + reboot, it always worked.
I did this on my Pi a while back, and now audio refuses to work, and I have no idea why…
I’ve never hit a problem I couldn’t fix quite easily but an update of a Pi distro running a GUI does tend to have a little wonky somewhere in my experience, even for the more minor changes. And a big change like changing audio server to pipewire or moving from x to wayland is always challenging on any distro – that one is a rather hefty methodology change.
I’ve not had a problem with ‘apt update’, ‘apt upgrade’ … That works fine. Do that all the time. But it is when you move from say Bullseye to Bookworm that is the issue.
On the Desktop I love rolling release distros and don’t really understand why any point release distros are popular.
I guess I never tried it on a Pi.
Pi OS should be renamed BIC OS. In theory you can keep reusing it but it’s basically disposable. I had a multi user family PC running on a Pi4 and I cross-graded (new term for me) from 32bit to 64bit. It was a nightmare. Setting up multi-user was horrible so I was very motivated to not start from scratch with 64 bit. I got it to work but later “sudo apt upgrades” eventually failed due to mis matching package versions. “Install fix broken” is BS. Also there is no consistency in the locations of application and OS config files between different system directories and between system and user directories. That is fundamental Linux weakness. Something as simple as setting a login background takes you through a myriad of symbolic (and maybe hard) links. Not for the fainthearted. Building an Arch install from scratch is probably a doddle by comparison. And ultimately you will fail, but isn’t that life. If the Pi OS goal is to teach by failing (the Edison method), then it is brilliant.
You are not supposed to ever use “apt upgrade” to do a release change as this will certainly break stuff. The correct command is “apt dist-upgrade” or “apt full-upgrade”
I’m not sure if that would have fixed all issues with the arch change, but you would have gotten farther at least :)
I’ll point out that is far easier to add a 32 bit userland to a 64 bit OS, rather than the other way around.
Matt – I tried all of those, but as a scatter gun. Now that I think back, the final straw was some kind of memory leak whereby the system would get so slow over a few days doing nothing that you could not log in. Another similar issue happened in the Chromium Browser whereby Google would start up experimental tasks (a normal thing AFAIK) but these would also overload the processor within a few hours. I wired in a reboot button on my Pi to avoid power downs and stressing drives, but even that was hit or miss. Currently I have a repurposed Atari VCS as our family PC and it is bomb proof. Runs Ubuntu. I also have my very first Pi from around 2012 running my ad blocker (PiHole) in a basement and it is also highly reliable. 100% uptime. Pis seem best suited to focused applications with minimal OS hacking.
Just to clarify about my blog post – the bullseye→bookworm upgrade was the trivial part; most of the difficulty and focus was on moving user land from 32bit to 64bit. That was a real pain, and I’m glad it’s behind me.
I run two “production” pi’s in my home, one runs a java service that controls my heating zones and boilers. It’s normally very easy; just a clean os install, dependencies, and the java program just runs.
The other one is more tricky – I have a c# app that I run fullscreen on a pi official touchscreen, which means installing mono. This one I find a lot more difficult to ‘upgrade’ (which really means install from scratch)
I’m tempted to just leave the older os versions running.