Trying to use the “timescaledb-tune” utility (a key part of the installation process for TimescaleDB) on any Mac made in the last 5 years will result in an error unless you have the Rosetta 2 dynamic binary translation feature installed:

unable to execute /opt/homebrew/bin/timescaledb-tune: Bad CPU type in executable

This is particularly weird as the TimescaleDB library itself is ARM64.

Given that Tiger Data have had 5 years to ship a native ARM64 binary for their “timescaledb-tune” utility, it is rather disappointing to see that they are still relying on people installing the optional Rosetta 2 dynamic binary translation feature on their devices. This requirement also doesn’t seem to be documented anywhere that I can find.

Apple are going to be removing most of Rosetta 2 from macOS 28 in 2027, so hopefully Tiger Data will get around to shipping an ARM64 binary before then.

In the meantime, we can manually build an ARM64 binary for the “timescaledb-tune” utility from source as follows:

1. Download the Go installer from https://go.dev/dl/ using the “Apple macOS (ARM64)” option and run through the installer steps.
2. Open up your preferred terminal app and run “go install github.com/timescale/timescaledb-tune/cmd/timescaledb-tune@main”.
3. You will find the ARM64 binary for the “timescaledb-tune” utility in ~/go/bin/timescaledb-tune

I really don’t understand why Tiger Data aren’t shipping an ARM64 binary for their “timescaledb-tune” utility, given how ridiculously simple it is to build one!

The post ARM64 timescaledb-tune on macOS first appeared on Spheron1.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).

After a quick rummage, I found that the reason was that the “LANG” environment variable on my laptop was defaulting to “en_GB.UTF-8”, whilst on the Ubuntu jump server it was “C.UTF-8”.

The cPanel server runs some Perl stuff when bash starts and if it doesn’t like your locale settings, then it spits out these warnings.

The “LANG” environment variable is part of the locale system and so the best way to fix this is to update the locale settings configured on the Ubuntu jump server.

By default, SSH on both macOS and Ubuntu is configured to send the local “LANG” and “LC_*” environment variables used for locale settings to the remote system.

You can use the “locale” command to see your current locale settings as well as “locale -a” to see installed locales.

$ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE=”C.UTF-8″
LC_NUMERIC=”C.UTF-8″
LC_TIME=”C.UTF-8″
LC_COLLATE=”C.UTF-8″
LC_MONETARY=”C.UTF-8″
LC_MESSAGES=”C.UTF-8″
LC_PAPER=”C.UTF-8″
LC_NAME=”C.UTF-8″
LC_ADDRESS=”C.UTF-8″
LC_TELEPHONE=”C.UTF-8″
LC_MEASUREMENT=”C.UTF-8″
LC_IDENTIFICATION=”C.UTF-8″
LC_ALL=

$ locale -a
C
C.UTF-8
POSIX
en_US.utf8

In my case I wanted to use en_GB.utf8, which wasn’t installed. You can use the “locale-gen” command to generate locales, but they are also provided in official Ubuntu packages , so I installed the “language-pack-en” package from the Ubuntu repositories using APT.
This added several English locales and then I could reconfigure Ubuntu to use the one that I needed.

