What happens when you turn on a computer
Between the button and the desktop there is a chain of handovers, each one waking up something slightly more capable than itself. Nothing on your screen exists yet; the machine has to build the conditions for its own software to run.
You press the button
The power button is not a switch. It is a doorbell — a momentary contact wired to a chip that has been quietly awake the whole time your computer was “off”, waiting to be asked.
Something was always on
As long as the machine is plugged in and the switch at the back is up, the power supply keeps one low-power rail alive: +5 V standby. That is what powers the chip listening to the button, the network card waiting for a wake-on-LAN packet, and the glow on the front panel. Pressing the button simply pulls a signal called PS_ON low, and the supply is asked to bring up everything else.
Why holding the button for five seconds is different
A short press is a request, passed to the operating system as an event — which is why your computer can politely shut down, or ignore you entirely if it is busy. Holding the button bypasses all of that: it tells the power management hardware to drop PS_ON regardless, cutting the main rails instantly. Nothing gets saved, nothing gets tidied. It is the electrical equivalent of pulling the plug, and it is why it should be the last thing you reach for.
Laptops and phones do the same thing differently
There is no big supply with one PS_ON line — instead a power management IC brings up a dozen separate rails in a precise order, each with its own voltage and its own dependency on the one before. The principle is identical: nothing is allowed to run until the thing it depends on is stable and has said so.
The takeaway “Off” was never off. The machine has been listening on standby power the whole time, and the button only asks it to start the sequence properly.
The firmware wakes up
The processor comes out of reset knowing nothing — no operating system, no drivers, and, remarkably, no usable memory. Its very first instruction comes from a small flash chip on the motherboard, and everything from here is bootstrapping.
Teaching the memory to work
Modern RAM is not simply switched on. The memory controller has to train it: sweeping voltages and nanosecond-scale timings, writing patterns and reading them back, until it finds settings that work reliably on this particular board with these particular sticks at this temperature. On DDR5 that can take twenty or thirty seconds. It is why the first boot after fitting new memory feels broken — and why the result is cached, so the next boot is quick.
POST, and the noises it used to make
The power-on self test checks that the basics are present and responding. Historically it reported failures through the one output device guaranteed to exist: a speaker. One beep meant all well; patterns of beeps meant no memory, or no graphics card. Modern boards replaced that with diagnostic LEDs or a two-digit code display, which is far more useful — if a machine shows a POST code and stops, that code names the component that failed.
UEFI is a small operating system in its own right
Old BIOS was 16-bit, limited to a 512-byte boot sector and about a megabyte of addressable space. UEFI replaced it with something much larger: it can read FAT filesystems, has a driver model, a shell, a graphical settings interface, network support, and its own persistent variable storage on the flash chip. That is what makes signed boot images and firmware update tools possible — and it is also why a modern firmware is complex enough to have its own bugs and its own updates.
The takeaway The firmware's whole job is to turn a pile of inert components into a usable computer, and then get out of the way. It does not know what an operating system is — only how to find and start one.
Choosing what to boot
The firmware now has working hardware and a list. It goes down that list looking for something it is allowed to run, finds a file on a disk, and loads it. That file is a bootloader — a program whose entire purpose is to start another program.
The old way, and why it was replaced
Legacy BIOS booting had no concept of files. It read the first 512 bytes of a disk — the master boot record — and jumped into it. In that half a kilobyte you had to fit both a partition table and enough code to find and load the rest of your bootloader, which is why GRUB had to be scattered in fragments across the gap before the first partition. It worked for thirty years, but it could not be signed, could not handle disks over 2 TB, and broke if anything overwrote those bytes.
What the bootloader actually does
- Offers a choice, if there is one — the menu you see when a machine dual-boots, or when a previous boot failed.
- Loads two files into memory: the kernel, and a small initial filesystem to go with it.
- Passes parameters — a command line telling the kernel which disk holds the real system, whether to show boot messages, and any options you have added.
- Hands over control completely. The bootloader exits. It is not running underneath your operating system; it is gone.
Where people get stuck
Almost every “it will not boot” problem at this stage is one of three things: the boot order points at the wrong disk, the boot entry points at a file that has been deleted or renamed by an update, or the ESP has been wiped by reinstalling something. None of them are damage to your actual data — which is why reinstalling a bootloader so often rescues a machine that looks completely dead.
The takeaway The firmware never knows what an operating system is. It knows how to run one small file, and it trusts that file to know what comes next.
The kernel takes over
This is the handover that matters. The kernel is the part of the operating system that owns the hardware — memory, processors, devices — and from the moment it starts, everything else on the machine runs at its pleasure.
The chicken-and-egg problem
To read your disk, the kernel needs a driver for your particular storage controller. That driver is a file — stored on the disk it cannot yet read. Shipping every possible driver inside the kernel would make it enormous, so instead the bootloader hands over a second file: the initramfs, a small compressed filesystem that is unpacked into memory and used as a temporary root.
Inside it is exactly the minimum needed to reach the real system: the storage driver, tools to assemble a RAID array or LVM volume, and the code that asks for your disk encryption passphrase. Once the real root filesystem is mounted, the kernel switches onto it, the temporary one is discarded, and the first real program — process number 1 — is started.
What the kernel does before any of that
- Decompresses itself. The kernel ships compressed; the first code that runs is a small stub that unpacks the rest.
- Takes over memory. It builds the page tables that will later let every program believe it has the machine to itself.
- Starts the other processors. Only one core is running until now; the rest are woken and brought into the scheduler.
- Enables interrupts and the scheduler. From this point, more than one thing can happen at a time.
- Probes devices. Every message scrolling past on a Linux boot screen is this — the kernel finding things and attaching drivers to them.
Windows does the same in different words
bootmgfw.efi is the bootloader; winload.efi plays the initramfs
role by loading the kernel and the drivers marked boot-critical;
ntoskrnl.exe is the kernel; and smss.exe — the session manager
— is the first process, the equivalent of PID 1. Different names, identical shape.
The takeaway A kernel panic or a “cannot mount root filesystem” message means the machine got exactly this far and no further — the hardware is fine and the bootloader worked. Something about reaching the disk did not.
Everything else starts
Process number 1 is the ancestor of every other program on the machine. Its job is to start the hundred-odd services that turn a running kernel into something a person can use — and to work out what can safely happen at the same time as what.
What is actually starting
Device management first, because everything else needs to know what hardware exists.
Then filesystems get mounted, logging starts so that later failures are recorded,
the clock is synchronised, networking is brought up, and the graphical login screen is
launched. On Linux this is systemd; on macOS launchd;
on Windows the session manager starts services.exe, which does the same job
with the same dependency logic.
The trick that makes it fast
Socket activation. Rather than start a service and wait for it to be ready, the init system creates the socket that service will listen on, immediately, and starts everything that might want to talk to it. If a client connects before the service is up, the connection simply waits in the queue. Dozens of services that would otherwise have to be strictly ordered can all be launched at once, because their communication channels exist before they do.
The login screen is a lie about progress
It appears as soon as the graphical stack is ready, which is usually well before the
machine has finished starting things. Background services carry on loading behind it,
which is why a computer can feel sluggish for the first thirty seconds after you log in
even though it looked ready much earlier. On Linux,
systemd-analyze blame lists exactly what took the time, and
systemd-analyze critical-chain shows which of those delays were actually on
the critical path — usually a much shorter list.
The takeaway PID 1 never exits. It stays running for the entire life of the machine, restarting things that crash and adopting any process whose parent dies — and shutting down is this same list, run backwards.
Logging in
The machine is running, but it is nobody's machine yet. Logging in does two separate things that are easy to confuse: it proves who you are, and it unlocks the things that were encrypted with your password while you were away.
Your password is never stored
What is stored is a hash — the output of a deliberately slow one-way function, with a random salt mixed in so that two people with the same password get different results. Logging in runs the same function over what you typed and compares. A stolen password file therefore gives an attacker something to grind against offline, not something to log in with, and the slowness of the function is what makes that grinding expensive.
Fingerprints and face unlock do not send a fingerprint anywhere
The sensor talks to a separate secure processor which stores a mathematical representation, never an image, and never releases it. The operating system does not ask “what is this fingerprint?” — it asks “does this match?” and gets back yes or no, plus, on most systems, the release of a key that was sealed to that answer. It is why biometrics unlock a device but cannot be used to log in remotely.
Why a work laptop behaves differently
On a domain-joined machine the check is not local. Your credential is exchanged with a domain controller for a ticket, which is then used for everything else — file shares, email, intranet sites — without typing the password again. That is single sign-on, and it is also why a laptop that cannot reach the corporate network still logs in: it has cached the result of the last successful attempt.
The takeaway Authentication is a question with a yes/no answer. Unlocking is cryptography. Most baffling login problems are the second one failing quietly while the first one succeeded.
Where the time goes
People blame the operating system for slow start-up. On a modern machine with an SSD, the biggest single chunk is usually over before the operating system is even loaded.
“Shut down” often is not one
Windows has had Fast Startup enabled by default for over a decade. When you shut down, it logs you out and then hibernates the kernel session — writing the state of the running system to disk instead of discarding it. Powering on restores that file rather than booting properly.
This is the explanation for one of the strangest support facts there is: restart fixes things that shut down does not. A restart is a genuine full boot. A shut down and power on is a resume, which faithfully restores whatever was wrong. It also explains machines that will not dual-boot cleanly, and disks that look busy to another operating system — because from the computer's point of view, it never actually stopped.
Sleep, hibernate and off
| State | What happens to memory | Power | Wake |
|---|---|---|---|
| Sleep | Kept alive in RAM | A trickle, continuously | A second or two |
| Hibernate | Written to disk, then RAM is emptied | None | Several seconds |
| Shut down | Discarded entirely | Standby only | A full boot |
| Modern standby | Kept in RAM, but the machine keeps working | More than you expect | Instant |
Modern standby is why a laptop can be warm and flat after a night in a bag: it is not asleep in the old sense, it is idling with the screen off, still syncing mail.
The takeaway If you want a machine to be genuinely fresh — after an update, or when something is behaving oddly — choose Restart, not Shut down.
The chain of trust
Every handover in this guide is an opportunity. Whoever controls an earlier stage controls everything after it — so modern machines make each stage check the next one before running it, and keep a tamper-evident record of what was loaded.
Why disk encryption does not ask for a password
On a machine with BitLocker or a similar setup, you are never prompted for a disk passphrase — you just log in normally. The key is not coming from you, it is coming from the TPM, which released it because the boot looked exactly as expected. Your login password protects the running system; the TPM protects against somebody taking the drive out and reading it somewhere else.
It also explains the alarming moment when a routine firmware update, or enabling virtualisation in the settings, suddenly demands a 48-digit recovery key. Nothing is broken and nothing was hacked: a measurement changed, so the seal did not open. This is the system working precisely as designed, and it is why that recovery key needs to exist somewhere other than on the encrypted disk.
The attack all this is aimed at
Give someone ten minutes alone with a powered-off laptop and, without these protections, they can boot it from a USB stick, modify the bootloader to capture your password next time, and put everything back. Nothing on screen would ever look different. The chain of trust exists so that the tampering either cannot run at all, or cannot stay invisible.
The cost of the chain
It is not free. Secure Boot is why some Linux distributions need an extra signed component to start, why self-built kernel drivers may need enrolling by hand, and why older operating systems will not install on a modern machine without turning things off. Whether that is a reasonable price is a genuine argument — but the mechanism itself is sound, and it is what makes an encrypted laptop meaningfully safe when it is lost.
The takeaway Trust in a computer is not a property, it is a chain — and it can only ever be as strong as the first link, which is why that first link is burned into silicon and cannot be changed by anyone, including the manufacturer.
When it goes wrong
A computer that will not start is not one problem, it is eight possible ones — and they are trivially easy to tell apart, because each stage fails in a visibly different way. The only question worth asking first is: how far did it get?
The fixes worth trying, in order
- Remove everything removable. USB drives, docks, second monitors, recently added cards. A machine that boots without them has told you the answer.
- Drain the power. Unplug, hold the power button for thirty seconds, plug back in. This empties the standby rail and clears a surprising number of stuck power states.
- Reseat the memory. The single most common cause of a machine that powers on and shows nothing.
- Read the diagnostic lights or codes. They exist precisely for this, and they name the failing component.
- Reset the firmware settings. If it stopped booting right after a settings change or an update, this reverses it.
- Boot from a USB stick. If a live system runs perfectly, every piece of hardware works and your problem is entirely in software — and your files are almost certainly intact.
One thing worth knowing before you panic
“My computer will not start” and “my data is gone” are unrelated statements. Everything in steps 1 to 5 can fail completely while every file on the disk sits there untouched. Before any drastic repair, take the disk out — or boot a live USB — and copy your files off. Do that first, every time. Recovery is much less stressful when nothing is at stake.
The takeaway You now have nine checkpoints and a way to tell them apart. “It will not turn on” is not a diagnosis — “it powers up but never reaches the bootloader” is one, and it comes with an obvious next move.