Boot media, partition schemes, and the choices you cannot undo later

Why this matters

Most of an installation is reversible. A wrong edition can be upgraded, a wrong account can be replaced, a wrong driver can be rolled back. Two decisions made in the first five minutes are not: the partition scheme and the firmware mode the machine will boot in. Changing either afterwards means starting again, and on a machine with data on it that is an expensive afternoon.

The exam knows this, which is why the boot and partitioning questions are disproportionately scenario-shaped: a machine that will not see its installation media, a disk that refuses a partition larger than two terabytes, an installer that offers only one drive. Each of those has a single cause, and each cause is a choice somebody made before anything was installed.

The lesson

Creating installation media, and why the tool matters more than the stick

Creating installation media is four clicks and one real decision, and the decision is which tool makes it.

The stick itself is not interesting — any reasonable 8 GB or larger USB drive works, and paying more for a faster one shortens the install by minutes. What matters is how the tool writes it, because the tool decides the partition scheme and the file system of the media, and those decide whether the firmware can see it at all.

• The vendor's own tool (Microsoft's media creation tool, Apple's recovery route, a distribution's recommended writer) produces media that boots on the widest range of firmware, and it is the right default.
• A general-purpose writer gives you control over scheme and file system, which you need when the vendor's tool produces media a particular machine will not boot.
• Copying the ISO onto a stick as a file does nothing. The stick must be made bootable; the image must be written, not stored.

One trap is worth knowing because it wastes hours. Windows installation media formatted as FAT32 cannot hold a file larger than 4 GB, and some Windows images contain one that is. Media formatted as NTFS can hold it, but some UEFI firmware will not boot NTFS. The tools that work around this split the large file or ship a small FAT32 boot partition alongside an NTFS data partition — which is why the vendor tool is the default, and why a hand-made stick that "looks fine" sometimes is not.

MBR against GPT: the limits of each and which firmware expects which

A disk has to record where its partitions are, and there are two schemes for doing that.

MBR is the older one, and its limits are the examinable part:

• A maximum addressable disk size of about 2 TB. A 4 TB disk initialised as MBR shows roughly 2 TB and the rest is unreachable.
• Four primary partitions, or three plus an extended partition containing logical drives.
• The partition table exists in one place, at the start of the disk, with no copy.

GPT is the modern one:

• Disk sizes far beyond anything you will meet.
• 128 partitions as standard, with no primary/extended distinction.
• The partition table is written at both ends of the disk and checksummed, so damage to one copy is recoverable.

Which firmware expects which is the part that causes real failures. UEFI firmware boots Windows from GPT. Legacy BIOS boots Windows from MBR. Mixing them produces the classic symptom: the installer runs, you select the disk, and it refuses with a message about the selected disk having an MBR partition table — or the machine installs happily and then will not boot.

The two rules that resolve almost every case: a disk over 2 TB must be GPT, and a machine booting in UEFI mode wants GPT. Converting between the schemes destroys the partition table, so this is decided before installation, not after.

UEFI, legacy boot and secure boot, and the setting that hides your installer

Firmware has two boot modes and one security feature, and all three appear in fault scenarios.

UEFI is the modern firmware interface. It understands file systems, boots from an EFI system partition, supports large disks through GPT, and boots faster.

Legacy or CSM mode emulates the old BIOS behaviour for operating systems and media that expect it. Many machines can do either, and some can do both at once, which is where the confusion starts.

Secure boot allows the firmware to run only bootloaders signed by a key it trusts. It is a genuine security control — it is what stops a bootkit persisting below the operating system — and it is also the single most common reason an installer does not appear in the boot menu.

The fault this produces looks like broken media and is not. A USB stick carrying a Linux distribution, or an older Windows image, or a recovery tool, is written correctly and simply does not show up. The firmware is refusing to offer it because it is unsigned, or because the stick is MBR and the machine is in UEFI-only mode.

The order to check, and it is worth memorising because it is a stock exam scenario:

1. Is the machine set to UEFI-only, and is the stick GPT/FAT32?
2. Is secure boot on, and is the thing you are booting signed?
3. Is the stick in the boot order at all, and did you use the one-time boot menu rather than the saved order?

Turn secure boot back on afterwards. A machine left with it disabled because an installer needed it once is a machine with a control switched off for no current reason, and that is the kind of thing the operational procedures objective expects you to notice.

Partitioning during setup: system, recovery and data, and what each is for

Left alone, a Windows installer creates several partitions on an empty disk and does not explain any of them. Knowing what each is for makes recovery scenarios much easier to reason about.

• EFI system partition — small, FAT32, holds the bootloader. On a UEFI/GPT machine this is what the firmware actually starts. Delete it and the machine boots nothing, even though the operating system is entirely intact.
• Microsoft reserved — a small working area with no drive letter. It is not interesting and should not be touched.
• Windows / primary — the operating system and, by default, everything else.
• Recovery — holds the recovery environment. If it is missing or undersized, feature updates may fail or recreate it, and the recovery environment may not be available when it is most needed.

The one genuine choice is whether to separate data from the operating system. A separate data partition means a clean reinstallation does not touch the files, which is convenient. It is not a backup — it is on the same disk, and it shares every failure mode that disk has — and it introduces its own problem, which is deciding how large to make each part before you know how the machine will be used.

For a single personal machine, one Windows partition plus the ones the installer makes is a defensible default. For a machine that will be rebuilt regularly, separating data earns its keep. Either answer is fine as long as you can say why you chose it.

Network and image-based installation, and where a technician meets them

Two installation methods exist that a support technician meets without usually being the person who built them, and the exam expects you to recognise them.

Network installation (PXE boot) has the machine ask the network for its boot image rather than reading one from local media. The firmware requests an address, a DHCP server points it at a boot server, and the machine downloads and runs an installer. Where you meet it: a machine that has been reimaged by pressing a key at power-on, or a machine that unexpectedly starts an installation because it booted from the network before its own disk.

Image-based installation captures a fully configured machine — operating system, applications, settings — into a file and applies it to other machines. Where you meet it: an estate where every machine is identical and rebuilding one takes fifteen minutes.

Unattended installation sits between them. An answer file supplies the choices the installer would ask a human for, so setup runs to completion without anyone watching.

What a technician needs from this, practically:

• Recognise the symptom of a machine booting from the network by accident, and know it is fixed in the boot order.
• Know that an imaged machine's problems are often the image's problems, so the question "does this happen on a freshly imaged machine too?" is a fast and powerful one.
• Know that a machine which will not image is usually failing on drivers, firmware mode, or the network, in that order.

Building the deployment infrastructure is not this exam's scope. Recognising where a machine came from, and what that implies about its faults, is.