$ apt-get install language-pack-en
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following additional packages will be installed:
language-pack-en-base
The following NEW packages will be installed:
language-pack-en language-pack-en-base
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 420 kB of archives.
After this operation, 3756 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 language-pack-en-base all 1:18.04+20180712 [419 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 language-pack-en all 1:18.04+20180712 [1904 B]
Fetched 420 kB in 0s (3606 kB/s)
Selecting previously unselected package language-pack-en-base.
(Reading database … 50814 files and directories currently installed.)
Preparing to unpack …/language-pack-en-base_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en-base (1:18.04+20180712) …
Selecting previously unselected package language-pack-en.
Preparing to unpack …/language-pack-en_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en (1:18.04+20180712) …
Setting up language-pack-en (1:18.04+20180712) …
Setting up language-pack-en-base (1:18.04+20180712) …
Generating locales (this might take a while)…
en_AG.UTF-8… done
en_AU.UTF-8… done
en_BW.UTF-8… done
en_CA.UTF-8… done
en_DK.UTF-8… done
en_GB.UTF-8… done
en_HK.UTF-8… done
en_IE.UTF-8… done
en_IL.UTF-8… done
en_IN.UTF-8… done
en_NG.UTF-8… done
en_NZ.UTF-8… done
en_PH.UTF-8… done
en_SG.UTF-8… done
en_ZA.UTF-8… done
en_ZM.UTF-8… done
en_ZW.UTF-8… done
Generation complete.

$ locale -a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IL
en_IL.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX
$ update-locale LANG=en_GB.utf8

The locale settings are stored in “/etc/default/locale“, so you can either edit this file manually or use the handy “update-locale” utility to do it for you.
Either way, once you start a new session, you are using the new locale settings and Perl no longer complains when you SSH to a cPanel server.

The post Changing the locale in Ubuntu Server first appeared on Spheron1.

Apparently there are ways to fix this by building the necessary drivers and inserting them into the Preboot volume, but as the drive in question is an m.2 NVMe disk, I didn’t have an easy way to put it into another computer which could mount APFS volumes.

I therefore decided that the quickest and simplest way to recover a working system was to temporarily decrypt the volume.
To do this, I booted the macOS installer from my UniBeast USB stick and launched the Terminal from Utilities->Terminal in the menu bar.

I found plenty of articles suggesting to use “fdesetup” to manage FileVault, however this utility doesn’t seem to be included in the macOS installer, so instead I had to work out how to accomplish this with the “diskutil” utility.

As I’m using APFS, everything takes place using the commands under “diskutil apfs”, however for older HFS+ formatted disks, the same thing should still be possible using the equivalent CoreStorage commands under “diskutil cs” (although I haven’t tested this, so the steps may be a little bit different).

Now lets take a look at the disks and volumes in this system:

diskutil apfs list

This gives you an ASCII tree view of your disks and their volumes along with various information about each of them.

Find the UUID (the 5 groups of letters and numbers separated by hyphens) for the volume  that you want to decrypt – it will say “Encrypted: Yes (Locked)”.

Before we can decrypt the volume, first we need to unlock it:

diskutil apfs unlockVolume <UUID>

Enter your passphrase and the volume will be unlocked so that it can be accessed. This only unlocks the Volume whilst the computer is running however and won’t persist after a reboot.

To permanently decrypt the volume, run:

diskutil apfs decryptVolume <UUID>

This will start the decryption of the volume in the background.

You can run “diskutil apfs list” again to see the progress. Instead of the previous “Encrypted:” line, you should now see “Decryption Process: 1.0% (Unlocked)”.
Depending on the size of the volume in question, it could take quite some time to complete the decryption.

Once completed, the progress line in the output of “diskutil apfs list” will have been replaced with “Encrypted: no”. At this point it’s safe to boot back into normal macOS.

The post Decrypting an APFS volume from the Terminal first appeared on Spheron1.

I couldn’t find the “Junk” mailbox anywhere – it wasn’t in the list of special folders (Drafts, Sent, Trash etc.) with the Inbox and it wasn’t in the list of general mailboxes – it had seemingly just vanished.

This is particularly annoying for me as I used Zimbra for my mail server and can train the server side junk mail filters by moving messages in and out of the special “Junk” mailbox.

All of the junk mail settings in Apple Mail were enabled and seemed to match those in the same version of Apple Mail on my old laptop, so what was happening?

It seems that when you have the junk mail setting in Apple mail set to “Mark as junk mail, but leave it in my Inbox”, Apple hides the “Junk” mailbox to start with whilst it trains its filters and then only shows it once they have sufficient data built up to start identifying spam.

A quick work around to get the “Junk” mailbox to show up straight away is to change the junk mail setting in Apple Mail from “Mark as junk mail, but leave it in my Inbox” to “Move it to the Junk mailbox” and back again.

Changing this setting causes the “Junk” mailbox to be shown and the mailbox doesn’t get hidden again when you change it back.

The post Missing Junk mailbox in Apple Mail first appeared on Spheron1.

When combined with the “Reopen Last Closed Window” and “Reopen All Windows from Last Session” items under the history menu, Safari now has all the features that I miss from Firefox for when I accidentally hit the cross or on the rare occasions when it just locks up (usually thanks to bloody Adobe Flash Player!).

To use this awesome new feature, just use the normal undo/redo buttons under the Edit menu.

Safari 5.0 also brings back the nice old school progress meter in the background of the address bar.

The post Re-open an accidentally closed tab in Safari 5.0 first appeared on Spheron1.

The ditto program is a command line tool for copying files and merging directories as well as extracting archives. Earlier in the evening I had been trying to extract what appears to be a corrupted .ZIP file from the finder which had failed a couple of times as it contained a directory structure but wasn’t creating the directories. In the end I made the directories by hand and then extracted it from the command line with “unzip”.

It seems that each of the failed extractions from the finder with the BOMArchiveHelper system utility left the ditto process running, even when I force quit the crashed BOMArchiveHelper instance. From looking at the process hierarchy, the ditto processes were running directly under launchd so it makes sense that they wouldn’t have been killed with BOMArchiveHelper as they aren’t children of it.

Killing each of the ditto processes from the Activity Monitor returned by MacBook Pro to it’s normal responsive self. Just remember that killing a crashed process might not always get rid of everything that it has spawned!

The post ditto 100% CPU usage in Mac OS X first appeared on Spheron1.

In Mac OS X 10.6 (aka Snow Leopard), this presents a bit of a problem as Activity Monitor can no long be moved as the path to activitymonitord is now hard coded for some reason. If you do move it, then Activity Monitor appears to start and then just hangs.

If you fire up the Console application to take a look at the syslog, then you’ll see messages along the lines of:

18/03/2010 22:20:34 com.apple.launchd[1] (com.apple.ActivityMonitor[1716]) posix_spawn(“/Applications/Utilities/Activity Monitor.app/Contents/MacOS/activitymonitord”, …): No such file or directory
18/03/2010 22:20:34 com.apple.launchd[1] (com.apple.ActivityMonitor[1716]) Exited with exit code: 1
18/03/2010 22:20:34 com.apple.launchd[1] (com.apple.ActivityMonitor) Throttling respawn: Will start in 10 seconds

There is a similar problem with the System Preferences application if you are trying to install custom preference panes such as Growl where the install window will hang with similar looking console messages:

18/03/2010 22:50:46 com.apple.launchd[1] (com.apple.systempreferences.install) Throttling respawn: Will start in 10 seconds
18/03/2010 22:50:56 com.apple.launchd[1] (com.apple.systempreferences.install[2390]) posix_spawn(“/Applications/System Preferences.app/Contents/Resources/installAssistant”, …): No such file or directory
18/03/2010 22:50:56 com.apple.launchd[1] (com.apple.systempreferences.install[2390]) Exited with exit code: 1

This is only a problem when installing new preference panes, and the System Preferences will work fine normally when moved.

Hopefully this will save someone the headache of trying to diagnose this. I was on the verge of doing a re-install, having only just installed OS X in the first place and started moving everything to be how I like it!

The post Activity Monitor in Snow Leopard first appeared on Spheron1.