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

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.

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

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.

--Matt

--
Matthew Ernisse                        https://www.going-flying.com/ 
"The avalanche has started, it is too late for the pebbles to vote." 
  --Kosh

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?

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.

--
Joe

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+)

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.

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"?

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

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.

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 
England