Whether It Is Easy To Debian-ize A Kanotix Installation

One question which people often ask me, is “What is the advantage of Kanotix over Debian?” Kanotix is in fact a Debian-based distribution, but has been bundled to include advantages over straight Debian, including the ease with which certain features recognize our hardware and install.

The next question people typically ask me is, “Suppose I had installed Kanotix. What would I do if I no longer want it to be Kanotix, but rather want to revert it to a standard Debian installation?”

The answer to that question is twofold. Firstly, it is easy to remove the specific Kanotix repositories from our Debian Sources list, which ‘apt-get’ queries, to download packages. But there is a slightly more subtle side to this question, which is best answered with a concrete example.

As an example, Kanotix / Spitfire, which is based on Debian / Jessie, currently comes with LibreOffice 5.1.3.2-2. I just updated mine tonight. This differs from standard Debian / Jessie, which is only supposed to come with LibreOffice 4.4.4.3-3. The LibreOffice version that comes with Kanotix works 100%, even though it is a higher version number than what is standard.

But from time to time, both the Kanotix distribution and the Debian distribution will update the LibreOffice version we have installed, either way. This could be because certain security-related flaws have been discovered, as if we had not heard of enough zero-days yet. But if what we had was Kanotix, and if we had installed the version of LibreOffice that it offers as an advantage, then the version number would stay at 5.1.3.2-2 in my case. Any subsequent, incremental updates to LibreOffice, which standard Debian had to offer, would come as slight version increases over 4.4.3-3 – for example, standard Debian might come up with a LibreOffice 4.4.4.4 . In this case our problem would be, that our package manager would see that we have version 5.1.3.2-2 installed, and would not offer us the (slightly newer) version 4.4.4.4 , because that updated version would still be lower, than 5.1.3… So our version would stay frozen for some time, at least until the Debian team started to publish a version higher than 5.1.3.2-2 . Which would be, effectively never for Debian 8.

So in order really to get Kanotix off our system, we would next also have to uninstall LibreOffice 5.1.3.2-2 completely, which consists of numerous packages. And then we could reinstall OpenOffice 4.4.3-3 from the standard Debian repositories.

Doing so might also mean, that we had LibreOffice documents in our home partitions (user data), which happened to take advantage of LibreOffice 5.1.3 features, and which LibreOffice 4.4.3-3 does not know how to display correctly… And so what some of us might do, is just keep the LibreOffice version installed, that was once installed.

Something similar happens with VirtualBox, which is a GUI-oriented Virtual Machine, on which some of us will install Windows… Kanotix bundles a version of it, which combines all the features in one package, that package being of a higher version-number than standard Debian. Standard Debian will publish VirtualBox as a set of packages, but typically with a lower version number. In theory, the question could be more urgent here, of having to revert the version to the standard Debian version, before we install our virtual Windows, because major version mismatches here can stop our “Guest Machine” (that again being user data in its entirety) from running outright.

Dirk

 

Chrome For Linux Upgrade Glitch Fixed By Google

One of the facts which I had observed about the Google Chrome browser version, which is meant for Linux, was that Google no longer provides a 32-bit version of its binaries. In keeping with this, Google has also removed the section in its code repository, which would make a 32-bit version available. Hence, I can only be subscribing to the 64-bit upgrades. Yet, my Linux computer ‘Phoenix’ has its package manager set up, to query a repository for both the 64-bit and the 32-bit versions of any package by default, and then to download and install the packages which are relevant.

In this earlier posting, I observed how this can lead to an error message when running ‘apt-get update‘. What I had done, was to make minor configuration changes like so, which I had needed to re-apply, after every upgrade to Chrome.

Well Google has caught up with the scenario which I was describing. As of their latest upgrade, their own ‘cron.daily‘ symlink will properly put the following source into ‘/etc/apt/sources.list.d/google-chrome.list‘ :


deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

You may note, that the script from Google now includes the ‘[arch=amd64]‘ parameter, which means that I won’t have to make any manual adjustments to this configuration detail of my machine, every time the Chrome browser receives an upgrade.

Thank you, Google!

Dirk

 

Unattended Upgrades Did Not Run This Morning.

I previously wrote about the Debian package ‘unattended-upgrades’ Here. This morning however, this system did not install any upgrades, almost as if it had not run. Yet, I found no changes to any of the relevant configuration files. But I do have a tentative explanation as to why, maybe, this package did not run as usual.

When I prompted my KDE desktop tool to do the pending upgrades – that tool having been named “Tasker” in some versions of KDE, it showed that there was an upgrade pending for the package “Wireshark”. What I dimly seem to recall, is that the previous version of Wireshark had a severe bug. It is entirely possible that the unattended upgrades did not run this time, because I also have installed ‘apt-listbugs’.

If this supposition was true, then today would have been the first demonstration, of how this package will prevent an unattended upgrade from running. If true, this would come as a relief, because I previously had the fear that although this package would prevent a potentially damaging upgrade, it might also corrupt the state of ‘apt-get’. Apparently it will not. Let us keep our fingers crossed.

Dirk

 

Choosing dist-upgrade Over upgrade

Under Linux, the command

apt-get update

Is safe, and only refreshes the packages list stored on the client, to reflect changes that have been made in the repository. OTOH,

apt-get upgrade

Tells the package manager, simply to upgrade all packages, which have newer versions in the lists, from the versions currently installed. In principle, this sounds logically correct. But there is an alternative to this, which is called

apt-get dist-upgrade

The difference is, that ‘dist-upgrade’ is smarter than ‘upgrade‘ about global changes that might take place, due to changes in the overall Debian Distribution – hence the ‘dist’ – which can affect which directories files and configuration changes need to be stored to.

In practice, ‘d-u’ is always safer than just ‘upgrade‘, and does everything ‘upgrade’ is supposed to do. Therefore, we generally give the command

apt-get dist-upgrade

Dirk