Bug#849382: [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.
Hi, As discussed via IRC, this could be a case of https://bugs.debian.org/838920 in unattended-upgrades. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
Bug#849382: [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.
On 07.01.2017 21:24, Julian Andres Klode wrote: > On Sat, Jan 07, 2017 at 09:15:15PM +0100, Sven Hartge wrote: >> On Mon, 26 Dec 2016 14:40:05 +0100 (CET) <34tg...@tutanota.com> wrote: >> >>> I use Debian 8 64bit with GNOME installed with standard install >>> procedure from netinstall and using tasksel. This occured to me the >>> second time. First time was a year ago, I reinstalled Debian then and >>> a year after this happens again. Both occurences were on Debian 8, >>> stable at the time. >> >> I have seen this as well and know under which circumstances this happens: >> >> a) backports repository is enabled in source.list (obviously) >> b) "apt update" is run and all normal repositories fail to download or >> are invalid >> >> When this happens, apt will happily upgrade all packages where a >> backported version exists to that version. > > This should not happen. The old repository state should be used, and thus > the pinning should not change. That's what I thought as well. > That said, maybe that only works right in 1.1 and newer, I don't > really know. I have definitely seen this in Jessie, maybe even Wheezy (memory a bit fuzzy in that regard). I run apticron on all our servers (~250) and it happened about once a month that one (a different one every time) of the server prompted to upgrade all packages to their backports-version. But after switching from httpredir.debian.org to deb.debian.org this problem did not occur again, so far at least. But there is absolutely something problematic with the version in Jessie where it is possible to trigger the behavior from this bug report. Grüße, Sven. signature.asc Description: OpenPGP digital signature
Bug#849382: [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.
On Sat, Jan 07, 2017 at 09:15:15PM +0100, Sven Hartge wrote:
> On Mon, 26 Dec 2016 14:40:05 +0100 (CET) <34tg...@tutanota.com> wrote:
>
> > I use Debian 8 64bit with GNOME installed with standard install
> > procedure from netinstall and using tasksel. This occured to me the
> > second time. First time was a year ago, I reinstalled Debian then and
> > a year after this happens again. Both occurences were on Debian 8,
> > stable at the time.
>
> I have seen this as well and know under which circumstances this happens:
>
> a) backports repository is enabled in source.list (obviously)
> b) "apt update" is run and all normal repositories fail to download or
> are invalid
>
> When this happens, apt will happily upgrade all packages where a
> backported version exists to that version.
This should not happen. The old repository state should be used, and thus
the pinning should not change.
That said, maybe that only works right in 1.1 and newer, I don't
really know.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Bug#849382: [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.
On Mon, 26 Dec 2016 14:40:05 +0100 (CET) <34tg...@tutanota.com> wrote: > I use Debian 8 64bit with GNOME installed with standard install > procedure from netinstall and using tasksel. This occured to me the > second time. First time was a year ago, I reinstalled Debian then and > a year after this happens again. Both occurences were on Debian 8, > stable at the time. I have seen this as well and know under which circumstances this happens: a) backports repository is enabled in source.list (obviously) b) "apt update" is run and all normal repositories fail to download or are invalid When this happens, apt will happily upgrade all packages where a backported version exists to that version. Why? Because of the pin value of a package in such a case. For example: # apt-cache policy exim4 exim4: Installed: 4.84.2-2+deb8u2 Candidate: 4.84.2-2+deb8u2 Version table: 4.88~RC6-2~bpo8+1 0 100 http://deb.debian.org/debian/ jessie-backports/main amd64 Packages *** 4.84.2-2+deb8u2 0 500 http://deb.debian.org/debian-security/ jessie/updates/main amd64 Packages 500 http://security.debian.org/ jessie/updates/main amd64 Packages 100 /var/lib/dpkg/status 4.84.2-2+deb8u1 0 500 http://deb.debian.org/debian/ jessie/main amd64 Packages The backports pacakges has a value of 100 as has the installed package. The package from the normal repository is at 500 and thus the candidate. If the normal repositories fail to download and are invalid the backported package and the installed package both are the only candidates left (and are both at the same pin value) and because the backported package has a higher version it is installed. Workaround: Have more than one mirror configured so that the chance is higher that at least one is valid. Grüße, Sven.
Bug#849382: [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.
Package: apt
Version: 1.0.9.8.4
Severity: critical
--- Please enter the report below this line. ---
I use Debian 8 64bit with GNOME installed with standard install procedure from
netinstall and using tasksel.
This occured to me the second time. First time was a year ago, I reinstalled
Debian then and a year after this happens again.
Both occurences were on Debian 8, stable at the time. They were installed from
the stable repo, I have logs of that.
I did not make any changes to my system lately and I generally do not tinker.
The only new packages that I installed during recent month were mktorrent,
mediainfo
Backports repo was pinned to 100 according to apt-cache policy after system
installation and now too, after the bug occured. I did not change pinning
settings ever on this machine nor any other.
# TLDR
Every package on system gets updated to the version from backports silently
(yes, I did click the upgrade button without checking if the right versions are
installed of each package) even though backports repo is pinned to 100. This
results in slow breakage of everything, max few days to make the machine
useless to do work as usual.
# Description of what happened
Few days ago (it's worth noting that the machine was on for perhaps a week and
package upgrades were performed) I noticed that hibernation stopped working on
my system for no apparent reason. Every time after I hibernated the machine,
upon booting it restarted and then at the next boot ext4 was performing fs
check and repairing lots of errors.
The next thing I noticed was that disk IO became extremely slow. It's the most
stable consumer SSD available at the moment, Intel 730. It performed no problem
before, but now if I move 100 or even 50 files, bunch of kilobytes in size
(together 1MB) the operation can take a minute or even more. No noticeable disk
problems with playing 1080p videos or browsing the web. Another system on this
machine (Windows) doesn't seem to exhibit similar issues.
Next thing is a message asking if software upgrades should be installed when I
click the power off button in GNOME. Next boot it installs them, but system
crashes. Then when I boot again, ext4 check and repair and lots of errors. BTW
While writing this, I clicked that GNOME power button and canceled, clicked
again, window didn't appear and the system turned itself off.
Evolution email client started showing folders I disabled and some errors about
cache (missing or something).
Firefox signed me out from every single website.
I became worried about what's happening with my machine, tried apt-get update
and upgrade manually (I normally use apt-config-auto-update), that's what
upgrade says "The following packages have been kept back: linux-image-amd64".
So it occured to me that it may be the same bug that killed my machine a year
ago, I runned "dpkg -l |awk '/^ii/ && $3 ~ /bpo[6-8]/ {print $2}'" to see what
backports are installed, and yes, every package that has a backport version
available was switched to that version silently and apt-cache policy still says
backports are pinned to 100! This is exactly what happened a year ago.
The only sane fix for this machine now is a complete reinstall.
Worth noting that a year ago this made dpkg unusable, ie. no package could be
installed or upgraded because of dependency breakage.
# List of backports installed.
Before that the only backports I had on my system were: apt-config-auto-update
(installed it with apt-get -t jessie-backports install), python-idna
(automatically installed with torbrowser-launcher), python-axolotl (installed
with apt-get install python-axolotl).
Now "dpkg -l |awk '/^ii/ && $3 ~ /bpo[6-8]/ {print $2}'" shows this:
apt-config-auto-update
autopoint
calibre
calibre-bin
dh-python
dmidecode
e2fslibs:amd64
e2fsprogs
exfat-fuse
exfat-utils
ffmpeg
firmware-realtek
fonts-opensymbol
geoip-database
gettext
gettext-base
gir1.2-gdata-0.0:amd64
hexchat
hexchat-common
hoichess
i965-va-driver:amd64
ifupdown
inkscape
libapparmor1:amd64
libasprintf-dev:amd64
libasprintf0c2:amd64
libav-tools
libavcodec57:amd64
libavdevice57:amd64
libavfilter6:amd64
libavformat57:amd64
libavresample3:amd64
libavutil55:amd64
libbluray1:amd64
libbrlapi0.6:amd64
libchromaprint1:amd64
libcomerr2:amd64
libcomerr2:i386
libdrm-amdgpu1:amd64
libdrm-amdgpu1:i386
libdrm-intel1:amd64
libdrm-intel1:i386
libdrm-nouveau2:amd64
libdrm-nouveau2:i386
libdrm-radeon1:amd64
libdrm-radeon1:i386
libdrm2:amd64
libdrm2:i386
libegl1-mesa:amd64
libfastjson4:amd64
libgbm1:amd64
libgdata-common
libgdata22:amd64
libgeoip1:amd64
libgettextpo-dev:amd64
libgettextpo0:amd64
libgl1-mesa-dri:amd64
libgl1-mesa-dri:i386
libgl1-mesa-glx:amd64
libgl1-mesa-glx:i386
libglapi-mesa:amd64
libglapi-mesa:i386
libgles1-mesa:amd64
libgles2-mesa:amd64
libglib2.0-0:amd64
libglib2.0-bin
libglib2.0-data
libgphoto2-6:amd64
libgphoto2-l10n
libgphoto2-port12:amd64
libjs-sphinxdoc
libllvm3.8:amd64
libllvm3.8:i386
liblognorm5:amd64
