Normal view

There are new articles available, click to refresh the page.
Today — 22 December 2024Main stream

Refugees Are Bracing for Trump to Cut the Resettlement Program Again

As Donald J. Trump returns to office, the rebuilt program is under threat. Many vulnerable people approved for resettlement in the U.S. could be stranded abroad.

© Mark Abramson for The New York Times

Even as Syrians in California, above, and around the world celebrate the fall of former President Bashar al-Assad, the country’s future is uncertain. Refugees fleeing the instability are most likely to seek sanctuary in the United States.

Encountering Italy and Germany on a Road Trip Through Southern Brazil

13 December 2024 at 18:02
A road trip through Brazil’s Rio Grande do Sul state leads to German and Italian cuisine, dialects and a surprising number of music festivals.

© Gabriela Portilho for The New York Times

The author encountered accordion music and other unexpected delights on a meandering five-day tour through villages with names like Garibaldi and Teutônia.
Yesterday — 21 December 2024Main stream

3-Minute Christmas Market Rampage Shakes Germany

At least five people, including a 9-year-old child, were killed in the attack, which took place in the eastern city of Magdeburg. The authorities are still seeking a motive.

© Ebrahim Noroozi/Associated Press

Security guards early Saturday in front of the cordoned-off Christmas market in Magdeburg, Germany, where an S.U.V. plowed into a crowd on Friday evening.
Before yesterdayMain stream

Government Shutdown and Travel: What to Know About Flights, Passports and More

The failure to act by Congress could cause airport lines and other disruptions across the travel industry during a busy holiday travel period.

© Joe Raedle/Getty Images

“Triggering a damaging government shutdown would hurt families who are gathering to meet with their loved ones,” said Karine Jean-Pierre, the White House press secretary, in a statement issued Wednesday.

Managing kernel extensions

By: hoakley
3 December 2024 at 15:30

In case the message isn’t clear yet, third-party kernel extensions are on their way out, particularly in Apple silicon systems. Although macOS continues to extend the capabilities of its kernel using nearly 700 of them, for almost all purposes user apps and devices should now have switched to using modern system extensions and their equivalents. This article considers how you can clean your Mac of those old kernel extensions (kexts), particularly in preparation for a new Mac.

The problem

In the past kexts have been used widely to support third-party hardware and features like software firewalls and security protection. Because those run at a highly privileged level, in what’s known as Ring 1, they have been a well-known cause of instability leading to kernel panics. They also provide malicious software with an opportunity to wreak havoc at the highest level. Replacing kexts with system extensions run at a user level should improve both stability and security, although experience shows that the first of those isn’t yet guaranteed, as macOS support for system extensions hasn’t been as free of bugs as it should have been, and sometimes has caused kernel panics.

From Big Sur onwards, the previous scheme of prelinked kernels has changed to use kext collections pooling kexts to be loaded into one of three:

  • The Boot Kext Collection (BKC), on the Sealed System Volume in /System/Library/KernelCollections (Intel Macs) or the Preboot volume (M-series Macs). This is the equivalent of the old prelinked kernel, and contains the kernel itself, and all the major system kernel extensions required for a Mac to function. This is typically about 65 MB in size on Intel.
  • The System Kext Collection (SKC), also on the Sealed System Volume of Intel Macs in /System/Library/KernelCollections, but not used on Apple silicon models. This contains other system kernel extensions, loaded after booting with the BKC, and typically around 370 MB.
  • The Auxiliary Kext Collection (AKC), stored on the Data volume in /Library/KernelCollections when it exists, is built and managed by the service kernelmanagerd. This contains all installed third-party kernel extensions, and is loaded after the other two. In Full Security mode on Apple Silicon there’s no AKC.

Cleaning up old kexts is a valuable move even if you’re not intending to migrate to an Apple silicon Mac, and has grown in importance with newer Macs. For a kext to be used on an Apple silicon Mac its boot security has to be reduced, third-party kexts must be enabled, and each one installed with authorisation through Privacy & Security settings, something you’ll probably want to avoid.

Uninstalling kexts

Before going any further, you need to check each of the kexts installed on your Mac to ensure that it can now be safely removed, either because there’s a better substitute, or because they have simply become orphaned. In many cases, on older Macs, kexts currently installed aren’t used at all, but have been abandoned there.

