Some years ago I ran into a problem where, when starting my computer, I got thrown into a GRUB rescue command prompt instead of GRUB showing up and letting me choose which OS to boot in directly. I was running Debian 11 “Bullseye” (the stable version at that time) and this started happening after performing a dist-upgrade. Probably this “breakage” had something to do with me fiddling with my GRUB config sometime before the update and making changes that were incompatible with the new version of GRUB installed by the update (at least, that’s what I think may’ve happened as of today, though I may be completely wrong). In other words, I’m pretty sure it was my fault.

When this happened I had never seen a GRUB rescue prompt before, so I freaked out. It turns out that the problem wasn’t as bad as I first thought.

Initial fix

After the initial shock after upgrading my system, I had to find a way to fix this problem. I found a temporary solution: in order for my computer to boot up normally I just had to enter the series of commands

    set prefix=(hd0,gpt2)/boot/grub
    set root=(hd0,gpt2)
    insmod linux
    insmod normal
    normal

and my computer booted up perfectly fine. Let’s see what these commands actually mean.

• The set command, as described in the GNU GRUB Manual 2.06, lets us set the value of an environment variable. If invoked with no arguments, all environment variables and their values will be print out.

• The insmod command is used to insert dynamic GRUB modules (which we can understand as loading or activating them).

Therefore, the first two commands set the value of the prefix and root environment variables, defining the path to the GRUB directory and the bootable partition respectively.

Later on, the linux and normal modules are inserted. The linux module is a loader for Linux images, while normal provides us with “Normal Mode” (the opposite of “Rescue Mode”, the one in which we enter these commands).

Once these modules are loaded one can switch to “Normal Mode” by simply typing normal. Then, the usual GRUB menu, that I’m sure you’re familiar with, is shown (the one that lets you choose the OS you want to boot in).

Final solution

It was a very busy season, so I kept postponing finding a better and definitive solution to this problem and I had to enter these series of commands every time I had to boot.

One day I got tired and decided to find a better solution. It was quite simple. Once my computer booted up, I ran the commands shown in the previous section so I could start Debian and, once I was logged in into my user account, I simply ran ¹:

    # update-grub
    # grub-mkconfig -o /boot/grub/grub.cfg
    # grub-install /dev/sda

As described in the grub-mkconfig(8) manpage, by default the grub-mkconfig command prints the generated GRUB configuration file to stdout (standard output). The -o flag outputs the generated config to a file, so the path following that flag should correspond to the location were GRUB expects its config file to be (in my case it was /boot/grub/grub.cfg).

The command grub-install will install GRUB to a device. The path you specify must refer to a disk and not one of its partitions. Tools like lsblk can help you identify the disk path on which you should ask grub-install to install GRUB.

Resources and references

GNU GRUB Manual 2.06

Musings: GRUB2 Modules

grub-mkconfig Manpage

grub-install Manpage

lsblk Manpage

Introduction

I like to think of computers comparing them to houses. Buying new things for your house or upgrading the things you already own may seem the most straight-forward way to make your house a better place. Buying new furniture can help your house look more modern, prettier and improve your overall quality of life. Replacing old tools and household appliances for new ones may help you accomplish some tasks in a more efficient way. You get the idea. The same can be said about computers if we replace the terms ‘furniture’ and ‘household appliances’ for ‘software’ and/or ‘hardware’.

My point here is that, while of course a modern and new house can be really convenient and desirable, a clean and well-organized house should be a priority. It doesn’t matter how new and cool your house is and how many gadgets and fancy items you have in it if it isn’t clean and organized. The same happens with computers. For me, having a lot of tools or software installed and readily available but not even using half of it or keeping software you don’t use anymore, cluttering your system with no real purpose at all, is the equivalent of having a messy house with old stuff you’ll never touch again and with random items spread everywhere.

As with houses, with computers there’s a time of the year when one should really spend some time cleaning the mess that daily usage comes with. I’m not talking only about removing old files and programs we no longer use, but also removing the clutter that things like our package manager may’ve left behind when performing tasks such as a version update (or dist-upgrade).

Although this article is mainly focused on Debian (and Debian-based distributions) I’m sure you can find tools and commands that can be equivalent to any other Linux distribution.

Where should we start?

In the same way that happens when you’re spring cleaning your house, when you’re spring cleaning your computer you will regret not having the habit of doing it regularly, as it’d require much less work. So my first tip would be to have the habit of keeping your system clean, with only the things you need.

