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.