Repo changed from "stable" to "oldstable", what does this mean?

[Taomyn]

When I went to update my 3 x RPI-4s they all showed no updates, which is unusual in my experience even after a week between checks I usually get some updates, but now they all also display the message after the check:

Code: Select all

N: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'

What does this mean?

The full text from a check of one RPi is:

Code: Select all

pi@octopi:~ $ sudo apt update
Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB]
Get:2 http://archive.raspberrypi.org/debian buster/main armhf Packages [378 kB]                                             
Hit:3 https://repo.zabbix.com/zabbix/5.4/raspbian buster InRelease                              
Get:4 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]                       
Get:5 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages [13.0 MB]
Fetched 13.4 MB in 9s (1,513 kB/s)                                                                                                                                      
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
N: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'

[rpdom]

It's nothing to worry about.

The main Raspbian repository tracks the Debian repositories. Debian has just upgraded from Buster to Bullseye. Bullseye is their new "stable" release and Buster has been relegated to "oldstable".

When Raspberry Pi are ready, they will release new install images that use Bullseye instead of Buster. That will be fairly soon.

There are some important differences between Buster and Bullseye, most notably the removal of Python 2.

[Taomyn]

It's nothing to worry about.

Thanks for the prompt response and explanation, I'm glad it's nothing to be concerned over, but my worry stemmed more from the fact that there were zero updates on all my devices which has never happened in the year or so of checking every week - yes I'm a bit thorough in this regard.

[greatquux]

Will we be able to upgrade to the bullseye release when ready with a simple apt update and apt full-upgrade?

[roydukkey]

[...] they will release new install images that use Bullseye instead of Buster.

Will these images seamlessly apply and install with these commands? Or, will systems currently on Buster diverge from active, regular updates?

Code: Select all

sudo apt update
sudo apt full-upgrade

[davidcoton]

Will we be able to upgrade to the bullseye release when ready with a simple apt update and apt full-upgrade?

[...] they will release new install images that use Bullseye instead of Buster.

Will these images seamlessly apply and install with these commands? Or, will systems currently on Buster diverge from active, regular updates?

Code: Select all

sudo apt update
sudo apt full-upgrade

From past history, it is unlikely that cross-version upgrades will be supported.

It is possible that upgrading basic systems will just be a matter of changing the apt sources, but it is also possible that *your* system will break.

The normal mantra will continue to update systems within the original version, but from past history RPT will not continue to provide updates, so only the Debian updates will apply.

[electronix_tech]

I used Solution 1 from this web page and it fixed that problem.

https://exerror.com/repository-http-deb ... e-updates/

Solution 1. sudo apt-get update --allow-releaseinfo-change

[HawaiianPi]

Will we be able to upgrade to the bullseye release when ready with a simple apt update and apt full-upgrade?

By default update/full-upgrade only performs upgrades to the installed release (Buster will only get Buster updates).