In the next few sections I’ll go over some of the commands you may want to use for cleaning up your Debian system. You can go through all of them when you feel like it, as there’s no wrong time for cleaning up your computer. However and as I said before, doing so before and after you perform a dist-upgrade (or a big upgrade in general) is highly recommended.

Before we start, I advise you to read carefully through the output of every command you type in the terminal, don’t just answer yes to every prompt and don’t blindly believe me on everything. Read the warnings and understand every command you type before confirming any action. I’m not responsible for the damage that your actions may cause to your machine(s).

First sweep through

The first and more basic thing one can think of when cleaning up a system is removing unused stuff, whether it is personal files or packages. If you want to free up some space in your computer and you have a ton of movies, TV series, games and music in your hard drive (legally downloaded, ofc ;) ) that you’ve already played and watched, that may be the first thing you need to check. For this task du and/or ncdu (a ncurses interface for du) may come in handy. They’ll show you how much space are your files taking up, so you can choose whether to remove them or not.

If you’re not a really organized person you may also have duplicated files in your computer. Maybe, when downloading stuff from the internet, you download the same document several times and forget to delete the duplicates, for example. In that case, please stop. But how do you clean the mess that you already have? Well, czkawka has got you covered. This program is, as described in its GitHub page, “a simple, fast and free app to remove unnecessary files from your computer”. It has a CLI version as well as a GUI one, which are quite intuitive. You may want to add this program to your set of tools for spring cleaning.

Czkawka (GitHub)

Okay, enough talk about personal files, what about system packages? The same logic applies. I recommend deleting everything you don’t need and/or don’t plan to use ever again. Ask yourself these questions: do I really need having all these desktop environments and/or window managers when I always log in to the same one? Do I really need all these pieces of software that I once installed to play around with and never used ever again? I’m not saying you should uninstall everything you don’t use on a daily basis, as you may want to keep some stuff that may come in handy when the time comes, but knowing what you have installed and why it is installed is always a good thing.

There are different approaches for tackling this problem. The first one, and the one that makes more sense if you’re desperate to free up some space, would be to have a list of all the packages currently installed (through apt) and sort them by the space they’re taking up. Once you have this list, you can start deleting packages you no longer need, starting with the big ones. This list can be obtained with this simple command:

    $ dpkg-query -Wf '${Installed-Size} ${Package}\n' | sort -rn

Another simple and clean option is using a Perl script called ds, written by Greg Wooledge, that does basically the same thing as the command shown above with the main difference that it won’t list anything that’s in state “deinstall” (“rc” on dpkg -l).

ds script

Greg’s Domain

Remove all that clutter

The easiest thing we can do to remove the clutter that the apt package manager may’ve stored in our hard drives, is the following:

    $ sudo apt autoremove --purge && sudo apt-get clean && sudo apt-get autoclean

The autoremove option is used to remove packages that were automatically installed to satisfy dependencies of a package that has since then been removed ¹ or has changed its dependencies. In case you want to keep some of these dependencies, mark them as manually installed with apt-mark.

The clean option, on the other hand, clears out the local repository of retrieved package files. On the other hand, autoclean only removes package files that can no longer be downloaded, and are largely useless. So maybe entering both commands, while not being harmful to your system, may be a bit repetitive.

By default, removing a package with remove or autoremove doesn’t delete its configuration file(s). In case you don’t plan on ever using again the programs you uninstall or just don’t want to keep the config files, purge is recommended. When using autoremove --purge unnecessary automatically installed packages will be purged (removed along with their configuration files).

In case you removed or auto-removed packages in the past without purging them, the following command should remove the remaining configuration files of programs that have been deleted:

    $ dpkg -l | grep '^rc' | awk '{print $2}' | xargs sudo apt-get -y purge

Before running the previous command you may want to take a look at the list of programs which are not installed but have remaining configuration files. This can be achieved by simply removing the command after the last pipe:

    $ dpkg -l | grep '^rc' | awk '{print $2}'

One could also go one step further and delete every package that was installed because another package recommended it but isn’t a dependency of any installed package. A list of all these packages can be obtained by typing:

    $ aptitude search '?and(?automatic(?reverse-recommends(?installed)), ?not(?automatic(?reverse-depends(?installed))))'

And in case you want to delete them all, you can do so by:

    $ aptitude search '?and( ?automatic(?reverse-recommends(?installed)), ?not(?automatic(?reverse-depends(?installed))) )' | awk '{ print $3 }' | xargs dpkg -P

