Booting from another machine's disk

A retail install of Mac OS X includes all the drivers for all the current supported Mac OS X platforms. So when you put one Mac into Target Mode, and boot 2nd Mac from the 1st Mac's disk, the 2nd Mac will load the appropriate drivers for its configuration.

Where a 'retail install' is when you buy the next major release of Mac OS X and install the software on a Mac, such as going from Leopard to Snow Leopard to Lion to Mountain Lion are all major upgrades and after each of those upgrades the Mac would have had a full set of drivers for all supported Mac hardware.

This will NOT work if you take a newer Mac OS X installation and try to boot a very OLD Mac which is no longer supported. The drivers for a no longer support Mac will not be included.

This may NOT work if you have the original factory installed software on the Mac and try to boot a different flavor Mac, as often times the factory installed Mac OS X version ONLY contains the drivers for that specific Mac.

Firmware is not an issue, as that is part of the Mac, and not part of Mac OS X. The firmware is saved on the Mac's motherboard and goes with the Mac, not the boot disk. The same applies to EFI and SMC

Message was edited by: BobHarris

This question can go arbitrarily deep into bootstrap firmware and designs, and into operating system design, and inherently touches on software licensing.

I'm going to intentionally gloss over some of the details in the following, as this text input box isn't big enough for that, nor to include a computing system architecture course.

I'll also infer that you're probably familiar with Windows and BIOS. (Other operating systems don't have the limits you're apparently accustomed to.) My knowledge of the Windows bootstrap sequence is also dated, so I won't discuss particular details of that here. (And some of what I do mention here may well be stale.)

Windows expects rather little from its BIOS (and BIOS delivers on that), and the Windows installation sets up the bootstrap environment; what drivers and such are loaded. That's an old and simple design and can also make for a fast bootstrap as the operating system bootstrap doesn't have to scan for arbitrary hardware to figure out what drivers and extensions are needed. This design is also fairly good at keeping the installed copies of Windows tied to specific boxes for licensing reasons, but it's obviously not particularly flexible for end users. (Windows can detect and allow some number of changes and allow bootstraps as part of its licensing; it's not fixed at installation time.)

BIOS is probably most charitably referred to as simplistic.

EFI is years newer than and rather more capable than BIOS, and (in its full implementation) offers a command-level shell, and contains "simple" boot-time drivers for accessing various bootable devices. EFI is most charitably called a cryptic environment, but it's quite flexible and (as the E in its EFI name implies) extensible.

EFI also means the OS can use the bootstrap drivers, while the OS is getting going, too. (Though the transition from its bootstrap mode to its configuration and capabilities when the OS is running is, well, decidedly odd and weird. But that's fodder for another day.) EFI contains the aforementioned drivers, the ability to access a GPT partitioned disk device, and a FAT file system, which means it can access the target disk and read data off of it. Without an operating system around. Which can (and usually does) include reading in parts of the OS bootstrap, console or hardware diagnostics, or, well, whatever else the folks working with EFI want or need.

OS X very effectively hides EFI from us end-users. Which, having worked with EFI, is a Good Thing. But I digress.

OS X and various other operating systems can load the necessary drivers and extensions dynamically; during bootstrap. (In the case of OS X, the bootstrap will prefer to boot from the kernel cache when/if that can be located, but will load without it. This caching for boot speed. It's also why you'll see the occasional discussion around invalidating the boot cache, either when hunting a bug, or as happens after a software upgrade.)

Because you can only purchase the hardware from Apple, OS X isn't tied to a specific Apple hardware installation (single box) nor to specific boot devices, and - as is the case with other operating systems - can boot from most any media that EFI can recognize and then access and load the OS X bootstrap from. (This short of performing certain acts I won't further discuss here.) (Search for DSMOS or DSMOSX for some related details.)

SMC is a low-level bit that "controls" certain key portions of the hardware. It's arguably not particularly related to the bootstrap. Well, other than that SMC can and does deal with the state of certain low-level parts of the hardware until the OS is ready to deal with the task. SMC also deals with licensing.

For (far) more (technical) bootstrap details for OS X, see the Apple Kernel Programming Guide documentation The Early Boot Process.

Hmm. Well, two things I think you're not considering:

1. Any software updates installed by the system are stored on disk. If the OS finds itself in a new environment (i.e. booting up a different machine) it is likely perfectly capable of digging out and rerunning any needed updates on the fly.
2. Firmware updates more than almost anything else need to be backwards compatible, because it's a common occurrence for disks to be swapped in and out of different machines. As long as the machine in question is capable of running the OS on the disk, it ought to boot fine regardless of any updates.

