“K64″ is what Apple refers to as the 64-bit version of the kernel beginning with Snow Leopard. As an end user, you really should not worry about the bitness of the kernel. If your Apple computer is not booting into K64 by default, you don’t need it—unless, of course, you know that you need it. (Say, because you are a kernel developer or an otherwise system-level developer and want to test something against a 64-bit kernel.) In particular, the 32-bit kernel, which is the default on most existing x86-based Apple computers, runs 64-bit applications just fine. Therefore, as long as you have a 64-bit processor, your Snow Leopard installation is 64-bit from the typical end-user standpoint.
An easy way to tell if you are running a K64 kernel is to use the
uname command-line program. The "x86_64" in the excerpt below means that we are running a 64-bit kernel. If the output showed "i386" instead, that would mean a 32-bit kernel.
$ uname -a Darwin... root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64
If you are averse to using command-line programs (Do you really care about a K64 kernel in that case?), you could instead launch the System Profiler application, either directly, or by clicking on "More Info…" in the "About This Mac" panel. In System Profiler, you can click on the "Software" section in the sidebar. There will be something about the presence or absence of 64-bit Kernel and Extensions. You could also launch the Activity Monitor application and look for
kernel_task. The "Kind" column will say if the kernel task (and consequently the kernel) is 64-bit.
As alluded to earlier, a 64-bit processor is required to run a K64 kernel. To boot into K64, you could do one of several things:
- Press the
4keys simultaneously at power-on time. This indicates to the EFI boot loader (
boot.efi) that you wish to boot a 64-bit kernel.
- Set the
boot-argsfirmware variable, say, through the
nvramcommand-line program. To boot K64, the specific command-line would be:
$ sudo nvram boot-args="arch=x86_64"
arch=x86_64to the value of the
Kernel Flagskey. By default, this value is an empty string.
$ cat /Library/Preferences/SystemConfiguration/com.apple.Boot.plist ... <dict> <key>Kernel</key> <string>mach_kernel</string> <key>Kernel Flags</key> <string>arch=x86_64</string> </dict> ...
Another way is to use the
-setkernelbootarchitecture argument of the
systemsetup(8) command-line program.
Additionally, you could tell the kernel to boot verbosely if you are interested in catching a 64-bit boot early on. Note that one of the early kernel messages is "64 bit mode enabled". This does not mean K64—it just means the kernel has identified the processor to be 64-bit and is going to use certain 64-bit features. In the case of a K64 boot, the message to look for is "Kernel is LP64".
Not so fast though.
Unfortunately, a 64-bit processor alone doesn’t suffice. Out of the box,
boot.efi will not boot K64 even if you have a 64-bit processor and explicitly request K64 if at least one of the following is true.
- The machine has 32-bit EFI.
- The machine’s model is prohibited from booting K64 through a hardcoded list within the boot loader. (A cursory look suggests that the list excludes "non-Pro" machines.)
Both of these "limitations" are technically artificial, albeit to different degrees.
The first limitation actually does have merit and is arguably not all that artificial. Although a 32-bit EFI could launch a 64-bit kernel, the kernel, when running, would not be able to use firmware services. In particular, you wouldn’t have NVRAM. For kernel developers merely wanting to run a 64-bit kernel for testing and debugging, this may not be an issue, but it’s understandable why the limitation is in place.
The second limitation is annoying. As a developer, if you knowingly wish to boot into K64 to test something, you can’t on certain machines even though they are technically perfectly capable. I ran into this on a Unibody MacBook, which has 64-bit EFI but is not a "Pro" machine. Also, it’s ironic that you can, in fact, boot Snow Leopard into K64 on the very same computer when you run it as a guest operating system in a virtual machine.
If you really need to boot into K64 on such a machine with 64-bit EFI, you can—at your own peril—"fix" things within
boot.efi by setting the appropriate bits in the hardcoded list of models. To ensure that we’re talking about the same multiarchitecture version of
boot.efi, compare the SHA-1 checksum of that file.
$ shasum boot.efi 2fb9fc10e5b4bb06f62c38b01bd9836a433897f8 boot.efi
Then, change the 1 byte at the corresponding model-specific position in the following table to the corresponding new value. Rather than overwriting the original
boot.efi, we will copy the original to a new file, say,
boot-k64.efi, and edit the latter.
|Model (with 64-bit EFI)||Byte Position in boot.efi||Old Value||New Value|
For the specific case of the MacBook, which is the only one I've actually tried, the before and after bytes will look like the following:
We'll place the
boot-k64.efi file somewhere on the root volume—
/System/Library/CoreServices/ is fine. Then, we need to reset volume bootability through the
bless command-line program. Optionally, we can also set the ownership and user immutable flag on the file to "proper" values.
$ sudo cp boot-k64.efi /System/Library/CoreServices/ $ cd /System/Library/CoreServices/ $ sudo chown root:wheel boot-k64.efi $ sudo chflags uchg boot-k64.efi $ sudo bless --folder /System/Library/CoreServices \ --file /System/Library/CoreServices/boot-k64.efi
Your mileage may vary depending on whether your installation has 64-bit versions of all necessary drivers for the model of your specific machine. Since I have not tried any other "excluded" machine besides a 64-bit MacBook, I don't know about other models. (Unavailability or instability of certain 64-bit drivers could be a plausible reason for these models to be excluded in the first place.)
If you do render your system unbootable, you can simply run
bless again to restore volume bootability as it was before. That is, you can tell
bless to use the original
boot.efi. Of course, to do that, you'll need to either boot from a different volume (a system install disc would be fine), or be able to access and write to the unbootable volume from another computer.
$ sudo bless --folder /Volumes/BrokenMac/System/Library/CoreServices \ --file /Volumes/BrokenMac/System/Library/CoreServices/boot.efi