Rolling back "sudo apt update" and "sudo apt full-upgrade" to previous state

I have a Pi4 with Raspberry Pi Os Buster, running TVHeadend so it works as a
personal video recorder. Following a recent "sudo apt update" and "sudo apt
full-upgrade", recording from a satellite tuner has become a bit unreliable:
I get more data errors than normal and recordings sometimes end prematurely.
The hardware (tuner, cable, LNB, dish) is OK because it still works on a Pi
3 running TVH.
Someone has suggested that the update may have included a changed (and
broken?) driver for the satellite tuner.
"uname -a" reported
Linux martin-pi4 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l
before the update and currently reports
Linux martin-pi4 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l
So there has been a significant update to the kernel.
Is there a way to list what packages were updated on a given date (probably
early March) and to roll back the version of each package (in the right
order, in case of dependencies) to the version just before the update?
It's frustrating that I got into the habit, every time I updated, of
removing the SD card, imaging it, replacing it, upgrading and then
temporarily removing it to take another image. But then I got too lazy to
carry on doing that, so my last image dates from the middle of last year.
For other reasons (*), I may still decide to reinstall from scratch, from
the latest download of Raspios (2021-01-11) which dates from before I
upgraded so is hopefully safe. But it would still be useful to know, in
general, how to roll back an "apt full-upgrade".
) The current installation was using NOOBS, to the 16 GB card supplied
with the Pi. I realised pretty soon that there wasn't much spare system
partition space. So I created an image, wrote it to a 32 GB card and booted
from that. Perfect, except that NOOBS creates all sorts of misc partitions
which prevent the system partition being enlarged. So I have a 32 GB card
with only 16 GB usable as system partition. Next time I'll do it properly:
using Raspios rather than NOOBS, and to the 32 GB card. Lesson learned!
Reply to
Loading thread data ...
luckily the kernel is more or less independent. I would just copy the old kernel and its drivers and test. If you are lucky and the problem is somewhere in the kernel, you win. If you are not lucky, then at least you eliminated the kernel as a source.
Reply to
Am 11.03.21 um 15:23 schrieb NY:
When I upgraded from a Pi3 to a Pi4 my (DVB-C) receivers became very unreliable. Sometimes they would not show up at all, sometines they produced lots of errors. Especially on cold boot when they were not powered up before the Pi.
Maybe they are just not ready when the faster Pi4 tries to upload their firmware? Maybe the power supply of my external hub takes too long to deliver stable voltage?
All those problems went away when I inserted this into config.txt:
HTH Rainer
Reply to
Rainer Kupke
I am not aware of any way to roll back package updates automagically like that. If you had cron-apt do the update it should have logged the versions but if you did it manually then I don't believe there is a record. In either case you'd have to manually downgrade every package. If it is truly the kernel you should be able to downgrade raspberrypi-kernel package.
Matthew Ernisse               
"The avalanche has started, it is too late for the pebbles to vote." 
 Click to see the full signature
Reply to
Matt Ernisse
Are old kernels saved anywhere when one is updated during an apt full-upgrade? Is there a way of looking at what kernel version a given (saved) file relates to? Or do I just do it by timestamp - choose the newest archive one that is older than the one in /boot?
/boot contains:
-rwxr-xr-x 1 root root 6320896 Mar 4 11:24 kernel7.img -rwxr-xr-x 1 root root 6694536 Mar 4 11:24 kernel7l.img -rwxr-xr-x 1 root root 7758284 Mar 4 11:24 kernel8.img -rwxr-xr-x 1 root root 5981936 Mar 4 11:24 kernel.img
Where 4 March is the date when I did the apt full-upgrade. I presume kernel7l.img is the one I'd want to overwrite with an earlier version, since uname -a gives the version as 5.10.17-v7l (ie with "7l" on the end).
Am I right that with UNIX, all device drivers are part of the kernel and there aren't any other file that would have to be patched? I know about /lib/firmware files. but the one for my DVB-S tuner hasn't changed.
When the Pi's (3 and 4) have finished recording and can be rebooted or I can move the tuner from one to the other, I'll first make sure that the Pi 4 with the latest disk image that I saved (writing to a new card) does definitely run OK. I'll keep the SD card that the Pi is currently using so I can do diagnostic investigations as you suggest - once I know where the old kernels are saved. Then I'll reinstall RaspiOS onto the new card, firstly to guarantee a clean installation and secondly to get round the 16 GB and NOOBS legacy. Lucky I kept copious notes of everything I customised and configured, so I can follow them to reinstall.
It's a weird symptom. It's not an outright failure: it's more insidious. Intriguingly, TVHeadend reports SNR and signal strength stats for an in-use tuner, and it's always reported them as numbers in dB or dBm. But since the increase in data errors in recordings and the premature ending, the stats are now (usually *) reported as % bars, as if the driver is reporting differently, triggering different code in TVH. And TVH definitely hasn't been updated for donkey's years because they seem to have stopped doing new builds for it (not that anything needs changing that I'm aware of).
) And the "usually" is weird: after a reboot, it reports numbers, and then a minute or so later, it switches over. WTF is going on there? Software - don't you just love it?
Reply to
Apt keeps a log under /var/log/apt, but I'm not aware of a reading tool, you may have to pick your way through it with grep.
No, there isn't a way, only backups. In many cases, it's only one or two packages you will need to roll back, and if you're not in the habit of cleaning the apt cache (/var/cache/apt/archive), you may well have the earlier packages stored there.
Reply to
you said you did backups but not recently. you could pick up some of the older images/backups and copy from there
The files you listed are targeting different versions of RPI kernel one for armel, armhf or arm64
because you use the 7l AFAIR it is armhf, so you need an older version of the same. For example the kernel7l.img for 5.10.17-v7l+ that was working and the drivers (means directory /lib/modules/5.10.17-v7l+)
Reply to
In the rpi forums I saw that
rpi-update 453e49bdd87325369b462b40e809d5f3187df21d
will revert your system to the 5.4 kernel used bfore the latest change to 5.10 I haven't used it - I just filed it away for reference.
Reply to
Jim Jackson
Hmmm. The cynic in me says that "they" wouldn't have produced this update if there wasn't a *need* to roll back to 5.4 - ie if there wasn't a problem with 5.10.
An increase from 5.4 straight to 5.10 seems a very large jump, unless it's just a funny with the way that the version numbers increment.
I've started again from scratch, doing the job right this time (install from RaspiOS distro rather than NOOBS, and install to a 32 GB card). That gives a 5.4 kernel, and the problem I was seeing is not present.
However as an educational exercise, I will try installing the update you mention to see if if solves the problem. I'll need to schedule my testing for a time when the Pi isn't needed for recording TV ;-)
Silly question: how do I actually obtain rpi-update 453e49bdd87325369b462b40e809d5f3187df21d? Is it one of the packages that is now offered when I do an "apt update"?
Reply to
Is rpi-update not installed by default? It's a shell script that pulls and installs firmware and kernel files. Install it first with apt or apt-get, or from
formatting link
if you feel really adventurous. Then you can use it with a hash argument to load a specific version of the system files.
Without a hash, it updates to the absolute bleeding edge unsupported untested (sorta) latest updates. Do. Not. Use. It. for that if you value system stability.
Reply to
A. Dumas
If you look at the kernel archives page you will see that every version between 5.4 and 5.10 (exclusive) has been removed. 5.4 and 5.10 are both longterm releases.
Chris Elvidge 
Reply to
Chris Elvidge

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.