Debian – Why are some packages not available in the Debian Jessie installation

[Note: the solution was discovered in the Update 2 data, and explained at the bottom, apt pinning.]

Diagnosing this issue requires determining where the failure is happening.

First, try this, it appears that something is wrong in terms of your sources, so just replace them with these, then debug backwards once you have a working setup again:

https://packages.debian.org/search?keywords=mysql-client&searchon=names&suite=oldstable&section=all

Exact hits Package mysql-client

jessie (oldstable) (database): MySQL database client (metapackage depending on the latest version)
5.5.57-0+deb8u1 [security]: all
also provided by: mysql-client-5.5

Other hits Package mysql-client-5.5

jessie (oldstable) (database): MySQL database client binaries
5.5.57-0+deb8u1 [security]: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x

This shows the packages in question are in old stable. Change your sources.list to this:

#deb http://ftp.de.debian.org/debian/ jessie main contrib non-free
#deb http://security.debian.org/ jessie/updates main contrib non-free
#deb http://ftp.de.debian.org/debian/ jessie-updates main contrib non-free
# try these instead:
deb http://mirrors.kernel.org/debian jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
# and your wine repo
deb https://dl.winehq.org/wine-builds/debian/ jessie main

Save, then: apt-get update

Then: apt-cache search mysql

If this does not now show your mysql-client, I believe something very difficult to debug is corrupted in your system.

Also, show in the full results of: apt-get update not just the last line, the entire thing, that may show errors you are missing.

You can also always check what your local apt knows, with something like this:

apt-cache show mysql-client

and carefully examine the output.

also: apt-cache policy mysql-client

It's clear that your apt update is failing to update for whatever reason, I suggest the above change of repos to remove some variables from the question.

[Updated] Note, I corrected a line in sources.list update yours, but your paste shows that was the only item failing, which means your primary jessie main contrib non-free local database is not for some reason updating correctly.

Modify the sources.list, run apt-get update again, and look for errors again. It's clear your apt package database is failing to update.

[Update 2] If apt-get update is working and not showing errors, and if you see the end result: 18.9 MB updated which your paste does show in the end, this strongly suggests that the issue is a failure to write the data to disk, in a way that apt itself is not able to be aware of in order to show error messages due to that failure.

Check: dmesg | grep apt-get for any error messages as well. Check the system with df -hT to make sure the /var partition apt is writing the update data to is not full. Run a fsck on the partition that contains /var.

Note that reinstalling will not fix hardware failures, so it's probably a better idea to figure out why it's failing than to reinstall hoping that will resolve the issues.

Did anything or anyone change the permissions of the apt database?

Check the following (note in particular the size of the files):

ls -l /var/cache/apt
# the results should look like this:
drwxr-xr-x 3 root root   147456 Jul 22 16:50 archives
-rw-r--r-- 1 root root 32808269 Aug 13 16:15 pkgcache.bin
-rw-r--r-- 1 root root 32088021 Aug 13 16:15 srcpkgcache.bin

Further, the last modified date should change every time you run apt-get update.

Further checks:

ls -l /var/lib/apt/lists/

should show all your repos and their associated data that was grabbed from apt-get update, or in your case, apparently grabbed but not updated.

Repeat the search: apt-cache search mysql-client which should either show nothing, as was your case until now, or it should show something.

Next: check that you have not set apt preferences to use a previous distribution or some other unremembered event in /etc/apt:

cd /etc/apt
cat apt.conf apt.conf.d/* preferences preferences.d/*

This should return any configurations set in those files (for example):

APT::Default-Release "buster";
APT::Get::AutomaticRemove "0";
APT::Get::HideAutoRemove "1";

[UPDATE 3 - Solved?]

And the user configurations from the /etc/apt cat above show the problem, which was obvious as soon as I saw it, but not obvious to guess, though the hint of running Jessie, old stable, after new stable, Stretch, was released should have been enough to check the pinning without the other tests:

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt || true";};
Package: *
Pin: release a=stable [***** my emphasis]
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10
cat: preferences.d/*: No such file or directory

Now it makes sense, no technical issues, no hardware issues, yet apt is showing no packages. Why? Because your system is pinned to stable, which is stretch, not jessie.

Change the pinning, first locate the file that has that pinning in it:

grep -snR 'Pin: release a=stable' /etc/apt

Then change 'stable' to 'jessie' and everything should work again.

Except I believe you need to change it to (note the n instead of a, n is the name of the release):

Pin: release n=jessie

And maybe add in /etc/apt/apt.conf this line, though I don't believe it's necessary in your case.

APT::Default-Release "jessie";

https://manpages.debian.org/stretch/apt/apt_preferences.5.en.html

Note that jessie I don't believe had all the .d directories yet, so it's hard to remember where its files should go, probably in the .d/ directories will work fine.

The Default-Release is set in: /etc/apt/apt.conf.d/80Basics The Pinning is in: /etc/apt/preferences.d/80Basics In your case, the pinnning is in /etc/apt/preferences

Basically you told apt to pin to stable, and it dutifully is doing what you told it to do, only you don't have stable in your sources, you have what is now old stable. So apt when you ask it about packages, dutifully informs, after you update jessie sources, that there are basically no packages to be found. No errors are reported because no error occurred, the update worked fine, the package database was updated fine, the package lists all updated, but sadly, none of them contain stretch (stable) data. That's the risk of using 'stable' instead of the actual distribution name in that, it's very easy to forget you did it, and even more confusing when stable changes to old stable, or EOL stable. Note that generally you can use sid/testing/stable in your sources, but I've found that those can fail at times when testing rolls to new testing, and stable becomes old stable, so the actual names are my preferences except of course for sid, which never changes.

I believe this is the solution, as you can see, reinstalling is almost never the solution, and I was increasingly beginning to suspect you had something configured somewhere that you'd forgotten about, since everything is working, apparently.

I believe that pinning is going to be in /etc/apt/preferences (since preferences.d didn't exist in your jessie).

APT PINNING: https://wiki.debian.org/AptPreferences

As a a result, I use a more conservative "only if I say so" approach to a mixed distribution, with a Pin file like this:

Package: * Pin: release a=testing Pin-Priority: 900

Package: * Pin: release o=Debian Pin-Priority: -10

Thus all debian packages are defaulted to priority -10, while testing receives a 900 point bonus. This invokes the behaviors:

From apt_preferences(5)

500 < P <=990 : causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent [...] P < 0 : prevents the version from being installed

[...]

P < 0 : prevents the version from being installed

As you can see, you told apt to basically ignore everything that is not stable (-10), and to only use stable (900), so apt did what you told it to do.

Given this was a stable, not sid or testing installation, I wouldn't in general use that -10 pinning, I'd use something like 100 or 200. But I'd only use pinning if I was actually running various pools, like stretch and jessie, or sid and testing, there's no point beyond confusing yourself to using it if you are only using Jessie, and even then, apt basically ignores the pinning and uses the Default-Release anyway now, for example, I have my testing pinned to 900, but set to default release, so apt-cache policy show this:

apt-cache policy nano
nano:
  Installed: 2.7.4-1
  Candidate: 2.8.6-1
  Version table:
     2.8.6-2 300
        300 http://mirrors.kernel.org/debian unstable/main i386 Packages
     2.8.6-1 990
        990 http://mirrors.kernel.org/debian buster/main i386 Packages
 *** 2.7.4-1 100
        100 /var/lib/dpkg/status

As you can see, the pinning value is 990, which isn't something I did, it's something apt does when you declare the default-release explicitly.

https://manpages.debian.org/stretch/apt/apt_preferences.5.en.html

The stretch man page for preferences is pretty clear.