Latest Debian Security Update Breaks Jessie (Resolved).

In addition to my Debian / Stretch computer, I still operate two Debian / Jessie computers. Those latter two computers were subscribed to the Debian Security repository, as well as to the standard Debian / Jessie repository. Unfortunately, the package manager on one of my Debian / Jessie computers had made me aware of a conflict which existed, due to an update which Debian Security is pushing, to a package and its related packages, all belonging to:

liqt4-dev

The version which Debian Security is trying to install is:

4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u2

But, the version which the rest of Debian / Jessie was using, was:

4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1

The problem was the fact that, if I told my package manager to go ahead with its suggested updates, doing so would have forced me to reject a long, long list of packages essential to my system, including many KDE-4-related packages. Now, I can just ignore that this problem exists, and rely on my package manager again not installing packages, that would break my system, on a daily basis. But this would turn into a very unsafe practice in the long run. And so, the only safe course of action for me currently seemed to be, to unsubscribe from Debian / Security instead.

(Update 17h55 : )

I have resubscribed to the Debian Security repository in question, and re-attempted the update, to find that this time, it worked. I can think of 2 possible reasons why it might not have worked the first time:

  1. My unattended-upgrades script is configured to break up an update into smaller pieces, and because this update involves a large number (over 20) of Qt 4 packages, this in itself could have broken the ability to perform the update, or
  2. Debian Security may not have put all the involved updates ‘out there’ on its servers, to be downloadable in one shot, even though every Qt 4 package needs to be updated, in order for any of the updates to succeed. But, only hours later, all the required packages may have become available (on the servers).

I rather think that it was due to reason (2) and not reason (1) above.

Dirk

 

Unattended Upgrades Resumed Running Normally Again, This Morning.

In This earlier posting only yesterday, I had written that for an unknown reason, my unattended upgrades not only did not run automatically, but that the responsible ‘cron.daily‘ script refused to run them, when invoked manually as root.

Well today, the unattended upgrades ran normally again, and also installed numerous updates. Routinely, without apparent errors.

Dirk

 

Unattended Upgrades Did Not Run This Morning.

I have had the strange experience, that this morning, for reasons unknown, my unattended upgrades system did not run, not even leaving an entry in any of its log files.

Additionally, running the script manually as root:

 


/etc/cron.daily/apt


 

Simply reproduces the behavior, of the updates not running.

But, I have noticed that This has happened to me once before. Strangely, the last time this happened was on March 14, 2016. This is usually around the time of year that Daylight Savings Time begins, and DST began this past Sunday, which was yesterday.

If this is somehow a DST bug, then I find it most strange, that it would not affect the Sunday in question, but the following Monday.

I will continue to monitor this problem. In 2016, the malfunction simply evaporated by the next day.

(Edit 03/14/2017 : )

Continue reading Unattended Upgrades Did Not Run This Morning.

Routine MySQL Update Successful Today

I use a system for updating my packages, which is named ‘unattended-upgrades’, and which I have blogged about before Here.

This morning, that system updated my MySQL server, which is also important to this blog, because these blog entries are in fact stored in a MySQL database. The way my blog generally works, each HTTP request causes a PHP script to be executed independently on the Apache server, and the PHP extensions I have installed, include a MySQL client. This part of the PHP scripts fetches the blog content, while other parts of the scripts format it as HTML, according to the Theme which I have chosen to install some time ago.

The individual blog entries do not actually form separate files or folders on my Web-site.

Also, it is an explicit WordPress Plug-In, which tries to retrieve the already-formed HTML from my server cache, If the HTML being requested has been cached. That Plug-In is named ‘Memcached Is Your Friend‘.

The fact that my blog still displays properly, indicates that the MySQL database is operating normally. After the upgrade, the scripts also restarted this server briefly. And, the fact that this server has been restarted, does not affect the cache, nor the speed of the blog, because the ‘memcached’ daemon is a separate process which did not receive any update or restart.

Dirk