You should "pin" backports, i.e., add a file "reluctant-backports" with the following into /etc/apt/preferences.d

Package: *
Pin: release a=ascii-backports
Pin-Priority: 100

With that, apt will not upgrade to backports versions of packages unless you ask for them explicitly.

The "-t ascii-backports" argument opens it up a little, so that the nominated package and its dependents get pulled from backports, but nothing else.

Later on, without "-t ascii-backports", only packages already from backports will be upgraded from backports.

There's a long and sad story about udev versions here. The more recent version has the name scrambling as a net_id "builtin", and basically, preservation of sanity requires the boot command line to include

net.ifnames=0

With that, your network interfaces supposedly are left as named by the kernel modules, i.e., the eth adapter that is quickest to register is named eth0, the next one eth1 and so on.

Perhaps you have two examples of namings at two different reboots? E.g., a blkid snap of each? And it probably wouldn't hurt to see an lspci snap as well. (I'm not sure; not really my forte, but I'm guessing what would be useful background info)

With /etc/fstab you assign block devices to mount points, and there you have a few different ways to refer to the block devices, where I think using labels or UUID are the reliable approaches if your hardware is moody. In my experience, most hardware is not moody, and I do well in using the /dev points for identification. But it sounds like that doesn't work for you.

I wouldn't think of using udev to dream up identifications, since it's merely concerned with making sure there are /dev points for the partitions, unless for some reason you want to insist that a partition of a certain label (or UUID) also end up at a certain /dev point. If it works correctly, udev should also be setting up identification mapping for label and UUID and whatnot to the associated /dev.

There are "wheels" of many colours for this ufw isn't too bad although it does introduce a (confusion?) layer between the ufw rules and the actual iptables rules. But I'm sure you'll easily find proponents talking more warmly about ufw.

I'm happy with raw iptables, so I install and use the iptables-persistent package.

Not really. Of course, for those kiddies, the "word" iptables has got the extra meaning of being the name of a service in addition to being the program for manipulating the kernel tables.

By the looks of it, "python" doesn't make use of the "alternatives" set up, but have /usr/bin/python as a link (to python2.7). You might change that but that could have severe ramifications, because there are more than a few system programs using python, and these may well expect and/or utilize python2.7.

A safer way could be to patch it only for yourself (and not root), e.g., by having $HOME/bin early in your $PATH, and make $HOME/bin/python a link to /usr/bin/python3. That will be an override for the user but not for root.

I suppose one could squeeze in a small search field at the top right somewhere... or maybe with themed placement (and looks). It's added to the list; somewhere above "Swedish localization" :-)

Good script.

One (small) remaining problem would be that it's still a script and not a binary; it relies on a pre-installed interpreter (bash), and is thus not fully self contained. Of course, that's not much of a problem except for those who take offence to installing bash, and those who wants a suid program.

But if you want that covered as well, you could write up that header function in C (probably with some minor variation to the separation logic), and then pack such a binary in front of a tar to make a binary, self-executable tar. The point being that you can concatenate anything to a binary executable without that destroying it.

(Or, rather than C, you could use newlisp, which in fact includes an embedding method similar to this.)

On the other hand, as a binary, it'll instead be sensitive to the architecture, and thus less universally distributable -- swings and carousels.

Could you be specific, please. Is it that you cannot start the keyboard over slim? or that it comes up but its input is not delivered to slim's login box? Or something else. Please include any error responses of any commands that your try.

Someone on a not dissimilar platform had success with the problem in 2009:
https://ubuntuforums.org/showthread.php … 455&page=2
The key was to "also disable loading lp module in default configuration of cups in /etc/default/cups".

sometime a sleep 1 beforehand makes wonders

Just picking up the smallest of your crumbs:

which could provide a similar layout separation as a code block, though not scrolling.

As for network interface re-naming, I can't offer anything not already said. Basically it's a udev thingy, and (stupid as it is, one might think), one of those warts that come with the "modern" and "improved" wheel. Slightly easier to fix than rid yourself of avahi and gvfs and packaged and uuidd and whatnot, I think.

I liked post #19 though; it was short and succinct, and its mere presence so elegantly violated its own sentiment.