[solved] ‘Because of billing requirements, it is currently not possible to disable auto-renewal’ (1and1)

tl;dr I was within 24 hours of domain renewal, so had to phone +44 333 336 5691 to cancel

I have a bunch of domains that I used at one point but no longer have a need for. I used to handle my domains with 1and1, and they sent me a reminder about an .eu domain which was expiring soon (tomorrow). I looked at what it had been used for — a ranty blog, if you’re wondering — and decided thta since it hand’t been used since ca. 2008 it probably wasn’t worth keeping.

Side note: Getting rid of things like domains is tricky for me, but something I’m just biting the bullet and doing. Tracking my expenses is helpful as well, an worth a bit of exposition at some point.

I went to cancel via the 1and1 admin page but couldn’t through the domain itself or the contract options:

Because of billing requirements, it is currently not possible to disable auto-renewal

Clicking around in an increasingly-frustrated manner didn’t seem to be getting me anywhere, so I phoned their tech support. Their rep told me that helpfully since it was within 24 hours of renewal, I was unable to change the option (?!); but he was able to manually cancel the domain itself.

Which he did:

Sorted.

Why Won’t My GIMP Python Plug-in Show Up Under Filters?

tl;dr: Did you put it in ~/.gimp-2.8/plug-ins and set the executable bit ?

It’s been a while since I developed a script to automate tasks in GIMP. I figured I would do one for the repetitive tasks for creating a custom YouTube Thumbnail (more on that later perhaps). But my script wasn’t showing up in the Filters menu.

I had found the preference for setting the directory: Edit ? Preferences ? Folders ? Plug-Ins (not that GIMP treats python as plug-ins, not scripts); with the default user folder being ~/.gimp-2.8/plug-ins. But the plug-in dind’t show up.

Restart GIMP. Still nothing.

Ask on IRC. Double check the documentation (always a good idea). Aha!

Scheme and Python plug-ins are readable text files. C-language and Python plug-in files must have permissions set to allow execution.

chmod +x myscript.py later, and it registered!

Hope this saves someone the twenty or thirty minutes it took me to find this out!

Invalid Security Token Issues

tl;dr: Having both AntiSpam Bee and Jetpack Comments causes this, disable one or other

While trying to leave a comment on here on a previous post, I got an error:

Invalid security token

Apparently, AntiSpam Bee and Jetpack Comments are not compatible. I’m not sure when Jetpack comments were enabled as I’ve had relatively recent comments/ I will see if I can find an antispam plugin that is compatible with Jetpack comments, or disable those.

My sincere apologies to anyone who has tried to comment and not been able to as a result!

[Fixed] No LED light on Logitech K750 Keyboard

K750 charging under a lamp

tl;dr: Use a combination of a bright light and the reset technique (off ? CAPSLOCK + some keys ? on)

Background

A few years ago while on holiday in sunny SC — a lovely place to visit, incidentally — I took the opportunity to purchase a Logitech K750 keyboard. The K750 was is a ‘solar’ keyboard- no changeable batteries, only solar cells to power it. I had been frustrated by other keyboards which needed battery changes timetabled in accordance with Sod’s Law.

They keyboard got passed on to my folks and all was well. However, since my dad passed away my mum has not used the computer as much, and so the lights in that room haven’t been on. When I went to use the computer there recently the keyboard was completely dead. Not even the red ‘sad face’ LED would light even if held close to a light source, which would normally elicit some response.

Leaving the keyboard in a decent amount of ambient light for a few days seemed to do very little to help.

Revivifying a K750

Enter Nut and his Tech, wherein they describe the reset procedure:

1. Turn off the keyboard.
2. While holding onto CAPS lock, keep pressing a few keys for the next 5 or more seconds.
3. Turn on the keyboard.

I did the above and held the K750 very close to a fairly bright bulb, and the LEDs sprang to life!

First the green happy face when still next to the light, then the red unhappy face when I took it out of full illumination.

So it works, for now. I was even able to type from the next room over where it sits charging beneath a mini anglepoise-type lamp.

Intermittent Monitor Blanking

tl;dr: Using a better-rated HDMI switcher improved the situation

For the past… maybe six months to a year one of the monitors I have has been ‘blanking’. That is, it will display properly most of the time, but intermittently go blank for around three seconds before the display reappearing. Strangely, the behaviour only occurred:

  • under Windows, not Linux
  • when using an HDMI switcher

For whatever reason, the issue got much worse in the last couple of weeks, where instead of happening once every five to sixty minutes (or sometimes not at all), it was happening back-to-back, several times per minute with an intolerable frequency. The situation was untenable.

I wondered about interference from other nearby cables, but adjusting them didn’t make any discernable difference. The monitor was running at 59Hz, but stepping it up to 60Hz made no difference either (and Windows 10 set it back to 59Hz). If anything, increasing the frequency may have made the problem worse.

So I figured the issue was the cheap HDMI switcher that I have. I don’t quite recall the circumstances of buying it (never a good sign), but it would have been cheap and therefore unlikely to be rated for 2560x1440x60Hz. After replacing the switcher with one with was rated for ? 2560x1440x60Hz, the issue seems to have mostly resolved- there was *one blank, but I think I can tolerate that.

For anyone else having a similar problem, allquixotic had the following to suggest for potential causes:

Periodic blanking could be: loose cable/connector; bad HDMI port; bad HDMI codec on the GPU/mobo; EMI interference on the cable (e.g., crosstalk by contact with another cable); or, yeah, insufficient cable quality for the data quantity being pushed… also could be pure software

