M48 - Boot & Startup
Boot & Startup
Explain the major boot stages on Windows and Linux and use a few practical tools to investigate slow or unhealthy startup behavior.
- Explain the major boot stages on Windows and Linux and use a few practical tools to investigate slow or unhealthy startup behavior.
Boot Is a Sequence, Not a Single Event
When a machine boots, several layers hand work to the next layer.
If startup fails or feels slow, it helps to ask:
- did the firmware find the boot device?
- did the bootloader hand off to the kernel?
- did the service manager start the system cleanly?
- did user-facing services or the desktop become ready?
That way of thinking matters more than memorizing one vendor-specific screen.
1. A Practical Boot Sequence
The details differ between Windows and Linux, but the broad pattern is similar:
- firmware starts and performs hardware checks
- firmware finds a boot entry or bootloader
- the operating system kernel loads
- the system starts core services
- the login environment becomes available
Examples:
- firmware: BIOS or UEFI
- bootloader: Windows Boot Manager or GRUB
- service stage: Windows startup subsystems or Linux
systemd
If you know which stage likely failed, your troubleshooting gets much narrower.
2. Windows: Startup State and Recent Boot Information
Windows learners should know two practical ideas:
- how to check when the system last booted
- how to reason about “shut down” versus “restart”
Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object LastBootUpTime
Modern Windows systems may also use Fast Startup. That can make a normal shut down behave differently from a full restart, which is one reason a restart sometimes clears problems that a shut down does not.
Linux exposes more direct startup timing through systemd-analyze.
3. Linux: Inspecting Boot Time with systemd-analyze
On Linux systems using systemd, you can inspect how long boot took and which services contributed most.
systemd-analyze systemd-analyze blame systemd-analyze critical-chain
These answer slightly different questions:
systemd-analyzegives overall timingblameshows which units took the longestcritical-chainshows the dependency path that delayed readiness
That makes boot troubleshooting more concrete than “the server feels slow.”
4. Recovery and Reduced Startup Modes
Sometimes the goal is not a normal boot. The goal is a boot simple enough to repair the system.
Windows recovery options and Safe Mode reduce the number of drivers and services involved, which helps when a normal startup path is broken.
Linux uses targets such as multi-user.target or rescue-oriented modes to change how much of the system starts.
sudo systemctl isolate multi-user.target sudo systemctl set-default multi-user.target
These are repair tools, not everyday commands. Use them when you understand why you need a reduced startup path.
Look for the Slow Stage, Not Just the Slow Boot
”Boot is slow” is only a symptom. A better question is whether the delay is happening before the kernel, during service startup, or while the user environment is loading. That framing leads to much better troubleshooting.
What You Just Learned
- Boot is a chain of stages rather than one monolithic event.
- Firmware, bootloader, kernel, service startup, and login readiness each play a different role.
- On Windows, checking recent boot time and understanding restart behavior gives useful context.
- On Linux,
systemd-analyzehelps you see which units delayed startup. - Recovery modes matter because they reduce the startup path when a normal boot is unhealthy.
Next, you will look at updates and patching, where reboot planning and service impact become even more important.