As you may be aware, kexts are now found in two different locations. They should have been originally installed by the app they came with, and saved first to /Library/Extensions. macOS then normally copies them from there to a folder nested inside /Library/StagedExtensions. That presents a further problem, as the latter are protected by SIP and can’t be tampered with. Cleaning up old kexts might thus appear an impossible task.

The good point about /Library/StagedExtensions is that its contents are structured to inform you of where the original kext came from: if it’s in /Library/StagedExtensions/Applications, then the kext was installed by that app, otherwise its folder path should lead you in the right direction.

For kexts installed by an app, or its installer, the responsibility for removing that kext rests with the app or its dedicated uninstaller. Apps that use kexts have to install them before use, for which most run scripts to move or copy the kext into the /Library/Extensions folder. They will then use additional scripts to update or remove that kext, that should save you the trouble. First visit that app’s support pages, and consult the procedure described there for uninstalling it. If the copy you have installed on your Mac isn’t the current version, you are likely to be advised to update to that latest version in order to uninstall it correctly.

Orphaned kexts

When a kext appears to have become orphaned from its app, or perhaps was installed independently, you’ll need to remove it manually. The steps required are:

  • Delete all apps and services that might try to use that kext, and any other kexts that might depend on it.
  • Unload the kext.
  • Delete the kext from the /Library/Extensions folder.
  • Restart to allow the auxiliary kext collection to be rebuilt.

It’s important to remove the app and any services that might try using that kext, as some might even try to reinstall it if they’re run. Others that might be run from LaunchAgents or LaunchDaemons could get into difficulties without the kext. Good uninstall scripts should deal with this thoroughly without you having to resort to looking for yourself.

Kexts are now unloaded using a command of the form
sudo kmutil unload -b [bundle-identifier]
or
sudo kmutil unload -p [bundle-path]
where bundle-identifier is a reverse URL like com.highpoint-tech.kext.HighPointRR, or the bundle-path is similar to /Library/Extensions/HighPointRR.kext. kmutil is the replacement for the old kextunload command. Although you could still use the latter, it will merely call kmutil to do its work.

With the kext unloaded, you can then delete it from its accessible location in /Library/Extensions. macOS controls its own staged copy in /Library/StagedExtensions, which it ultimately may get around to removing as well. If you want to remove all kexts from the staging directory, use the command
sudo kmutil clear-staging
although that will also clear any that you might still need, and could require those to be reinstalled.

With those cleared away, you’re ready to restart, which should trigger macOS to rebuild the auxiliary kext collection containing third-party kexts before they’re loaded during the restart. If the auxiliary kext collection isn’t rebuilt correctly, you can force that with the command
sudo kmutil rebuild
and authorising that, followed by restarting the Mac to bring those changes into effect.

You can then check to see if that kext has been loaded using the command
kmutil showloaded --collection aux
to list all loaded kexts in the auxiliary kext collection.

Migration to Apple silicon

Not only is Migration Assistant reluctant to try installing kexts on your new Mac, because of their requirements for use on Apple silicon Macs, it’s unable to enable and load any kexts. However, if you do need to use kexts on an M-series Mac, you’re going to have to enable them first using Startup Security Utility in Recovery Mode, then run the app’s install sequence and authorise them in Privacy & Security settings. That isn’t something that can happen behind your back, and without changing boot security settings no third-party extensions can be loaded. By default, your new Mac should start as clean as a whistle.

Summary

  • This is a good time to clean up old kernel extensions on your Mac.
  • Where possible, follow instructions for their removal provided on their support site.
  • Use an app’s uninstall feature, or its uninstaller, if provided.
  • Manual uninstalls require deletion of apps and code relying on that kext, unloading using kmutil, deletion from /Library/Extensions, and restarting.
  • Don’t worry about what may be left behind in /Library/StagedExtensions.
  • Old kexts can’t be enabled automatically by Migration Assistant for an Apple silicon Mac.

Further reading

Installing a kernel extension (Apple)
Installing system extensions and drivers (Apple)

Should you migrate to your new Mac, and when?

By: hoakley
15 November 2024 at 15:30

Between now and the end of the year, many will be taking on a new Mac, either a brand new M4 model or an older Mac sold or passed on. Before you even think about setting it up, you need to work out how you’re going to move your existing apps, Home folder and media libraries to it. Are you going to trust that to Migration Assistant in macOS? If so, should you do that when first personalising and configuring the Mac, or leave it until later? This article is intended to help you plan that.

What do you want to migrate?

