Earlier this week, a third party NVMe SSD failed as the boot drive inside my MacBookPro11,4. The drive had been backed up less than 8 hours from the disaster, but I was hoping to fiddle with the failed drive a bit more to recover files on the desktop that were saved within the last 8 hours.

Jivan Pal and others have developed DRAT for macOS and linux to work with APFS drives that might have some sort of corruption (I’m assuming this is extremely rare). Immediately after the failure, the SSD drive wasn’t visible in Finder or Disk Utility and obviously wouldn’t mount. After employing the power cycle method using an USB enclosure the NVMe was suddenly viewable in Disk Utility, but still couldn’t be mounted.

And that’s when I came across Jivan Pal talking about his open-source software, DRAT. My NVMe SSD is throwing error messages that mention the Space Manager is invalid. I’m not sure DRAT will help with this issue, but I figured it was worth a shot before I sent the SSD away on warranty for a replacement.

To install DRAT, you’ll need to visit this site, find the highest number for the latest version, click the triangle next to “Assets”, and if you’re on a Mac click on the file name “drat-0.1.3-darwin-amd64” or whatever the number is that corresponds to the version you’re seeing when reading this.

When the file is downloaded place it in the /Applications/Utilities folder, then open Terminal.app to execute these two lines of code:

cd /Applications/Utilities
chmod +x drat-0.1.3-darwin-amd64
./drat-0.1.3-darwin-amd64

When you execute the code with the last line of code, move back to Finder and offer access to this app in your Security settings, Apple logo->System Preferences…/Security & Privacy->General tab, and click “Allow Anyway”.

As suspected, the NVMe SSD is too far gone as back in Terminal.app and a request for DRAT to inspect the drive yields the following output:

sudo ./drat-0.1.3-darwin-amd64 inspect /dev/disk3s1
Password:
Opening file at `/dev/disk3s1` in read-only mode ... OK.
Simulating a mount of the APFS container.
Reading container superblock at address 0x0, assuming default block size of 4096 bytes ... FAILED: read_blocks: An unknown error occurred whilst reading from the stream.
ABORT: Failed to successfully read block 0x0.

I wasn’t able to recover any files with DRAT, but I think I was close. I ended up using the trial version of Disk Drill to view a single file I was curious about and stopped my recovery effort there – my other backup was good enough. Should I return to DRAT, the online instructions were helpful.

I’m working on a project with an Advantek router (SR305 v3) that needs infrequent firmware security updates. It has the ability to pull the firmware updates from a third party web server on a specified schedule. To do this, the web server (Apache running on macOS Monterey) needs read access to the directory and files the firmware is saved in.

Advantek’s latest firmware is usually posted here. After downloading the firmware files and saving them in the web server directory “Spectre_firmware”, proper file and directory permissions are enabled on the web server by opening Terminal.app and running the following command:

sudo chown -Rv _www /Library/WebServer/Documents/Default/brad/images/Spectre_firmware

This information is for later reference if we decide to script the update process.

I had to restore my iPhone from a backup and in the process wiped out my Authenticator/two factor information, which disabled Homebridge authentication. No sweat, from Terminal.app:

sudo hb-service stop

Navigator to your home folder and Homebridge settings:

cd ~/.homebridge

Now rename auth.json:

mv auth.json auth_old.json

Restart homebridge:

sudo hb-service start

And with a browser navigate to you’ll be able to authenticate with admin/admin through Homebridge’s web user interface. In the upper righthand corner of your web browser’s tap the 3 dots, tap “User Accounts”, and finally tap “ENABLE 2FA” to re-enable two factor authentication.

I have some 32-bit apps I wanted to retain access to, so it was time to virtualize Mojave under Monterey. I found these excellent instructions, hopefully they help you too:

https://www.whatroute.net/installerapp2iso.html

Of course I installed VirtualBox Extensions in the middle of this and somehow needed to follow advice at these links:

https://stackoverflow.com/questions/65149373/kernel-driver-not-installed-rc-1908-getting-errors-in-macos-big-sur-11-0-1

https://stackoverflow.com/questions/41691803/how-to-install-guest-addition-in-mac-os-as-guest-and-windows-machine-as-host

And note to self and others who arrive here, as of today I do not recommend instructions in the following two links as they did not work for my set up:

https://appletoolbox.com/need-to-run-32-bit-apps-on-macos-catalina-use-a-mojave-virtual-machine/

https://forums.virtualbox.org/viewtopic.php?t=95049

So far things are working well. If all of this virtualization should later fail and I’m unable to continue on with my previous work in the app Addresses & Labels, I vow to follow others’ advice and give this app a shot or maybe even consider gLabels through macports.

Also, for those coming here for the first time, maybe consider skipping all the steps above and try this instead.