An upgrade of a package may also bring some changes related to configuration files (deprecated settings, change of syntax, etc.). When apt notices this, it usually asks the user what to do: overwrite the old config file, backup the old config file and create a new one for the new version of the package or do nothing. Usually, the user will want to keep the custom config file that he had before the upgrade until he can adapt it to work with new version, so the second option is chosen most of the times. Once the user has modified and tweaked the new configuration file, keeping a backup of an older version makes little to no sense. To avoid confusion one may want to delete these leftover files, along with versions supplied by the package maintainers and other unused copies. These leftover files can be found with:

    $ sudo find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'

Orphaned packages

A very popular tool for cleaning up your system is deborphan. deborphan searches for packages that have no other packages depending on them and were installed as a dependency or recommendation for a package no longer present on the system. When executing deborphan with no additional flags, a list of packages will be printed to stdout. Once you’re sure you can remove all of them, you can do so by typing:

    $ deborphan | xargs sudo apt-get purge -y

One could also add the --guess-all flag to deborphan, to make it try to figure which packages are of little to no use to you by examining the package’s name and description. You must be really careful when using this flag and I only recommend it if you really know what you’re doing. Please, read the package list outputted by deborphan before piping it to apt-get purge.

Obsolete packages

The apt-show-versions utility lists the versions of the packages present on your distro. In a similar way that aptitude versions, but with in a more convenient way for our use case.

By entering apt-show-versions in a shell prompt, a list of all the currently installed packages will be printed out. Note that this only includes packages installed with the apt package manager (or aptitude or nala), and not things like snaps or flatpaks. A sample of this output could be something like:

    ...
    sbcl:amd64/bullseye 2:2.1.1-2 uptodate
    sbcl:i386 not installed
    screenkey:all/bullseye 1:1.4-2 uptodate
    sed:amd64/bullseye 4.7-1 uptodate
    sed:i386 not installed
    sensible-utils:all/bullseye 0.0.14 uptodate
    sent:amd64/bullseye 1-3+b1 uptodate
    sent:i386 not installed
    ...

We can then see that the list is formatted in a specific way that we can take advantage of.

    [name of the package]:[architecture]/[distribution] [package version] [updates]

Where [updates] simply checks if the package is or isn’t on the latest version available in the Debian repos corresponding to the current Debian version that the system is running.

There’s a series of packages that display their info in a different way. This includes packages that were installed by a .deb file downloaded from the internet, packages installed from apt sources that are no longer available (they no longer figure in /etc/apt/sources.list nor /etc/apt/sources.list.d/) and packages from previous Debian versions that have changed their name in more recent ones and haven’t been replaced, leaving the two versions, which apt interprets as two different packages, coexisting. In other words these are packages that Debian can’t find in their repositories or the ones you may’ve added in /etc/apt/sources.list. An example could be:

    linux-image-4.19.0-21-amd64:amd64 4.19.249-2 installed: No available version in archive

This package corresponds to the latest kernel version I used before updating to Debian 11. Right now I’m using version 5.10.0-19 (the latest one available in Debian stable as of now), but this package wasn’t removed. We can get a list of all the packages that Debian can’t find a list for with:

    $ apt-show-versions | grep 'No available'

After taking a look at the listed packages you may want to remove some of them manually. In case you’d like to remove all of them, something like this should work for the example using apt-show-versions:

    $ apt-show-versions | grep 'No available' | awk -F' ' '{ print $1}' | xargs sudo apt-get purge -y

If you prefer not to use apt-show-versions, a similar (or nearly identical) list can be obtained with:

    $ aptitude search '~o'

This will search for packages marked as “obsolete” by the aptitude.

Non-Debian packages

Now let’s imagine you installed a bunch of software from third party repositories that you may want to uninstall now. Maybe you installed a ton of packages from .deb files downloaded from sketchy websites or added a bunch of entries to your sources.list that you no longer want to have. First of, let me tell you that was a bad idea and that you should always install software through your distro package manager and from the official repos when possible. Once that’s been said, you could try and list all the installed packages that didn’t come from the official Debian repository.

The Debian 11 release notes suggests two different commands to do exactly that.

    $ aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

This will also include packages that were once provided by Debian but no longer are (e.g. old kernel packages).