you know, it could simply be Windows driving more data to the monitor; have you verified Windows isn’t overclocking the monitor beyond 60 Hz?

or it might be a GPU issue — Linux tends not to even use the GPU very often unless you’re decoding video, using the animation “whizzy” effects of a compositing window manager, or explicitly an OpenGL application (which in modern times could actually be a typical web browser, but not for everything)

*: I can’t quite explain why the problem only occurred under Windows, but I’ll wave my hands and say “driver differences” while nodding sagely.

[Solved] “Logical volume is used by another device”

tl;dr: use dmsetup remove before trying lvremove

Note: Volume group and logical volume names have been substituted here. I’m not entirely sure it’s necessary, but better safe than sorry. If following this, please use the names of your volume group[s] and logical volume[s]

I am in the process of combining fileserver information, and so I have been touching parts of the system not usually looked at in the normal case of day-to-day operations. For some reason, on one of my logical volumes I had created a partition table and added a partition. Of course, that worked normally so there was no reason to be aware of this — clearly I had blanked the fact that I did it at all not long after doing so — until recently.

The Problem

Logical volume vg/lv-old is used by another device.

After copying the data over to a new logical volume, I wanted to remove the now-unnecessary original logical volume that contained the partition. Easy, right?


# lvremove -v /dev/vg/lv-old
    DEGRADED MODE. Incomplete RAID LVs will be processed.
    Using logical volume(s) on command line
  Logical volume vg/lv-old is used by another device.

Okay, what’s using it? cat /proc/mounts reports that it isn’t mounted. lsof and fuser return nothing. Maybe retrying the command will work*… nope.

There are a bunch of posts around this, mostly saying “make sure it is umounted first”, or “try using -f with lvremove“. And the old favourite: “a reboot fixed it”.

Find Out device-mapper’s Mapping

Well, the culprit in this case seemed to be device-mapper creating a mapping which counted as ‘in-use’. Check for the mapping via:


# dmsetup info -c | grep old
vg-lv--old       253   9 L--w    1    2      1 LVM-6O3jLvI6ZR3fg6ZpMgTlkqAudvgkfphCyPcP8AwpU2H57VjVBNmFBpL
Tis8ia0NE

Find Out Mapped Device

Then use that to find out what is holding it:


$ ls -la /sys/dev/block/253\:9/holders

drwxr-xr-x 2 root root 0 Dec 12 01:07 .
drwxr-xr-x 8 root root 0 Dec 12 01:07 ..
lrwxrwxrwx 1 root root 0 Dec 12 01:07 dm-18 -> ../../dm-18

Remove Device (via `dmsetup remove`)

Then do a dmsetup remove on that device-mapper device:


# dmsetup remove /dev/dm-18

Retry `lvremove`

And you’re good to go with lvremove:


# lvremove -v /dev/vgraid6/lv-old
    DEGRADED MODE. Incomplete RAID LVs will be processed.
    Using logical volume(s) on command line
Do you really want to remove active logical volume lv-old? [y/n]: y
    Archiving volume group "vg" metadata (seqno 35).
    Removing vg-lv--old (253:9)
    Releasing logical volume "lv-old"
    Creating volume group backup "/etc/lvm/backup/vg" (seqno 36).
  Logical volume "lv-old" successfully removed

Bish bash bosh!

Addendum

*: I’m not sure of the thought process behind “just try it again”.

I’m reminded of a short bit of Darrell Hammond’s stand up (paraphrased):

“You know that message you get when you dial the wrong number that tells you to ‘check you have the right number and dial again’? Well, women will check the number and try again. Men will try the same number, but this time we’ll push the buttons a ******** harder…”

[Solved] “Filesystem is already n blocks long. Nothing to do!”

tl;dr: if you’re sure you did everything right, use lsblk or parted (etc) to see if a partition table is present on your logical volume.

So I am in the process of merging the content of two fileservers, and had the need to extend a logical volume to accommodate some additional data. No problem- that’s one of the benefits of using LVM!

Except after resizing, I ran into a problem:


$ lvextend +150G /dev/vg/lvinquestion
$ resize2fs /dev/vg/lvinquestion
> The filesystem is already 268435200 (4k) blocks long. Nothing to do!

Wait, what? Aside from the fact I could have combined the comments by including the --resizefs option to lvextend, why was resize2fs complaining that there was “Nothing to do!”?

Fortunately SE Arquade user ToxicFrog had the answer:

@bertieb parted reports the partition size, not the filesystem size
If it’s a partitioned LV you need to resize the partition after expanding the VL
*LV

Ah, whoops! I’m not sure why I partitioned the LV (it only had one partition) but I must have done so.

lsblk confirmed the partition:


sdh                                8:112  0   2.7T  0 disk
??sdh1                             8:113  0   2.7T  0 part
  ??md1                            9:1    0  10.9T  0 raid6
  (...)
    ??vg-lv                      253:9    0   1.2T  0 lvm
    ? ??vg-lv1                   253:18   0   1.1T  0 part

So, then what? Well, I used dd to copy the filesystem to a new logical volume, then extended that, and finally removed the original:


# dd if=/dev/dm-18 bs=1M | pv -s 1T |  dd of=/dev/vg/lv-new bs=1M
# lvextend --resizefs -L 1.15T /dev/vg/lv-new
# lvremove /dev/vg/lv
# lvrename vg lv-new lv

(pv was included to give a nice progress indicator, rather than faffing around with SIGUSR1)

And that was that. There was a slight problem with removing the original logical volume, but more on that later…