Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

2,024 views
Skip to first unread message

NY

unread,
Mar 11, 2021, 9:24:23 AM3/11/21
to
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
GNU/Linux

before the update and currently reports

Linux martin-pi4 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l
GNU/Linux

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!

Deloptes

unread,
Mar 11, 2021, 1:43:48 PM3/11/21
to
NY wrote:

> Linux martin-pi4 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l
> GNU/Linux
>
> before the update and currently reports
>
> Linux martin-pi4 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021
> armv7l GNU/Linux
>
> So there has been a significant update to the kernel.

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.

Rainer Kupke

unread,
Mar 11, 2021, 3:45:04 PM3/11/21
to
Am 11.03.21 um 15:23 schrieb NY:
> 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.

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:
> bootcode_delay=10
> boot_delay=10

HTH
Rainer

Matt Ernisse

unread,
Mar 11, 2021, 4:00:27 PM3/11/21
to
On 2021-03-11, NY <m...@privacy.invalid> wrote:
>
> 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?

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

NY

unread,
Mar 11, 2021, 4:03:15 PM3/11/21
to
"Deloptes" <delo...@gmail.com> wrote in message
news:s2dod2$rcl$1...@dont-email.me...
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?

Joe

unread,
Mar 11, 2021, 5:28:08 PM3/11/21
to
On Thu, 11 Mar 2021 14:23:50 -0000
"NY" <m...@privacy.invalid> wrote:

> 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 GNU/Linux
>
> before the update and currently reports
>
> Linux martin-pi4 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021
> armv7l GNU/Linux
>
> 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?

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

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

Deloptes

unread,
Mar 11, 2021, 7:13:03 PM3/11/21
to
NY wrote:

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

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



Jim Jackson

unread,
Mar 13, 2021, 5:13:49 PM3/13/21
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.

NY

unread,
Mar 13, 2021, 5:54:54 PM3/13/21
to
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"?

A. Dumas

unread,
Mar 14, 2021, 6:20:02 AM3/14/21
to
On 13-03-2021 23:54, NY wrote:
> 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 https://github.com/Hexxeh/rpi-update 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.

Chris Elvidge

unread,
Mar 14, 2021, 7:22:26 AM3/14/21
to
On 13/03/2021 10:54 pm, NY wrote:
>
> 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.
>

If you look at the kernel archives page <https://www.kernel.org/> 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
0 new messages