The other option is using apt-forktracer, a utility for managing package versions.

    $ apt-forktracer | sort

Transitional dummy packages

Transitional dummy packages are meant to simplify the transition when a package is renamed. If a package called package-old is renamed to package-newfrom a release to another, without a transitional package, the package manager will treat package-new as a completely different program than package-old and not its newer version. User users who already had package-old installed won’t receive any updates, as the package manager does not see the relation between package-old and package-new.

Transitional packages try to prevent this kind of behaviour. The package maintainer just needs to create a transitional package called package-old without any files nor contents that has package-new as its only dependency. By doing this, if someone updates package-old it will update to this transitional package and, therefore, package-new will be installed as a requirement. These empty packages (containing only metadata) whose sole purpose is to install other packages by having them as a requirement are also referred to as “meta packages”.

These transitional dummy packages are, most of the times, useless once the name change has been done (i.e. the transition has been completed), so we can remove them.

One can see the dummy packages present in its system by doing:

    $ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Alternatively, one can use deborphan:

    $ deborphan --guess-dummy

Take into account that, as the deborphan(1) man page states, these guess flags for deborphan are not perfect, so be extremely cautious when deleting some of the packages listed in there.

Final notes

These would be some of the things I’d do in order to clean up a bit a Debian system. Sometimes less is more and having a clean system with only the things you need is key administrate it in the most efficient way.

If you have any suggestions, corrections and/or comments you’d like to send me, feel free to email them to me.

Resources and references

The Debian Administrator’s Handbook - Section 6.7

Debian 11 Release Notes - Section 4.2

Debian Bug report logs - #987017

Man pages of all the software mentioned.

Introduction

The year was 2012 when I got my first my computer.

It was an Ahtec laptop which had quite some good specs for that time and considering how much it had cost. The laptop came with an Nvidia GeForce GT 525M graphics card, which performed way better that I could’ve ever dreamed of (once the propietary Nvidia drivers where installed, of course).

One may wonder why buy this laptop when probably there where much better options out there and why go for a lesser known laptop brand and not buy an HP, Toshiba, Dell or a Lenovo ThinkPad. Well, mostly because of money, but also because it was the only one at my local store which came with no OS installed by default, which meant there wasn’t a need to pay for a Windows license.

Also, by that time, I wasn’t using Windows anymore. In fact, I never really got to use Windows on a daily basis, as when I was young we didn’t have a computer at home and, when we finally got one, we changed its OS from Windows XP to Debian 5 (or maybe it was 4?) just a few months later because of how incredibly slow it Windows XP was. Debian gave our PC a new life. I’ve been a Debian guy ever since. This time wasn’t going to be different, so I installed Debian on my new laptop and, to no one’s surprise, it worked like a charm.

I’ve been using Debian for most of my linux years. I don’t know why but I’ve always felt that the robust feeling the distro gives me makes me feel at home. Not a lot of other distros make me feel like that. Debian is a hell of a solid linux distribution and I’ve only experienced a few major breakages over the years (and they have all been my fault). For some time I went back and forth switching between the “stable” and “testing” branches until finally just stayed on the stable one, as I don’t really need a lot of new packages (and those that I do need I can compile from source).

I never felt the need to switch away from Debian, but out of curiosity and after seeing other people’s opinion and different approaches about what a linux distro should and should not be, I decided to go and test some other distros. I played with Ubuntu, Void Linux, ArchLabs and even ditched Linux for some time to try some of the BSDs, only to come back to Debian.

systemd a.k.a The Antichrist

During my time learning and tinkering with linux, I got to try and see different approaches on software development in general. My love for minimalism grew through the years and I tried to replace most of my software with more minimalist options when it was possible. I moved from away from full blown DEs (such as GNOME and KDE) to standalone window managers (such as Openbox, CWM, XMonad, etc.) and started using more terminal-based applications. I found this new workflow to be more convinient for most of my use cases.

Some may argue that, when looking for minimalism, another distribution would’ve made much more sense than Debian. There’s Arch, Void, Gentoo, CRUX or even KISS Linux, to name a few, which let you build your OS from the ground up so you only keep whatever packages you choose to, achieving “peak minimalism”. Although I love Void and Gentoo and CRUX are distros I’d love to try on physical hardware one day, a similar (yet not quite the same) “build it from the ground” experience can be also achieved in Debian by unticking all the boxes refering to desktop environments in the “Software selection” step in the netinst installer, leaving only the base system ¹.

