post-upgrade restoration of configuration files

Question

When I last upgraded Rpi OS (Lite) from stretch to buster, I followed an in-place upgrade procedure; i.e. apt update, ... upgrade, ... dist-upgrade, & edit /etc/apt/sources.list. This worked out fine. During the approx. 2 years I used buster, I never experienced any hangovers due to the in-place upgrade.

Now it's time for the upgrade to bullseye. Following my usual pattern of research before stumbling forward, I have read The Foundation's pronouncements on upgrading in the "Official Documentation", and in their referenced post for a buster-to-bullseye in-place upgrade. The Foundation's warnings against an in-place upgrade struck me as a bit more urgent this time around, but perhaps that's only me after 2 years of COVID warnings :) In either case, the immutable law of "cruft accumulates" finally convinced me that a fresh install might be the way to go this time.

Which brings me, finally, to the question: What's best practice for restoring all of the configuration changes I made to my old buster system over the course of 2 years to my new bullseye system? My current best guesses are that a recursive diff, or rsync to list the changed files might work. It also occurs to me that there may be an existing solution, a tool tailored to this tedious job. Any of the above would be welcome.

Answer 1

Your reservations about an upgrade are well founded. Old config.txt settings won't work on Bullseye apart from the kms changes.

I have done 2 "upgrades" (for testing) & a fresh install.

You may be interested in the procedures I use to work out what to install. Ideally this needed a few changes installed when you first used Buster to identify older packages, but can be applied to an old backup image.

See https://raspberrypi.stackexchange.com/a/128009/8697

---

I have been putting together a few notes on Bullseye - the following are my observations.

This version seems to have been designed for users who use the GUI Desktop on a Pi4/Pi400 with little consideration for those running older models, headless or at CLI (and even less testing of these scenarios).

Unsurprisingly there are a number of issues, some of which have been addressed by updates, but the downloadable image is unchanged, so be prepared to upgrade, before anything else.

If you are using your Pi as a desktop computer then it appears to be quite usable, although PiCamera users should expect to adapt to new interfaces.

One thing to note ANY display oriented customisations in config.txt and most tutorials DO NOT apply to Raspberry Pi OS Bullseye,

What has changed

Debian Bullseye has relatively few changes which are visible to users – most of the changes are patches and upgrades to existing applications and features.

However, over and above the changes in Debian itself, the Bullseye version of Raspberry Pi OS has a number of significant changes to the Desktop Environment and to support for Raspberry Pi hardware.

All of the desktop components and applications are now using version 3 of GTK+

Window manager

One of the changes which was prompted by the move to GTK+3 is that it uses a new Window Manager Mutter instead of the Openbox Window Manager used in previous releases.

Mutter can only run properly on a Raspberry Pi with 2GB or more. On Raspberry Pis with less than 2GB the older Openbox Window Manager is still used.

Notifications

This release added a common notification manager to the taskbar, which can be used by the taskbar and any of its plugins, and can also be accessed via other applications.

Notifications are shown in windows at the top right corner of the screen, and are displayed in chronological order, with the most recent notifications being presented at the top. Notifications will automatically time out and be hidden after fifteen seconds, or can be cleared immediately by clicking on the windows.

Updater plugin

Another new feature, which makes use of the notification system, is an easy way to be informed about and to install system and application updates.

KMS video driver

The KMS (kernel modesetting) driver, which was an experimental option in previous releases, is now the standard video driver in this release.

New camera driver

The driver used by Raspberry Pi to access camera modules has now been replaced with libcamera, a standard Linux API.

VNC

If you have enabled the in-built VNC server, you should have Openbox rather than mutter. Updates appear to have fixed headless VNC as I can now set a headless resolution with raspi-config for VNC to use when running headless.