Upgrading to a new major release has never been an approved procedure. Raspberry Pi OS is not a rolling release (meaning, it's not designed to upgrade from one major release to another).

That doesn't mean people won't try it, and some may even be successful, but for others it will end badly. It's always recommended to start fresh which each new major release. For some this may seem like a daunting task, but problems with in-place upgraded systems often cause far more headaches.

[pfletch101]

The normal mantra will continue to update systems within the original version, but from past history RPT will not continue to provide updates, so only the Debian updates will apply.

I share the OP's surprise that there were no available updates after (in my case) 2 weeks since my last apt dist-upgrade. I won't be moving to Bullseye for a couple of months (after it is released) on my 'workhorse' Pi, since I will have a fair amount of configuration and testing to do before I can do this. In the interim, will any Debian Buster updates (presumably largely security-related) be available from the Raspberry Pi Debian Buster repository, or will I need to go direct to the Debian repositories for these.

[davidcoton]

The normal mantra will continue to update systems within the original version, but from past history RPT will not continue to provide updates, so only the Debian updates will apply.

I share the OP's surprise that there were no available updates after (in my case) 2 weeks since my last apt dist-upgrade. I won't be moving to Bullseye for a couple of months (after it is released) on my 'workhorse' Pi, since I will have a fair amount of configuration and testing to do before I can do this. In the interim, will any Debian Buster updates (presumably largely security-related) be available from the Raspberry Pi Debian Buster repository, or will I need to go direct to the Debian repositories for these.

Again, looking at the precedents, security (and other) updates from Debian will be echoed in the RPiOS repository. It is only the RPi specific updates that cease -- RPT do not have the (human) bandwidth to support two versions.

It should not matter, but note that apt full-upgrade has replaced apt dist-upgrade. It's just a name thing, dist-upgrade was misleading because the distribution (wheezy/jessie/stretch/buster/bullseye) actually remains the same, there is no automatic cross-distribution upgrade in apt.

[craigevil]

Upgrading to a new major release has never been an approved procedure. Raspberry Pi OS is not a rolling release (meaning, it's not designed to upgrade from one major release to another).

That is too bad. With Debian you can pretty much go from release to release forever as long as you READ the Release docs.

What changes that rpios can't be upgraded to a new release?

I added the Bullseye repos months ago and everything seems to be working without any problems.

Active apt repos in: /etc/apt/sources.list.d/raspi.list
1: deb https://archive.raspberrypi.org/debian/ buster main
2: deb https://archive.raspberrypi.org/debian/ bullseye main

[jamesh]

Upgrading to a new major release has never been an approved procedure. Raspberry Pi OS is not a rolling release (meaning, it's not designed to upgrade from one major release to another).

That is too bad. With Debian you can pretty much go from release to release forever as long as you READ the Release docs.

What changes that rpios can't be upgraded to a new release?

I added the Bullseye repos months ago and everything seems to be working without any problems.

Active apt repos in: /etc/apt/sources.list.d/raspi.list
1: deb https://archive.raspberrypi.org/debian/ buster main
2: deb https://archive.raspberrypi.org/debian/ bullseye main

You can certainly try it, but we don't test it, and don't put any effort in to making sure it works. So the choice is yours.

[dickon]

You can certainly try it, but we don't test it, and don't put any effort in to making sure it works. So the choice is yours.

And that having finally been said, I can say without fear of being countered, that it's been flawless every time I've done it. I will happily admit that my systems aren't quite normal -- netbooted, so /dev/mmcblk0p1 size is irrelevant; no desktop -- but the usual Debian update dance has workd for me every time. Headless lite -> lite will probably just work. Desktops possibly not so much.

Snapshot and try it. If you can't snapshot, well, that's another discussion...

[Chivar]

That is too bad. With Debian you can pretty much go from release to release forever as long as you READ the Release docs.

What changes that rpios can't be upgraded to a new release?

I added the Bullseye repos months ago and everything seems to be working without any problems.

Active apt repos in: /etc/apt/sources.list.d/raspi.list
1: deb https://archive.raspberrypi.org/debian/ buster main
2: deb https://archive.raspberrypi.org/debian/ bullseye main

2: deb https://archive.raspberrypi.org/debian/ bullseye main <---- this worked for me also i just added it on a new line

[allpass]

This is a big problem for us. We run automatic updates in our product (running on CM3+) that runs apt-get update -y and this change basically breaks hundreds of end-user products in the field.

Is there a way to revert this so that updates will continue to work? Accepting returns of all these units because the update system is broken or having to explain to several hundred customers how to manually re-image their system is going to be a very expensive prospect for us.

[jamesh]

I've asked around to see if there is anything that can be done. I don't know enough about it to know where the change came from or what it affects or how to get round it.

However, I am quite concerned about you updating multiple products in the field automatically from the repos without testing first. Really you shouldn't be doing this, as there is really no guarantee that it will work properly afterwards. This is a prime example! For products like this you should provide your own updates that are fully testing and you know will work, not rely on some third party system. Probably your own apt server where you control exactly what goes on, but I am no expert.

[PhilE]

We've never (in my memory) supported upgrades between major OS releases. From https://www.raspberrypi.org/documentati ... rs/os.html (emphasis added):

Note that full-upgrade is used in preference to a simple upgrade, as it also picks up any dependency changes that may have been made.

Generally speaking, doing this regularly will keep your installation up to date for the particular major Raspberry Pi OS release you are using (e.g. Stretch). It will not update from one major release to another, for example, Stretch to Buster.

And further down, before the discussion of dust-upgrade, it says:

Upgrading from Operating System Versions
WARNING
Upgrading an existing image is possible, but is not guaranteed to work in every circumstance and we do not recommend it. If you do wish to try upgrading your operating system version, we strongly suggest making a backup first — we can accept no responsibility for loss of data from a failed update.

[PhilE]

And it's a bit much to say

this change basically breaks hundreds of end-user products in the field.

when what you mean is that they will no longer update.

[allpass]

when what you mean is that they will no longer update.

Well sure, but users think it's broken because our app reports an error.

We still had the raspi repos in the sources list but we've locked all package versions to the current ones except for the apt server that serves the latest version of our application. I never thought I had to remove those since I figured they wouldn't change, or that the raspi servers being down wouldn't cause the apt-get update to require user intervention. Indeed during testing we saw some servers down and the process still completed anyway without manual prodding. Obviously it's my fault for not knowing the intricacies of this stuff... I wear many hats. But I don't understand the purpose behind requiring manual changes... I've been using Linux on my desktop for years and never had this happen to me.

Does anyone know of a GUI-based tool that incorporates usbboot and an image writing tool into one program? If my users have to image their units I need something as straightforward as possible. Ideally they could plug in the USB bootloader port on the device, run a program and it would bootload and then update the image in one step. I wrote up instructions for my IT-minded users but a lot of folks don't even know which end of the USB cable is which.

[AkulaMD]

It's nothing to worry about.

The main Raspbian repository tracks the Debian repositories. Debian has just upgraded from Buster to Bullseye. Bullseye is their new "stable" release and Buster has been relegated to "oldstable".

When Raspberry Pi are ready, they will release new install images that use Bullseye instead of Buster. That will be fairly soon.

There are some important differences between Buster and Bullseye, most notably the removal of Python 2.

Hi, newbie question here. What are the noticeable differences with the removal of Python 2 for a normal end user like me who use the Raspberry Pi 4 for watching YouTube, Netflix and browsing internet. Thank you in advance.

[craigevil]

None.

[jojopi]

We still had the raspi repos in the sources list but we've locked all package versions to the current ones except for the apt server that serves the latest version of our application.

The error message from apt-get update (1.8.2.2) is:

Code: Select all

E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

This disables the Raspbian repository only, not the Raspberry Pi OS repo, nor any that you have added.

So, can you push a new version of your application with a postinst script to accept the Suite change or otherwise patch the problem? Re-imaging seems a rather extreme solution, and bear in mind Raspberry Pi are not recommending bullseye yet, so you probably want to stay on buster for a few months anyway.

Incidentally, apt 1.8.2.3 was released on April 19, with the only difference being that AllowReleaseInfoChange::Suite defaults to true. If your systems had done an unpinned upgrade between then and August 14, that would also have avoided the problem:

Code: Select all

N: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'

[allpass]

So, can you push a new version of your application with a postinst script to accept the Suite change or otherwise patch the problem? Re-imaging seems a rather extreme solution, and bear in mind Raspberry Pi are not recommending bullseye yet, so you probably want to stay on buster for a few months anyway.

I would love to push a new version of my application but the problem is that apt-get update fails before my update script (triggered by my user application) even has a change to actually upgrade any packages. So the problem is that there seems like no way to actually have any packages update (mine or anyone else's) without console access which is not possible since there is no console accessible to the user.

[beta-tester]

1: deb https://archive.raspberrypi.org/debian/ buster main
2: deb https://archive.raspberrypi.org/debian/ bullseye main

simply replacing buster by bullseye or adding an additional line for bullseye in
/etc/apt/sources.list and /etc/apt/sources.list.d/raspi.list
does not work for me...

when i try to full-upgrade it throws an error:

Code: Select all

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Code: Select all

The following packages have unmet dependencies:
 libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6+rpi1 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

[jojopi]

libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6+rpi1 is to be installed

buster has 8.3.0-6+rpi1 and bullseye should have 8.4.0-7+rpi1.

Did you change all references in sources.list and sources.list.d/raspi.list? Did you run apt update before the upgrade?