With all this minimalism thing swirling around in my head I eventually came across Suckless’ software. I instantly loved dmenu, slock and some other tools by them ² and I eventually found their opinions on different software and their opinion on systemd.

Suckless’ opinion on systemd

At that time, there were some linux related topics I still didn’t have a deep understanding of, being init systems one of them. Reading so much people complaining about systemd and talking about other init systems was the perfect excuse to start learning about init systems, investigate alternatives to systemd and to really consider if it was really that bad and if I should care at all about it being a giant peace of bloatware trying to do too much and not giving a single shit about the Unix philosophy ³.

The “No systemd” website came in handy to answer some questions, providing links to others people’s opinions and/or arguments against the init system, as well as a list of some Non-systemd distributions.

No systemd website

Another useful resource when talking about init systems and get some a basic idea of them all is the page in the Gentoo Wiki dedicated to comparing a handful of them.

Comparison of init systems (Gentoo Wiki)

So, after reading all those pages, did I get any conclusion? Well, not really. I don’t like basing my opinions solely on other people’s and I prefer to investigate the topics to form my own. This time wasn’t an exception.

What about Devuan?

A year or so ago, I tried out Void Linux on my laptop, which performed quite well. Void comes with the runit init system, so I thought it was time to give runit another try and get to know the deep-down essence of it.

In contrast to systemd, runit is designed as a minimal init system with the Unix philosphy in mind of “do one thing and do it well”. It actually is a collection of six utilities, each one of them designed to perform an specific task.

At that time my laptop was running NetBSD, as I had wanted to tinker with that OS for a long time, but I replaced it with Devuan 4 with the runit init system. I was going to use this laptop for doing actual work which involved programming, compiling and executing code written in Fortran used to solve integrals via numeric methods as well as studying physical models with methods such as the Metropolis Algorithm. These type of programs may take a lot of time and system resources when executing, so it was a must for the computer to be performant and usable and for the OS/distro to just “get out of the way”. I thought that Devuan would be the perfect field to try runit in, as I was already very familiar with Debian-based distros and I would need to spend much time setting the system up and learning its ins and outs.

Devuan is basically Debian without systemd, so software availability and hardware support is as good as it can get. Nvidia propietary drivers are available and easy to install and overall performance is great.

Announcement of the Debian Fork (devuan.org)

One of the most interesting aspects of Devuan is the so called “init freedom” approach they give. Considering that the users should have the freedom to choose whichever init system they prefer.

Init freedom (devuan.org)

Conclusions and final thoughts

Then, does the init system really matter? Does it make a change performance-wise?

Well I’d say that the importance of the init system depends on who you ask and what they use their computer for. In case you want to build a career around Linux (in which you’ll need to work with different machines etc.), you may want to know systemd really well, as it has become a sort of “standard”. Most of the machines you’ll encounter in these jobs will probably run systemd distros. These include RHEL (since version 7), Debian (since version 8), Ubuntu (since 15.04), Fedora (15+) and others.

On the other hand, if you’re just a hobbyist computer user that likes to tweak with this sort of things, I’d say give one of the alternative init systems a go. Who knows if you’ll end up prefering it.

I honestly consider runit to be a better init system than systemd. I think runit is way superior, not only because it follows the Unix philosophy (although I think that is something that needs to be taken into account), but also because its size makes it quite faster than most other init systems out there and also more suitable for old hardware.

Some weeks ago, I saw a video of a linux youtuber somewhere on the internet where he said that, since he started getting familiarized with Unix-like operating systems, his computer usage has been progressing towards using the system in a more “low-level way”. That means throwing away GUI apps for CLI alternatives and using more minimalist software that just gets to the point of whatever you want to do and gives you more control on how to do it. I feel that, unintentionally, I’ve followed a similar path. Why is that? Well I’d say that, in my case, when using my computer this way, I can better understand how everything works. And I think this point is key when stating that runit may be preferable to something like systemd: its size makes it easy to understand and learn in a couple of hours.

I don’t think I’ll be moving from Devuan any time soon. I might even switch to Devuan in my main production machine, which has been running Debian for a couple of years now, when I have some time.

Resources and references

Other links you may wan’t to check if you’re thinking about moving away from systemd or simply want to know more about why people hate it:

Inferencium Network: systemd insecurity

Lanodan’s Cyber-Home: SystemD eated su

Benno Rice: The Tragedy of systemd – BSDCan 2018