My blog was displaying a funky error message at the top of every page:

ABSPATH already defined in /Library/WebServer/Documents/Default/wp-config.php on line 25

After looking at line 25:

define('ABSPATH', dirname(__FILE__).'/');

I added one line above it:

if ( !defined('ABSPATH') )

And now the funky error message is gone.

For future reference, when building a Swift package, use Terminal and move into the directory of the Swift project. In Terminal, type:

swift build

The build should finish with “Build complete!”

For the hcitool project, I then tried to run it with:

.build/x86_64-apple-macosx/debug/hcitool ibeacon

A prerequisite for this stunt is to have Xcode installed if you’re on a Mac. Eventually I want to find out my Mac’s Bluetooth LMP with instructions on this site by using this command:

sudo hcitool info 9C:65:B0:A0:1E:BD

I’m hoping I find an LMP of 8. Maybe I’ll get another chance if this issue is resolved.

My above-referenced machine has a third party SSD inside of it, which when updating to Monterey through up this error message:

To get around this, I happened to have an original Apple SSD that came with another MacBook Pro. I opened the MacBook Pro, removed the 3rd party SSD, inserted the original Apple SSD, and then put the 3rd party SSD in a USB enclosure.

Next, boot the MacBook Pro while holding the option key down. Then, choose the “macOS Install” disk, which was created when the error message shown above was thrown.

Your Mac will probably restart at least 3 times all on its own, this is ok. After the restarts are done, you’ll be booted to the desktop of your 3rd party SSD that is now in the USB enclosure. Re-launch the Monterey Installer and you’ll now be able to install the 3rd party SSD in your USB enclosure. When the installation is finish (about an hour), shut the machine down and move the 3rd party SSD back inside your MacBook Pro. Press the power button to boot and be sure to hold the option key down to choose your internal 3rd party SSD.

Kind of a hassle, but it works.

Our 15-year-old Toto Aquia II CST416M toilet had been making a hissing noise at the Dual-Max flushing system valve, seem to allow water to leak past it. Just turn the water supply off, lift off the green plastic cover to access the ballcock cap – I cleaned it, but the hissing continued after it was reassembled and the water supply turned back on.

Ballcock cap is listed as THU302 “Diaphragm Cap – Lavelle” in an older parts list from 2008, but it appears removed from Toto’s 2017 parts list – go figure. Park Supply of America sold me a Lavelle Industry Inc. Korky R528 Ballcock Cap Assembly replacement (UPC 749306528039) that was easy to install and immediately corrected the issue. Thanks, PSA and LII!

I needed to upgrade a wemo Homebridge plug-in on my Mac mini, but before I could node had to upgraded from its current version v14.15.2 to v14.16.1. To find out the current version the mini was running, fire up Terminal.app type the following and press the “enter” key:

node --version

To find out which node versions brew has already installed:

brew search node

My mini had node@10, node@12, and node@14 installed, so I just typed in the following to go to the next version:

brew install node@15

It seemed to install fine, but I found the same output when executing the following command:

brew search node

And, I see what I did wrong, I upgraded to node v15.14.0 based on the following command:

node –version

I’m not sure why brew doesn’t show “node@15” when I search for installed versions of node, but I’ll let it go for now. Also, I should probably start to uninstall some older versions of node, but for now they can stay.

** Update 5-19-2023 **
I don’t remember how I resolved the situation above, but today my Mac mini was running node 16.18.1 and it upgraded to 16.20.0 using the following command:

brew upgrade node@16

After the upgrade, the following command showed 16.20.0 had installed and was running:

node -v

Back on High Sierra when I wanted to tether my MacBook Pro to my iPhone and save some battery power, I used Bluetooth and chose “Connect to Network” through the Bluetooth icon up in the menu bar. In Big Sur, that changed: when you go to the Bluetooth menu and choose your iPhone, it briefly connects and then disconnects.

I found that the “Connect to Network” option is now buried. Assuming you’ve already paired your iPhone via Bluetooth to your Mac, you can enable Bluetooth PAN using the following:

1. On your Mac, open “System Preferences”.
2. Click “Bluetooth”.
3. Right-click on the name of your iPhone and choose “Connect to Network”.

You’ll now be tethered to your iPhone via Bluetooth PAN. I only do this when I have low bandwidth needs and plan to stay tethered for a long time on battery power. In limited tests with speedtest.net and a tethered Bluetooth connection on Total Wireless, my macbookpro12,1 gets about 0.75 Mbps up and down. When tethering via wifi, the bandwidth jumps to about 40 Mbps down and 7 Mbps up. Finally, tethering via USB was nearly the same as the wifi-tether, although via USB the ping time dropped by 10 ms. This is with crude testing of one sample run for each connection type.