Installing macOS and Linux, and what is genuinely different on first boot

Why this matters

This exam is not a macOS exam or a Linux exam, and it does not pretend to be. What it does expect is that you are not helpless in front of either — that you can reinstall macOS, install a Linux distribution, and recognise the handful of places where each behaves differently from Windows in a way that changes what you do.

The differences that matter are few and specific: how each system recovers itself, how software is installed, how disks are laid out, and what a dual-boot machine does to the boot process. Everything else is a different set of words for the same ideas, and treating it as more than that is how people convince themselves these systems are harder than they are.

The lesson

macOS recovery, reinstallation, and the firmware password that blocks it

macOS carries its own recovery environment, which makes reinstallation a different experience from Windows.

Recovery is started by holding a key combination at power-on — the exact combination depends on the processor generation, and the machine's own support page is the authority. It offers four things: restore from a Time Machine backup, reinstall macOS, open Safari for help, and Disk Utility.

Reinstalling from recovery keeps user data. This is the equivalent of a Windows repair install and it is the right first answer for a macOS machine with system-level problems.

Internet recovery downloads the recovery environment rather than using the local one, which is what you need when the disk has been erased or the recovery partition is damaged. It requires a network the firmware can use, which in practice means a normal wireless network with a simple password rather than one with a captive portal.

The firmware password is the part that catches people out. When set, the machine refuses to start from any device other than its designated one and refuses to enter recovery, and the prompt gives no route around it. It cannot be cleared by resetting anything, and the only legitimate route is the vendor with proof of ownership. A second-hand machine that will not enter recovery is usually this, and it is the honest answer to give a customer.

Linux installers, the partition step, and swap in a world with enough RAM

Linux installers are graphical and unremarkable until the partition step, which is where the real decision is.

Most installers offer three options: use the whole disk, install alongside an existing system, or do it manually. The first two are safe and self-explanatory. Manual partitioning is where the vocabulary changes:

• Mount points rather than drive letters. There is one tree, and a partition is attached at a point in it: / for the root, /home for user data, /boot/efi for the EFI system partition on a UEFI machine.
• Separating /home is the equivalent of a separate data partition, and it has the same appeal and the same limitation — reinstalling the system leaves user files alone, and it is still not a backup.
• File system choice is offered and the default is almost always right.

Swap is the part where old advice persists long after it stopped being true. The historical rule of "twice your RAM" came from machines with 256 MB of memory. On a machine with 8 or 16 GB, a small swap area or a swap file is plenty, and its job is mostly to let the kernel move genuinely idle pages out of the way rather than to substitute for memory. The one case that still needs swap at least as large as RAM is hibernation, because the memory image has to go somewhere.

Package management as the thing Linux does instead of installers

The largest practical difference between Linux and Windows is not the desktop; it is where software comes from.

On Windows the normal route is to find a vendor's site, download an installer, and run it — which means judging the site, the installer and the vendor every time. On Linux the normal route is a package manager drawing from a repository: a curated, signed collection maintained by the distribution. You ask for a program by name and it arrives with its dependencies, verified.

What that changes for support work:

• Installing is one command or one click in a software centre, and it rarely fails in interesting ways.
• Updating covers everything at once — the system and every application — rather than each application updating itself.
• Removing is clean, because the manager knows every file it installed.
• Dependencies are resolved for you, and the failures you do see are usually conflicts between repositories rather than missing files.

The two families worth recognising by name: Debian-derived systems (including Ubuntu) using apt, and Red Hat-derived systems (including Fedora) using dnf. Newer cross-distribution formats bundle an application with its dependencies, which trades disk space for not caring which distribution you are on.

The security point is the one to carry into the security objectives: software from the distribution's repository has been through a process. Software from a script someone posted has not, and "curl this URL and pipe it into a shell" is the Linux equivalent of running an unsigned installer from a search result.

Dual boot: the bootloader, the order it is written, and how it gets broken

A dual-boot machine has one firmware, one boot order, and two operating systems that both believe they own the boot process. That is the entire source of the trouble.

The bootloader — GRUB on most Linux systems — is written during installation and offered a menu of what it found. Order matters: installing Windows after Linux typically overwrites the boot entry with Windows' own, and the Linux installation vanishes from the menu even though it is entirely intact on disk. Installing Linux after Windows normally produces a working menu with both.

So the rule is Windows first, then Linux, and if that order cannot be followed, the repair is to boot the Linux installation media in live mode and reinstall the bootloader.

Two more things break it:

• Firmware updates sometimes reset the boot order or clear boot entries, and a machine that dual-booted last week and now goes straight to Windows has usually had exactly that happen.
• Fast startup on Windows does not fully shut the machine down; it hibernates the kernel. A Linux system that then mounts the Windows partition can corrupt it, and Windows can behave oddly when it resumes. Turn fast startup off on any dual-boot machine — this is the single most useful piece of dual-boot advice there is.

First-boot tasks each system expects that Windows does not

Each system expects a few things on first boot that Windows does not, and skipping them produces support calls a week later.

macOS:

• Sign in to the vendor account, because activation lock and several recovery routes depend on it.
• Set up Time Machine to an external disk. macOS makes this genuinely easy and users still do not do it unprompted.
• Decide about FileVault. It is offered during setup and it is much easier to enable then than to retrofit.

Linux:

• Run the update command immediately. The installation media is a snapshot and is usually weeks or months behind.
• Install the restricted or additional drivers if the machine needs them — graphics and wireless are the usual candidates, and the machine that cannot reach the network to download its own network driver is a real scenario.
• Check that the firewall is enabled, which is not always the default.

Both:

• Confirm the machine has a name you can recognise on a network.
• Confirm the time zone and clock, because certificate errors caused by a wrong clock look like broken websites and waste a lot of time.

None of this is exotic. It is the same first-boot checklist Windows gets, with different names on the steps — and noticing that is most of what this objective is teaching.