That's not really a direct answer to your question, I know, but it does suggest that your question has to have some direct answer otherwise the OS would be unstable.

My question was aimed at finding out if a machine that is booted from a source that contains an updated version of OS X will, somehow, inherit those updates for its own, different, configuration.

No.

Mac A (in Target Mode)

Mac B (booting from disk of Mac in Target Mode)

Mac B's unused boot disk will NOT be updated unless you did something to intentionally change it. So that when you reboot using Mac B's primary boot disk it should still be the same OS version as before.

Mac B while booted from Mac A's disk will behave as Mac A would have. It will be running the Mac OS X version found on Mac A's boot disk.

... as booting from the disc of a machine that has had those updates done, will not result in inheriting them

Mac B's firmware (EFI and SMC) will remain unchanged (unless you intentionally update it), but changing Mac firmware require a special reboot, and is also generally independent from the Mac OS X version.

For the most part a given version of Mac OS X will support the original firmware in any Mac that the version supports.

The firmware is generally changes to improve reliability ot add a new firmware features, such as netboot, holding Option to get a list of boot disks, etc... In rare cases, some new OS feature wants a firmware feature to work correctly but that generally will not prevent the Mac from booting the new firmware.

Ok...

I might infer you're asking these bootstrap- and firmware-related questions as a prelude to some other questions or some other requirements; that you have some other purpose or requirement(s) in mind here that you haven't (yet) mentioned.

What are you really up to here? What problem are you looking to solve? What's some background?

Is this purely an EFI question, or are you looking to deal with (for instance) software distributions and updates?

As for the question you're asking, it makes no sense (to me). There's no difference with the firmware here; the case that you're seemingly concerned about isn't a problem. EFI is forward and backward compatible across various versions (within the limitations of whatever EFI bugs were getting fixed), so old EFI will boot newer operating system bits, and newer EFI firmware will boot older bits. Which leads me to wonder what you're really up to...

...And the firmware only gets updated if somebody explicitly requests that the firmware to be updated.

An upgrade? Ok. So that's your real question.

😉

Boot the DVD (or boot the recovery partition), clone the disk external (for backup), and use Disk Migration to install the software. Target Disk Mode (if you have matching ports) or Time Machine can also be used.

The migration stuff works quite well, and you start with a fresh install that way.

As discussed, you can - if your OS X version is past the version required for the new box (see the caveat below) - simply transfer the disk over, and boot it.

As for the bootstrap, OS X is not the only operating system around that does this, either; that isn't tied to a particular box or configuration. And OS X isn't the only operating system EFI can boot; it's a generic package that's tailored (by Apple, in this case) for specific hardware. A number of other operating systems can detect the configuration and boot, too, and various of these can boot from EFI.

EFI does provide the hardware configuration up to the host operating system (via tables accessed via the ACPI interfaces), but the host then detects and loads that. EFI doesn't tell the host what drivers to load (directly), it tells the host (via ACPI) what hardware is present.

BIOS isn't as fancy as EFI, so the host software can need to probe the hardware to figure out what's present. (Though some BIOS boxes do offer ACPI or "plug and play" (sometimes called "plug and pray"), which makes this configuration process easier on the host operating system and the system hardware vendors.) Various operating systems that boot from BIOS do this, too; they read ACPI or sometimes directly probe the hardware and use this to load the necessary software drivers and extensions. This probing is somewhat time-consuming, so it's something that can be cached.

As for your options, have a look at the innards of OS X; you can see the extensions for the various hardware widgets present on your disk. This is what you're calling option 2. Apple can get away with this packaging because its system hardware is more constrained, where Microsoft can require drivers be downloaded from the vendor, as Windows can encounter all sorts of hardware.

You're making this whole sequence harder on yourself, too. You're overthinking it. Mapping over how Windows or some other operating system or hardware platform does things - it can be easier to forget that, and just learn how OS X works. The goal of an operating system is to boot and work and get out of the way, and with a minimum of fuss for the end-user. Not to cause users to have to go chasing after consoles and devices and downloads and ACPI and BIOS and such. 😉

--

Caveat: the version of OS X installed on a brand-new Mac box can be slightly past the displayed version of OS X, because Apple can add some one-off pieces specific to the new box, meaning that you might need the next dot-release or so after the displayed version before you can migrate the software to the box. If the version you're running is past the first version shipped with the box (HT1159), then you're usually good to go.