Feb 122024
 

So two days ago, I upgraded my main workstation to Ubuntu 23.10; a few little issues (mostly related to my own scripts), but nothing serious. Yet.

On the following day, my smart TV box started misbehaving. It couldn’t see any of the videos NFS mounted from my workstation, ITVX threw up a website error (this should have been a clue), but Youtube worked fine (which showed that the network was working fine).

So I did the obvious thing and started checking the NFS parameters to see if anything had changed. Nothing definite but on the way I noticed that the TV box wasn’t getting an IPv4 address from the dhcp server; IPv6 was working fine but some services don’t work on an IPv6 network.

I foolishly assumed that the TV box had stopped requesting addresses via dhcp – backed by the dhcp logs which showed no requests had been logged since the previous day. Set a static address, and everything sprang into life (except for ITVX who seem to have decided that only approved TV boxes should be allowed to run their code).

Later that same day, I upgraded a switch which failed to come back (“Failed to adopt”) which caused a daisy-chained wireless access point to disappear (“Failed to adopt”). And then a little while later, a second unconnected wireless access point also disappeared.

After a few reboots of the switch (and access points), I finally checked the dhcp server and found that its root filesystem had become ‘read-only’. But that wasn’t the end of the misdiagnosis …

I assumed that the SD card in my dhcp server (a tiny ARM box) was fried, so made arrangements to backup the contents, buy a couple of replacements, and try a spare (which was broken). After the spare turned out to be broken, I ran fsck on the root filesystem of the original and a whole bunch of errors were fixed.

Re-installed into the ARM box, and everything sprang to life again.

I guess the moral of the story is that you should check the basic services before diving into making assumptions.

Upended Cannon
Oct 302021
 

Steam under Linux (and probably other environments too but I’ve never run it elsewhere) has a nice feature to enlarge text on high dpi displays. Unfortunately when I enable it, the pop-up windows (such as the settings window) will scroll down the screen repeatedly disappearing from view.

Which is very inconvenient and makes it quite tricky to turn the feature back off again. Now this could be a problem with the Awesome window manager or with the settings that I use (although Steam seems to be the only application with this issue), but I’m not interested enough to try and fix the problem.

I just want to change the setting back to something that may be small and squashed but at least works.

  1. Find the ~/.steam/registry.vdf file.
  2. Edit with a text editor and search for “DPIScaling” :-
» grep DPIScaling registry.vdf 
					"DPIScaling"		"1"

And change the “1” to a “0”, and restart Steam.

About To Break
Oct 302021
 

Ever since adding a couple of additional network interfaces to my workstation I have had a problem with reboots – the systemd-networkd-wait-online.service service “lingers” as it waits for all of the NICs to come online (and fails). Not especially problematic as everything works fine after the boot process has finished, but it slows down reboots (which are slow enough on this rather complicated desktop) and gives me an amber ✗ in my window manager’s status bar.

After spending some time re-jigging my storage (which consisted of far too many reboots), I finally decided to fix it.

Which basically consisted of making the relevant NICs “optional” in netplan. :-

    enp9s0f1:
      dhcp4: false
      accept-ra: false
      addresses: [172.16.76.0/24]
      optional: true

This isn’t one of the NICs that I actually use – I added the NIC configuration in an earlier attempt at making things work … unsuccessfully. The key part is the “optional: true” bit.

And whilst you’re in there, replacing the gatewayv4 and gatewayv6 specifications with the “new style” is worth doing too :-

      routes:
        - to: default
          via: 192.0.2.1
        - to: default
          via: 2001:db8:9c2:dead::1

(No those aren’t the real addresses)

This can be activated in the usual way – with a netplan apply (in my case a netplan try isn’t effective because of the use of bridges), although in this particular case a full reboot is called for.

The Round Table
Jul 182021
 

This is a procedure to replace one working drive in a fully functional mirror vdev; if you are replacing a failed disk there is no advantages in following this procedure. Although if you have a somewhat functional disk it may be worth trying.

So why not simply yank out the working disk you want to replace? Well, you can of course and that would work but there is nothing Murphy likes more than a mirrored vdev temporarily down to a single disk – resilvering onto a new disk guarantees a higher chance of failure of the previously working disk (I have actually seen this happening).

So I’m going to describe how to make a three-way mirror with three disks and then detach the disk you wanted to replace.

To do this there are some prerequisites :-

  1. You will need space to install an additional disk into your system; perhaps temporarily in an “unsuitable” location.
  2. You will need a spare SATA controller port to plug the new disk into. If necessary with an additional PCIe SATA controller (which sounds expensive but safety is worth the cost).
  3. You will need a SATA data cable and a SATA power cable.

The first step is to make very careful note of what devices you are going to “swap over” – ideally using their WWNs. If you don’t use WWNs, sorting out which disk is which is going to be a bit trickier.

The second step is to practice the steps involved using a ‘fake’ storage pool backed up by tiny disk files :-

# cd /pool1/temp
# for w in one two three
do
  dd if=/dev/zero of=test-disk-${w}.img bs=1M count=1000
done
# zpool create test mirror /pool1/temp/test-disk-one.img /pool1/temp/test-disk-two.img
# zpool attach test /pool1/temp/test-disk-one.img /pool/temp/test-disk-three.img
# zpool detach test /pool1/temp/test-disk-one.img

That’s pretty much it in a nutshell.

The real process is a bit more disturbing of course and most of the work is physical. The first difference from practice is that when you attach the new disk to one or other of the existing devices within the mirror, you will have to wait until the resilvering process is complete.

Whilst you will receive an estimate for that if you run zpool status, the estimate that you get :-

  scan: resilver in progress since Sun Jul 18 08:20:54 2021
	8.25T scanned at 1.09G/s, 7.28T issued at 981M/s, 8.25T total
	995G resilvered, 88.23% done, 0 days 00:17:16 to go

(Only showing the relevant part as the full output from my system is confusing and deceptive)

Is wildly inaccurate – partially because the resilvering process takes second place to any ordinary file system activity. My own estimate (1 hour per Tbyte) is probably also wildly inaccurate; basically it is done when it is done.

Detaching the old device is fast – you won’t need to sit down to wait for it.

Jul 112020
 

So I am currently messing around with a tiling window manager on my laptop – I prefer tiling window managers in general (I use Awesome on my main desktops). These are (in general) not “desktop environments” but just manage windows (and sometimes a “status bar”).

As it happens the window manager I’m messing with doesn’t come as part of a distribution package with a pre-prepared file for GDM3 to use. So I created a ~/.xsession file – something that has worked since display managers first arrived.

Didn’t work.

Turns out that I need to “hack” GDM3 to make a long standard bit of functionality functional again. As an aside (and especially to the GNOME people), all you had to do to keep this functional was detect if someone had a ~/.xsession file and then offer that up as a menu option. Not that difficult to do and even if it isn’t your preferred way of doing things, it’s a nice thing to do for us old-timers.

Anyway, to restore this functionality all it took was to create a file in //usr/share/xsessions/ called xsession.desktop with the following contents :-

[Desktop Entry]
Name=XSession
Comment=This session uses the custom xsession file
Exec=/etc/X11/Xsession
Type=Application
DesktopNames=GNOME-Flashback;GNOME;
X-Ubuntu-Gettext-Domain=gnome-flashback

Dead simple.

And yes I stole this and adapted it myself – I’m putting this up here so that I know where to look when I need it again.