[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#849382: marked as done ([apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.)

Your message dated Sat, 28 Jan 2017 08:53:16 +0100
with message-id <20170128075316.ppwoxozp6hu7h4g4@crossbow>
and subject line Re: Bug#849382: [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.
has caused the Debian Bug report #849382,
regarding [apt] Every package on the system gets silently upgraded to backports. The result is severe system breakage, malfunctioning and data loss.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
849382: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849382
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---

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
libmediaart-2.0-0:amd64
libmtp-common
libmtp-runtime
libmtp9:amd64
libmysqlclient18:amd64
libnet-dbus-perl
libnss-myhostname:amd64
libpam-systemd:amd64
libpcap0.8:amd64
libpostproc54:amd64
libpulse-mainloop-glib0:amd64
libpulse0:amd64
libpulsedsp:amd64
libreoffice
libreoffice-avmedia-backend-gstreamer
libreoffice-base
libreoffice-base-core
libreoffice-base-drivers
libreoffice-calc
libreoffice-common
libreoffice-core
libreoffice-draw
libreoffice-evolution
libreoffice-gnome
libreoffice-help-en-us
libreoffice-impress
libreoffice-java-common
libreoffice-math
libreoffice-report-builder-bin
libreoffice-sdbc-hsqldb
libreoffice-style-galaxy
libreoffice-style-tango
libreoffice-writer
librygel-core-2.6-2
librygel-renderer-2.6-2
librygel-renderer-gst-2.6-2
librygel-server-2.6-2
libseccomp2:amd64
libss2:amd64
libssl1.0.0:amd64
libswresample2:amd64
libswscale4:amd64
libsystemd0:amd64
libudev1:amd64
libudev1:i386
libva-drm1:amd64
libva-x11-1:amd64
libva1:amd64
libvdpau1:amd64
libwayland-egl1-mesa:amd64
libwine:amd64
libx265-87:amd64
libxapian22:amd64
libxatracker2:amd64
libxnvctrl0:amd64
linux-base
linux-image-4.7.0-0.bpo.1-amd64
linux-image-amd64
linux-libc-dev:amd64
manpages
manpages-dev
mysql-common
openssl
pinentry-gtk2
pulseaudio
pulseaudio-module-x11
pulseaudio-utils
python-axolotl
python-axolotl-curve25519
python-cffi-backend
python-cryptography
python-dateutil
python-debianbts
python-dnspython
python-idna
python-ipaddress
python-openssl
python-pil:amd64
python-pkg-resources
python-psutil
python-pyasn1
python-pygments
python-pysimplesoap
python-routes
python-serial
python-setuptools
python-six
python-twisted
python-twisted-bin
python-twisted-core
python-webob
python3-brlapi
python3-pkg-resources
python3-six
python3-uno
rsyslog
rygel
rygel-playbin
rygel-tracker
shared-mime-info
systemd
systemd-sysv
tar
tor
tor-geoipdb
torbrowser-launcher
torsocks
udev
uno-libs3
unoconv
ure
usb-modeswitch
usb-modeswitch-data
va-driver-all:amd64
vdpau-va-driver:amd64
wine
wine64
xbrlapi
xserver-xorg-video-intel


--- System information. ---
Architecture: amd64
Kernel:       Linux 4.7.0-0.bpo.1-amd64

Debian Release: 8.6
  500 unstable        ftp.gajim.org
  500 unstable        download.jitsi.org
  500 stable-updates  ftp.pl.debian.org
  500 stable          security.debian.org
  500 stable          ftp.pl.debian.org
  100 jessie-backports ftp.pl.debian.org

--- Package information. ---
Depends                         (Version) | Installed
=========================================-+-===============
libapt-pkg4.12             (>= 1.0.9.8.2) | 1.0.9.8.4
libc6                           (>= 2.15) |
libgcc1                      (>= 1:4.1.1) |
libstdc++6                       (>= 4.9) |
debian-archive-keyring                    |
gnupg                                     |


Package's Recommends field is empty.

Suggests         (Version) | Installed
==========================-+-============
aptitude                   |
 OR synaptic               | 0.81.2
 OR wajig                  |
dpkg-dev       (>= 1.17.2) |
apt-doc                    |
python-apt                 | 0.9.3.12



--- Output from package bug script ---

--- End Message ---
--- Begin Message --- 
Version: 1.1

On Sat, Jan 07, 2017 at 09:42:01PM +0100, Sven Hartge wrote:
> 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) <34tg535@tutanota.com> wrote:
> > 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.

Due to how the 'update' process was coded there were cases in which the
failure in one repository would influence the action taken for another
– or rather non-action. The details of the code are more than a bit mind
boggling with various file renames (not) happening which can result in
this problem reported here if you are unlucky.

The solution taken was to basically rework that entirely over the last
few years while keeping it backward compatible (which means its still
not nice…), but at least signed repositories are first-class citizen now
(the old code was written before repositories could be signed and then
retrofitted with support for it) and all files belonging to one
repository transition together to their new place fixing the whole
problem class reported here and hence I mark the bug accordingly.

As you might guess, entire rewrites are unacceptable for stable updates,
so the bug remains open for apt < 1.1 and given the (not) available
manpower I seriously doubt anyone will work on changing that – your best
option if you are effected is hence to upgrade to stretch early on.

This or similar might be helpful in a workaround (which can't be done
globally as some people depend on apt not failing on warnings…):
---
if [ -n "$(apt-get update -qq 2>&1)" ]; then
	exit 112
fi
---

That said, it is always a good idea to apply sanity checks to a solution
apt proposes as it isn't and can't be perfect. There is a reason it asks
for confirmation of the solution after all…


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: