So on my upgrade from Wheezy to Jessie, I found myself (amongst other issues) looking at a graphical interface where the mouse worked fine, but no mouse pointer was visible. After trying a few other things, it turned out that :-
gsettings set org.gnome.settings-daemon.plugins.cursor active false
Did the trick.
Of course that tip came from somewhere else, but as it worked for me, it’s worth making a note of.
I have recently been upgrading my Linux containers from Debian wheezy to jessie, and each time have encountered a problem preventing the container from booting. Or rather as it turns out, preventing the equivalent of init from starting any daemons. Which is systemd of course.
Now this is not some addition to the Great Systemd Debate (although my contribution to that debate may well arrive someday), but a simple fix, or at this stage a workaround (to use the dreaded ITIL phrase).
The fix is to re-install the traditional SystemV init package replacing the new systemd package. This can be done during the upgrade by running the following at the end of the usual process :-
apt-get install sysvinit-core
Of course you will probably be reading this after you have encountered the problem. There are probably many ways of dealing with the situation after you have tried rebooting and encountered this issue, but my choice is to run the following commands from what I tend to call the "global container" :-
chroot ${container root filesystem}
apt-get install sysvinit-core
As mentioned before, this is not a fix. And indeed the problem may be my own fault – perhaps it doesn't help having the "global container" still running wheezy. Perhaps there are some instructions in the Debian upgrade manual that details some extra step you should run. And of course by switching back to System V init, we are missing out on all of the systemd fun.
So for ages I've been having these mysterious slow downs in connecting to some of my internal servers. A few seconds, but once connected things are working normally.
And of course I kept putting off having a look into the problem, because firstly I'm lazy, secondly there are other more interesting things to look at, and thirdly I'd already discounted the obvious (actually I'd "fixed" it but made certain assumptions). But it's finally time to have a look.
Now I said I'd earlier discounted the obvious but decided to have a look any way. The thing to remember is that when you connect to a server it almost always performs a DNS lookup on your network address, so a mysterious slow down could well indicate that DNS resolution is to blame. You could perform diagnostics to determine what the problem is, but in all the decades I've been solving issues with computers whenever a mysterious slow down has occurred when connecting over the network, then the problem has almost always been the DNS resolver.
Taking a look at /etc/resolv.conf on the relevant server (a Linux container), and I find the file has a nameserver within it that was retired several weeks ago! Fixing that solved the issue.
Lessons learnt :-
So there I was, wandering down the street thinking about :-
And I thought that it would be fun to knock up a little application that would pop up a window and show a file. Then I got real, and realised that the application was already written and allowed fancy formatting of the help file(s) – it's called a browser.
Now for a whole bunch of reasons, you probably don't want to use a full blown browser, but something a little simpler and without any fancy controls, and I plumped for dillo. Turns out that the "-f" flag turns off the fancy menu and toolbar, so what I needed was to persuade my window manager (Awesome) to run it when I pressed "Help" :-
awful.key({ }, "Help", function () awful.util.spawn("dillo -f /home/mike/lib/help-files/index.html") end))
If you need help adding that to your Awesome configuration file, you're in the wrong place!
And of course it works :-
(And now of course I need to spend some time writing some help files!)
Undocumented command options … grrr!
Every so often I find that I have a need to put a volume label onto a FAT filesystem – usually so a digital camera SD (or CF) card can be "automatically" mounted (actually they don't mount automatically on my workstation and I like it like that) in the right place. And of course every time I do, I remember that the command to do so is mlabel but I cannot remember exactly how to do it.
Because mlabel (together with the other mtools) has some sort of weird configuration file to turn Unix/Linux paths into drive letters‽ And yes that was an interribang although it could just as well be some other form of punctuation to express disgust instead. As it happens mlabel has an undocumented option to specify a device path … at least it doesn't appear in the usage hints :-
» mlabel -h Mtools version 4.0.17, dated June 29th, 2011 Usage: mlabel [-vscVn] [-N serial] drive:
It turns out that there is a "-i" option which takes a device path, but you still have to specify the drive as "::" just so things are less likely to go right :-
» mlabel -i /dev/sdi1 :: Volume has no label Enter the new volume label : LEICA1
And there it is!