Archive for December 22, 2020

Tuesday, December 22, 2020

Booting an M1 Mac From an External Disk

Howard Oakley (tweet):

The most obvious method of doing this is to run the Big Sur installer app, and select a freshly formatted external drive as its destination. Some who have attempted this using an M1 have reported that the installation never completes; thankfully mine was completely successful until I tried to restart from it. Although I could see and select it in the Startup Disk pane, Big Sur 11.0.1 couldn’t be booted from there.

Checking the external disk gave no clues as to what was wrong.

yarshure:

zero problems[…] But [don’t] support X86 Mac installed partition, you need full new install on M1 Mac.

Howard Oakley (tweet):

Thanks to many comments but no real clues, I’ve now been able to solve this, and here explain how you can do this too.

[…]

Once booted from the internal disk again, ejecting the bootable external disk isn’t fault-free. Clicking on the Eject tool for the System disk brings a helpful dialog which offers to unmount both System and Data volumes. Oddly, on Intel Macs running Big Sur, the Data volume isn’t shown as a separate volume, but on M1 Macs it is.

Unfortunately, on an M1 Mac running macOS 11.1, the Data volume is usually left behind, and any attempt to eject it will result in your being told that it’s still in use, while trying to open the volume denies that it’s present at all.

[…]

If you’re trying to create and use a bootable external disk for M1 Macs, I therefore recommend that you don’t waste your time discovering which USB-C SSDs might be compatible: go straight for a Thunderbolt 3 enclosure. It’ll cost you more but save you time and effort in the long run.

Update (2021-01-01): See also: Hacker News.

Update (2021-02-10): Howard Oakley (Hacker News):

Now that Big Sur can be updated to 11.2, I’ve been looking at how that affects external boot disks, and whether it finally enables them all to work. However, far from 11.2 solving this problem, it actually makes it worse.

[…]

It doesn’t appear possible to update a bootable external disk, only to format it and install a fresh system, as if the disk had never had macOS installed before.

The 11.2 full installer is incapable of copying existing account settings from the internal SSD to a fresh installation of 11.2.

M1 Macs currently don’t work reliably with bootable external disks. Users who want to boot from an external disk would be wise not to buy an M1 model, until Apple has fixed these problems completely.

Update (2021-03-14): Howard Oakley:

Having now completed the most pointless macOS update ever – that to 11.2.2 – I had hoped that Apple might at least have finally fixed the bug which prevents macOS updates from being installed successfully on most external bootable disks connected to M1 models. TL;DR: it doesn’t.

Update (2021-03-23): Howard Oakley:

If you want to use 1 True Recovery to change to or from using a bootable external disk, use its Startup Manager. Press and hold the Power button until the display shows Loading Startup Options, then release it. This takes you to the Startup Options screen. Wait until all bootable disks have loaded into the list, select the disk you want to boot from, then click Continue underneath it.

Howard Oakley:

If there’s anyone left who’s still trying to boot their M1 Mac from an external SSD, the question now is how to update it to macOS 11.2.1. As I reported, booting from the external disk isn’t likely to result in successful update, although a few users have reported that Software Update worked first time for them. Assuming that you have the same bad luck that I’ve had trying to do this on numerous occasions, here are my findings to guide you.

Previously:

Update (2021-04-15): Howard Oakley:

With changing Mac hardware, the use and value of external boot disks is changing. This article is a short overview of what’s happening, and its consequences.

Previously:

Update (2021-05-03): Howard Oakley:

Big Sur 11.3 progresses support of external bootable disks by M1 Macs, but can still appear flawed and unreliable, at least with non-Thunderbolt SSDs.

[…]

Strangely, with both bootable external SSDs (Thunderbolt 3 and USB-C), changing between booting from the external or internal SSD often takes you through the Recovery Assistant, despite the Mac being restarted from the Startup Disk pane. Although not a problem, it means that switching between disks can require two restarts.

[…]

The Finder often fails to eject external volume groups correctly. Although the ejection itself works, the Data volume is usually left in the Finder’s sidebar, from which it can’t be removed until the Mac is restarted without that external disk connected.

Undocumented NSShadow Change on Catalina

Jeff Johnson (tweet):

Curiously, the API documentation for shadowOffset is now shared between AppKit and UIKit.

[…]

So there is a change in behavior of NSShadow shadowOffset in AppKit on Catalina, presumably to emulate UIKit. Sigh… why does the Mac always have to emulate iOS now? Unfortunately, AppKit developers were not informed of the change, because there were no AppKit release notes published for Catalina.

If you want the shadowOffset to behave as (you) intended on all versions of macOS, both before and after Catalina, the workaround is to check if (@available(macOS 10.15, *)) and switch the sign of your offset height accordingly.

Jonathan Deutsch:

Also your article surfaces for me that the number of mandatory @available checks to workaround bugs and API changes is really getting bad for my app.

@hypeapp runs on macOS 10.10+ and has 111 checks! These are for compatibility and not to make use of new OS features.

Also, some enum values have changed on Apple Silicon Macs:

The NSTextAlignment enumeration uses different numerical values for some constants on arm64 and x86_64 architectures. When referring to constants using numerical values, validate that you use the correct values on each architecture.

The NSImageResizingMode and UIImageResizingMode enumerations uses different numerical values for some constants on arm64 and x86_64 architectures. When referring to constants using numerical values, validate that you use the correct values on each architecture.

See TARGET_ABI_USES_IOS_VALUES in the headers. I’m not sure how this interacts with archiving.