OK, the weekly screwing around with your Mac updates. Here are some of the interesting things I’ve learned…
Use APFS and GUID for USB Drives
One of my Macs only has a 256GB SSD. That sounds like a lot, but I regularly run out of space and have when I’m home a RAID1 16TB array on Thunderbolt 3 (a hat tip to CalDigit TS3 and the RS3 Dual Drive TB3 holder for 3.5″ hard drives!).
But when I’m on the road I would really like storage for things like git repos. So I tried a simple and small solution: a 128GB Kingston D microDuo 3C USB Key with no hope of success. This is just a regular USB key that is very small and has both a USB A and a USB C connection so there is some hope of taking it on the road. But I quickly found that this worked really poorly when configured as a FAT drive with the old Master Boot Record and exFAT file system. I would get all kinds of strange git errors complaining about node failures.
The inspiration was when I looked at the drive, I wondered if Fat was really going to be able to handle it, so I reformatted the drive using the latest APFS file system and the more modern GUID Partition Map. This means that Windows machines can’t read it, but maybe this would work better. And voila! I can now recurse submodules and it seems to work. The moral of the story is that you should use ExFAT for compatibility, but APFS if you really want the key to work doing lots of file I/O as I’m sure git is doing right now.
HD HomeRun reception is weather dependent
OK, I can now confirm this, I’ve been moving the HD HomeRun antenna around, but when I check the channels, I get different ones. When I think about it makes some sense, when it is rain is going to reduce signal, but right now I’m getting channels 4 and 7 whereas before it was 5 and 7. The easiest way to do this by the way is that the HD HomeRun does use Bonjour, so you can always access the channel detection at https://hdhomerun.local
Can’t Get Open Core Legacy Patcher to work
Argh, I have a plethora of old machines and I just can’t get the latest operating system on them. It is quite a tribute to Apple to say that I have hardware working reliably that is 13 years (?!!!) old. This includes a MacBook Pro 2010, 2014, 2016, and 2017 as well as a MacBook Air 2012 and Mac Mini 2011. But, it would be nice to have Monterey at least running on all of them. This is what OCLP promises to do. It’s a fairly involved process. Go to each machine download it, then download the installer that you want, get a USB drive and it then does its magic to hack away at say Monterey to get it to run.
And most of the time I can get it to install, but when I boot to the new image, I get the “Do Not Enter” sign. Sigh, what an amazing project, but I need to invest more time in it.
Apple Photos Sync stalls
OK, I often find on this machine that Apple Photos just stops syncing. I thought this might be because of disk space, but it just seems like a bug. I think this is a problem with the large size of my Apple Photos. There are a bunch of fixes, but in order, it is basically thanks to MacWorld:
- Quit and restart Phots. This didn’t work for me.
- Kill anything names photos in Activity Monitor like cloudphotod (that does the upload), photolibraryd. This didn’t work
- Restart the Mac. This didn’t work
- Rebuild the Photos database by holding down the Command-Option while launching. This took forever on a huge database, but it did work
- Disable and enable iCloud Photos in Photos > Preferences > iCloud. Good idea I haven’t tried it.
- Goto in the Finder your Photos Library and then Control-click it and select Show Package and go down to
private/com.apple.cloudphotosd/CloudSync.noindexand delete it.
The other problem I had on a really old Mac, a MacBook Air 2011 is that I tried the sync and it failed when running out of disk space and left a massive 56GB file in ~/Library. So look out for that too.
Synology USB Copy partially crashes the UI with Drobo on DSM 6
Ok, this is a strange edge case, I have an old Synology DS2413+ running DSM 6, and when I plug an even older DroboPro from probably 2010 and try to run USB Copy to do backups it originally crashed the Synology. But trying it again this year, it only crashes the user interface and makes new file connections fail. But alas that is still not great, so I’ve moved the Drobos back to an old MacBook 2010 to try to get that to work. But, the USB drives are not recognized. Usually it takes a little while but they come up. Oh well 🙂
Git LFS files should have been pointers but were not
I get this pretty often and this is typical because git lfs was not installed and then when you pull and push, you are pushing real files. I’ve also had the other case where the pointers are checked in rather than the real data. I think all of this is related to having git lfs as a client-side only thing and there is no warning when you clone a repo when you do not have git lfs installed. Sigh. But the recovery is the same which is that you try to reinstall git and then pull the files from the lfs store associated with the repo. This by the way is another example where you should not just read the most liked item in StackOverflow, the right answer is much further down. The explanation for what is going on here is that when git lfs looks at .gitattributes, it assumes all files wildcarded there are going to be in git lfs, so when it find say a .jpg that is a real file, it is confused, it expects a pointer and got a real file.
What the migrate import does is take all the files listed in .gitattributes and if it finds something that is not in Git LFS (but is in the git repo itself), it pushes the file into git lfs and leaves a pointer.
# make sure you have git lfs version 2.5 or higher
# --no-rewrite says do not rewrite the entire commit history
# --everything is dangerous it is better just to have a list of offending files
git lfs migrate import --no-rewrite broken1.jpg broken2.jpg
# if you want to go full nuke!
git lfs migrate import --no-rewrite --everything
# the old way to fix
cd <offending repo>
git lfs uninstall
git reset --hard
git lfs install
git lfs pull
# If this doesn't work then the more exstream thing is
git rm --cached -r
git reset --hard
# this blows away git lfs associations
git rm .gitattributes
git reset .
git checkout .