The first important question is what you want to migrate from your old Mac to the new one. If you intend taking across much of what’s on the old one, including all your current user settings, then the best time to do that is when you’re first configuring the Mac, shortly after powering it up. Instead of going through all the steps to create a new user account, migrating at this stage will set that account up for you.

If you’re currently running an older version of macOS, or don’t want to transfer settings from your current user account, then you might do better to delay any migration until later, when you’ve already created yourself a new account and set it up as you want.

If you want to start from scratch, and only move the files and folders you want, then you may prefer to give Migration Assistant a miss, and perform the migration by hand. This is much harder, and even if you think you know what to do, you may well be surprised with the tasks that prove difficult, and those that don’t work at all. Modern macOS is exceedingly complicated and largely undocumented, so it’s easy to omit something important, and waste time trying to move it by hand.

When should you migrate?

Migration Assistant isn’t perfect, and the version of macOS pre-installed on a new Mac inevitably needs to be updated as soon as you can. As a result, in the past I’ve recommended that you delay performing migration until you’ve set up the primary admin account and brought the Mac fully up to date with macOS.

With new M4 Macs, I now recommend that, if you do want to migrate much or all from your old Mac, you do so during initial configuration, rather than later. The first batches of M4 Macs come with the regular edition of macOS Sequoia 15.1, and need to be updated to a newer build number, taking them from 24B83 to 24B2083, which is only for M4 models and VMs. Unlike some previous Macs, the version of 15.1 they ship with is still robust, and its Migration Assistant works well, so migrating early should be robust, if you want to move much of what’s on your old Mac.

If you remain undecided, then don’t forget that you can always migrate later.

What to migrate from

If you’re going to migrate much, you want your new Mac to be connected to the source it’s going to use by the quickest means possible. In practice, that means by Thunderbolt 3/4 if you can, rather than over a regular network. Either connect the two Macs back-to-back with a good Thunderbolt 4 cable, or migrate from a backup on a Thunderbolt 3 SSD, if you can.

Migration from a backup should work correctly whether that backup was created by Time Machine, Carbon Copy Cloner, SuperDuper, or any other good utility. All you need to do is ensure that it was made recently.

iCloud

Just as when migrating iOS and iPadOS devices, sharing using iCloud often proves a major advantage, indeed it may be the only way to fully synchronise the Data Protection keychain that’s shared when you share Keychain in iCloud. Although that’s backed up by Time Machine, restoring or copying it from a backup may not work.

If you don’t normally share your Keychain in iCloud, or other databases such as Contacts and Calendar, consider turning those on and letting them sync fully before migration, as that could save you trouble. Once migration is complete and your new Mac has synced fully, you can always disable their sharing again. If you’re selling or passing your old Mac on, you’ll be disconnecting it from your iCloud account and using Erase All Content and Settings (EACAS) anyway.

Anticipate problems

Migration Assistant, whether used during initial configuration or later, works best when:

  • both Macs are running the same version of macOS (and Migration Assistant);
  • it’s migrating the primary admin user account from your old Mac to the primary admin account of your new Mac;
  • there are no disk errors, damaged folders or files in either source or destination storage;
  • the old user account is entire and doesn’t use any ‘tricks’ in its Home folder.

You do get a choice as to what you migrate, but if you’re going to have to work through that in detail, picking some items and not others, you might find a painstaking manual migration better. If the versions of macOS on the two Macs (or backup) are far apart, then you may find yourself having to work through the new Mac correcting any misunderstandings that arise between the two versions.

If you migrate later, you’ll be given the option of merging from the old account into the current one on your new Mac. If you include settings in that migration, then your new settings will be overwritten by the old ones, and may need further attention once that migration has completed.

Post-migration checks

Once migration has finished, check through all your key settings to ensure they’re just as you want for your new Mac. As far as security is concerned, a quick check with SilentKnight covers key items like FileVault and security data updates. One important setting that I noticed hadn’t been enabled on my new M4 Mac mini was Find My, which takes a bit of searching in System Settings to get right. You should also set aside some time and patience to attend to all the details in Privacy & Security, to ensure nothing is amiss there.

The current version of Migration Assistant does try to migrate the contents of well-known hidden folders including /usr/local, and should copy across any command tools and other files you have installed there. It may not cope so well with more extensive customisation in those hidden folders, though, and you should check those locations carefully following migration.

Migration mess

