apt-get update fails cause 'Suite' changed from 'stable' to 'oldstable' #5

New Issue

ungleich-gitea · 2021-11-20T11:24:43Z

ungleich-gitea commented

2021-11-20 11:24:43 +00:00

After the bullseye release, the Debian repos changed there releaseinfo's accordingly and now an non-interactive apt-get update aborts because the suite changed and waits for acknowledgment. This aborts each cdist run which updates the package index till you run it yourself and interactively acknowledge that.

The abort looks like:

E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable'

As documented in Debian bug #931566, it was fixed for unstable at Tue, 11 Aug 2020 14:28:07 +0200 (ver. 2.1.10) and for Buster at Mon, 19 Apr 2021 18:41:13 +0200 (cherry-picked to ver. 1.8.2.3), meaning that all Debians that did an update after this date work fine. If they didn't updated apt after this date, they get these aborts.

For the affected machines, we could do following: to automatically acknowledge it, apt-get has an option for it (apt-get(8) OPTIONS):

--allow-releaseinfo-change

Allow the update command to continue downloading data from a repository which changed its information
of the release contained in the repository indicating e.g a new major release. APT will fail at the
update command for such repositories until the change is confirmed to ensure the user is prepared for
the change. See also apt-secure(8) for details on the concept and configuration.

Specialist options (--allow-releaseinfo-change-field) exist to allow changes only for certain fields
like origin, label, codename, suite, version and defaultpin. See also apt_preferences(5).
Configuration Item: Acquire::AllowReleaseInfoChange.

To avoid breaking old apt versions that don't support these arguments, they can be called with -o which ignores unknown configurations.

It would mean we need to patch following types because they use apt-get update:

$ grep "apt-get update" -riIn .
./__apt_source/gencode-remote:26:   printf 'apt-get update || apt-get update\n'
./__apt_update_index/man.rst:11:This cdist type runs apt-get update whenever any apt sources have changed.
./__apt_update_index/gencode-remote:21:# run 'apt-get update' if anything in /etc/apt is newer then /var/lib/apt/lists
./__apt_update_index/gencode-remote:24:   apt-get update || apt-get update
./__package_update_index/man.rst:37:        apt-cache was updated (run of `apt-get update`). `currage` is the time
./__package_apt/gencode-remote:89:then echo apt-get update > /dev/null 2>&1 || true

I don't know the number of affected hosts, but it's a lot from my containers because I don't run apt-get upgrade's regularly (which would install the new apt version). I think it depends on each upgrade policy if the new apt version was installed or not.

For the question if we need all these types, I would open a new issue for it.

After the bullseye release, the Debian repos changed there releaseinfo's accordingly and now an non-interactive `apt-get update` aborts because the suite changed and waits for acknowledgment. This aborts each cdist run which updates the package index till you run it yourself and interactively acknowledge that. The abort looks like: ``` E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable' ``` As documented in [Debian bug #931566](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931566), it was fixed for unstable at _Tue, 11 Aug 2020 14:28:07 +0200 (ver. 2.1.10)_ and for Buster at _Mon, 19 Apr 2021 18:41:13 +0200 (cherry-picked to ver. 1.8.2.3)_, meaning that all Debians that did an update after this date work fine. If they didn't updated `apt` after this date, they get these aborts. For the affected machines, we could do following: to automatically acknowledge it, `apt-get` has an option for it (`apt-get(8)` OPTIONS): > **--allow-releaseinfo-change** > > Allow the update command to continue downloading data from a repository which changed its information > of the release contained in the repository indicating e.g a new major release. APT will fail at the > update command for such repositories until the change is confirmed to ensure the user is prepared for > the change. See also apt-secure(8) for details on the concept and configuration. > > Specialist options (--allow-releaseinfo-change-field) exist to allow changes only for certain fields > like origin, label, codename, suite, version and defaultpin. See also apt_preferences(5). > Configuration Item: Acquire::AllowReleaseInfoChange. To avoid breaking old `apt` versions that don't support these arguments, they can be called with `-o` which ignores unknown configurations. It would mean we need to patch following types because they use `apt-get update`: ```sh $ grep "apt-get update" -riIn . ./__apt_source/gencode-remote:26: printf 'apt-get update || apt-get update\n' ./__apt_update_index/man.rst:11:This cdist type runs apt-get update whenever any apt sources have changed. ./__apt_update_index/gencode-remote:21:# run 'apt-get update' if anything in /etc/apt is newer then /var/lib/apt/lists ./__apt_update_index/gencode-remote:24: apt-get update || apt-get update ./__package_update_index/man.rst:37: apt-cache was updated (run of `apt-get update`). `currage` is the time ./__package_apt/gencode-remote:89:then echo apt-get update > /dev/null 2>&1 || true ``` I don't know the number of affected hosts, but it's a lot from my containers because I don't run `apt-get upgrade`'s regularly (which would install the new apt version). I think it depends on each upgrade policy if the new apt version was installed or not. For the question if we need all these types, I would open a new issue for it.

ungleich-gitea closed this issue

2021-11-20 11:24:43 +00:00

ungleich-gitea commented

2021-11-20 15:24:57 +00:00

fixed as all MRs merged