Very occasionally, Migration Assistant is like a bull in a china shop, and creates havoc, or fails to complete. Allow time so that you can work out how best to resolve that. If the worst comes to the worst, don’t be afraid to start from scratch with a clean install of macOS and an empty Data volume.

Pulling tricks

Old methods of instant migration using volume clones only work with old versions of macOS, prior to Big Sur or even Catalina. While you might get away with using them now, they often cause fundamental problems. Bite the bullet and take the easy way by migrating properly, so your new Mac gets off to the right start.

I wish you fair winds and success!

See also

Migrating to a new Mac, and claiming Time Machine backups
Apple Support

Migrating to a new Mac, and claiming Time Machine backups

By: hoakley
12 November 2024 at 15:30

Over the last few years, Migration Manager in macOS has improved considerably, and when used wisely it can save you a great deal of time getting you new Mac up and running. This article explains how you can use it in Sequoia, and how that works with Time Machine and the backups from your old Mac.

There are two occasions when you can transfer your apps, settings and documents using the process of migration: during the initial personalisation and configuration of macOS, or using Migration Assistant at any time later. I always used to postpone that until macOS was set up and brought up to date, but lately I’ve preferred to get this over with first.

This time I faced a more difficult problem: I was replacing my old Mac Studio M1 Max with my new Mac mini M4 Pro, both of which are intended to use my single Studio display. While I could have run one of them headless (without a display connected), Migration Assistant expects both Macs to be used interactively, which would have required some cunning juggling. Instead of opting to connect them back-to-back, I therefore chose to migrate during initial setup from the Studio’s last Time Machine backup. As the backup storage for my Studio was a Thunderbolt 3 external SSD, this proved surprisingly quick.

Migration during setup

Before unboxing your new or previously owned Mac, prepare the source for migration, and any cable required to connect that Mac with the source. Migrating from a backup is here one of the simplest and fastest options, as all you need do is move your old Mac’s external backup storage over to the new Mac.

In the past, migration used the fastest connection available between two Macs that were connected back-to-back, but Apple’s current support note now states that Wi-Fi will be used. In my case, given that both Macs have 10 GbE, that could have been a disappointment if they were already connected by Ethernet cable.

Another important step is ensuring that your new Mac has a keyboard and mouse/trackpad. As I was moving those from my Studio, I connected both to the new Mac mini by their charging leads to ensure they’d work and pair correctly.

Unbox your Mac, connect it up to your migration source, its new keyboard and mouse/trackpad, then start it up. When the setup sequence reaches the Migration Assistant screen, select the migration source.

tmmigrate

If you’re migrating directly from your old Mac, at this point you’ll need to open Migration Assistant on that Mac and set it to migrate to another Mac. Follow the prompts to continue the process.

Migration after setup

Initiate this by running Migration Assistant in /Applications/Utilities, and follow its prompts to select and connect to the source as above.

Time Machine backups

Assuming that your old Mac made Time Machine backups, and you want your new Mac to continue doing so, now’s the time to connect that backup storage, if it wasn’t already used as the migration source. When you do, you’ll be offered two options, to claim the existing backups for the new Mac, or to leave them for the old one.

tmbackupclaim

You should see this dialog if:

  • you have migrated settings from an old Mac to this one,
  • you have migrated settings from a Time Machine backup of another Mac to this one,
  • you cloned the boot volume group used to start up your Mac,
  • your Mac’s logic board has been replaced.

If you claim the existing backups for your new Mac, then they’ll be used as part of its backup history, but you won’t be able to use them with the old Mac. You may prefer to leave those old backups as they are, and gradually delete them to free up space. Provided that you create the new backup volume for your Mac in the same container, old and new backups will share the same free space on your backup storage.

This apparently replaces the old tmutil inheritbackup command, which no longer appears to work with backups to APFS.

Postscript

I am very grateful to Csaba Fitzl for two useful pieces of information:

  • In macOS Sequoia 15.1 at least, tmutil inheritbackup does work again, when entered with the path to the backup volume, e.g. /Volumes/[TMDISK].
  • Claiming old backups is only offered when migration has taken place. If you set up your new Mac without migrating, it doesn’t appear to be offered, although you should then be able to use tmutil inheritbackup instead.

As Nicolai points out in the comments below, Apple’s support note is incorrect about migration only using Wi-Fi connections to another Mac. This should work as it always has, and select the fastest connection between them, which could include back-to-back Thunderbolt.

❌
❌