# Troubleshooting OS and Software Issues

> Chapter 15 of the Courseiva SERVER-PLUS curriculum — https://courseiva.com//learn/server-plus/troubleshooting-os-and-software-issues

**Official objective:** 3.4 — Troubleshoot operating system and software issues such as boot failures and service problems.

## Introduction

Operating system and software troubleshooting is the systematic process of identifying and resolving failures that prevent a server from starting or running its essential services. For the CompTIA Server+ exam, you must understand the boot sequence, common failure points, and how to diagnose service problems. Mastering this skill turns you from a panicked bystander into the calm IT professional who can get a server back online quickly.

## The Restaurant Kitchen Nightmare Analogy

A restaurant kitchen is a system of interdependent stations and processes. The head chef is the operating system, and each cooking appliance (fryer, grill, oven) is a service. One morning, the kitchen manager arrives and flips the main power switch (presses the power button). The lights come on (POST passes), but the fryer won't ignite—its gas line is blocked. The manager checks the gas valve (service status), sees it's turned on (service enabled), then examines the igniter (log files) and finds a clogged nozzle (corrupted configuration file). She clears the nozzle (modifies the config) and the fryer roars to life (service restarts). Meanwhile, the oven won't start because its pilot light (dependency) is out due to a faulty thermocouple (missing prerequisite service). The manager traces the dependency chain, replaces the thermocouple (installs missing driver), and the oven works. This mirrors server troubleshooting: the OS kernel (head chef) must load before any service (appliance) can run. A boot failure occurs when the chef never enters the kitchen—or the kitchen's layout changed (boot order altered). Service problems are appliances that won't start because of a missing ingredient (dependency) or a broken part (corrupt binary).

## Core explanation

When a server fails to boot or a service won't start, the cause can be hardware, firmware, boot files, operating system components, or application dependencies. Let's break down the normal boot process first, then see where things go wrong.

A server starts by running the Power-On Self Test (POST), which checks basic hardware like memory, CPU, and storage. If POST fails, you'll hear beeps or see error codes—this is a hardware issue, not an OS problem. After POST, the server loads the BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface). BIOS/UEFI identifies the boot device (hard drive, SSD, USB) and hands control to the boot loader.

The boot loader (like GRUB on Linux or the Windows Boot Manager) loads the operating system kernel into memory. The kernel then initialises drivers and starts the init process (on Linux) or the Session Manager (on Windows). Init (often systemd on modern Linux) launches all essential services in the correct order based on dependencies.

A service (also called a daemon on Linux) is a background program that provides a function, such as web serving (HTTP) or database access (SQL). Services have startup types: automatic (starts at boot), manual (started by an admin), or disabled (cannot start). If a service fails to start, the server may still run, but its function is unavailable.

Common boot failures include:
- “Operating system not found”: the boot device isn't detected or the boot loader is missing.
- Kernel panic (Linux) or blue screen (Windows): the kernel encounters a fatal error, often from a bad driver or corrupt system file.
- Stuck at logo: the OS loads but hangs while starting a service, usually due to a dependency loop or corrupt binary.
- Boot loop: the server restarts repeatedly, often after a failed update or driver installation.

Service problems are diagnosed by checking status (systemctl status <service> on Linux, Get-Service on Windows), reviewing logs (/var/log/ on Linux, Event Viewer on Windows), and verifying dependencies. For example, a web server that needs a database service will fail if the database isn't running.

The key troubleshooting methodology is:
- Identify the symptom (server won't boot vs. service won't start).
- Isolate the failure point (hardware, boot loader, OS, service).
- Check logs for error messages.
- Determine recent changes (updates, configuration edits, hardware additions).
- Apply a fix (rollback update, reconfigure, reinstall driver).
- Test and confirm the resolution.

This process is identical whether you're in a server room or a cloud console. Understanding the boot order and service dependencies lets you predict where a failure will manifest and resolve it efficiently.

## Real-world context

Imagine a company runs its customer-facing web application on a Linux server. One morning, employees can't access the website. The IT professional receives an alert saying the HTTP service is down. She tries to SSH into the server, but the connection times out—a boot failure has occurred. She drives to the data centre (or accesses the remote management card) and sees the server is powered on but displays a black screen with a blinking cursor.

Step 1: She checks the monitor output—no POST errors. This rules out hardware failure. Step 2: She reboots and watches the screen; it shows “GRUB loading” then “error: no such partition”. This points to a corrupted boot loader configuration. Step 3: She uses a live USB to boot the server and inspects the /boot partition. The GRUB config file (grub.cfg) is missing. She recovers it from a backup and runs grub-install to reinstall the boot loader. The server now boots normally.

Step 4: Once logged in, she checks the web service status (systemctl status httpd) and finds it's dead. Logs show “Cannot bind to port 80: Address already in use”. Another process is occupying the port. Step 5: She runs netstat -tulpn to see which PID is listening on port 80. It's an old instance of the web server that didn't cleanly shut down. She kills the zombie process and restarts httpd. The website comes online.

Step 6: To prevent recurrence, she adjusts the service configuration to automatically restart on failure (Restart=always in the systemd unit file) and sets up log monitoring alerts. She also documents the boot loader corruption cause—a recent kernel update that didn't properly update GRUB. The IT team now knows to always regenerate the boot loader configuration after kernel updates.

This scenario shows how boot failures and service problems intertwine. The professional used tools like live USB, systemctl, netstat, and logs. She didn't panic—she followed the systematic troubleshooting path from hardware to OS to service. That's exactly what the CompTIA Server+ exam expects you to do in multiple-choice scenarios.

## Exam focus

The SK0-005 exam tests your ability to identify the cause of a boot failure or service problem from a set of symptoms, logs, and actions. You'll face multiple-choice questions that present a scenario (e.g., “A server hangs after POST and shows a disk error. What is the most likely cause?”) and you must pick the correct troubleshooting step or diagnosis.

Key concepts the exam loves to test:
- The exact order of boot phases: POST → BIOS/UEFI → Boot Loader → Kernel → Init → Services. Questions may ask “At what stage does a missing boot loader cause failure?” The answer is after POST and before kernel loading.
- Differences between BIOS and UEFI: UEFI supports GPT disks and Secure Boot, while BIOS uses MBR. A question might say “A server with a 4TB disk fails to boot after replacing the drive. Why?” The answer likely involves MBR not supporting disks over 2TB.
- Troubleshooting commands: On Linux, systemctl status, journalctl, dmesg, and lsblk. On Windows, Event Viewer, bcdedit, and sfc /scannow. Traps: they might ask “Which tool shows real-time kernel messages?” Answer: dmesg (not /var/log/messages, which is a file, not a tool).
- Service startup types: automatic, manual, disabled, and delayed start (Windows). They love to ask “A service is set to manual but the application requires it to start at boot. What should the admin do?” Change it to automatic.
- Dependency failures: A service fails because its prerequisite service isn't running. The exam might give you a log message “Dependency failed for Service B; Unit Service A not found”. The answer is to start Service A.
- Boot failures due to updates: a recent patch or driver update can corrupt the boot loader or cause kernel panic. The trap is to immediately reinstall the OS—instead, you should roll back the update or boot into safe mode.
- Hardware vs. software: If there's no POST, it's hardware. If POST passes but OS doesn't load, it's boot loader or OS issue. They will try to confuse you with symptoms of a failing hard drive (clicking sounds) vs. missing boot files (silent failure).
- Recovery methods: Windows Recovery Console, Linux rescue mode, live CD/USB. Questions may ask “Which tool allows you to repair the boot sector from a recovery environment?” On Windows: bootrec /fixmbr. On Linux: grub-install.

To prepare, memorise these definitions:
- POST: checks hardware integrity before boot.
- Boot loader: small program that loads the OS kernel.
- Kernel: core of the OS managing hardware and processes.
- Service: background process providing a function.
- Dependency: a service that must run before another can start.

Practice scenario-based questions and understand why each answer is correct or wrong. The exam rarely asks for a single command name without context—they describe a situation and want the logical next step.

## Step by step

1. **1. Identify the Symptom** — Determine if the issue is a boot failure (server doesn't fully start) or a service problem (server is up but a specific service isn't running). This narrows down where to start looking: hardware/firmware vs. OS/application layers.
2. **2. Isolate the Failure Point** — Check POST for beeps or errors. If POST fails, it's hardware. If POST passes but no boot device is found, examine BIOS/UEFI boot order and disk connections. If OS begins loading but hangs or crashes, focus on boot loader, kernel, or init.
3. **3. Examine Logs and Error Messages** — Use built-in tools: on Linux, run dmesg for kernel messages and journalctl -xe for service logs. On Windows, open Event Viewer and look under System and Application logs. The error message often states the root cause, e.g., 'File not found' or 'Dependency failed'.
4. **4. Determine Recent Changes** — Ask yourself or the server's history: Was a new driver installed? Did a system update run? Was hardware added or removed? Were configuration files edited? Recent changes are the most common cause of new failures.
5. **5. Apply a Targeted Fix** — Based on the cause, take action. For a corrupt boot loader, use recovery tools (bootrec on Windows, grub-install on Linux). For a service dependency issue, start the prerequisite service. For a failed update, roll back via recovery console. Always test after each fix.
6. **6. Verify and Document** — After applying the fix, reboot or restart the service to confirm the problem is solved. Document the symptom, cause, and solution in a knowledge base so the same issue can be resolved faster next time.

## Comparisons

### BIOS (Legacy) vs UEFI (Modern)

**BIOS (Legacy):**
- Uses MBR partition table, limited to 2TB disks
- Boot process is simpler, but slower
- Lacks Secure Boot; can boot from any disk without signature verification

**UEFI (Modern):**
- Uses GPT partition table, supports disks over 2TB
- Faster boot and pre-boot networking
- Includes Secure Boot to prevent unauthorised code; requires signed boot loaders

### MBR (Master Boot Record) vs GPT (GUID Partition Table)

**MBR (Master Boot Record):**
- Stored in first 512 bytes of disk; supports up to 4 primary partitions
- Maximum disk size 2TB (some implementations up to 4TB)
- Used by legacy BIOS systems

**GPT (GUID Partition Table):**
- Stored in multiple sectors; supports up to 128 primary partitions
- Maximum disk size 9.4ZB (practically unlimited)
- Required for UEFI boot; includes backup partition table for redundancy

### systemd (Linux) vs SysV Init (Legacy Linux)

**systemd (Linux):**
- Starts services in parallel based on dependencies, faster boot
- Uses unit files for configuration (e.g., httpd.service)
- Commands: systemctl (status, start, stop, restart, enable, disable)

**SysV Init (Legacy Linux):**
- Starts services sequentially in a fixed order
- Uses shell scripts in /etc/init.d/
- Commands: service (status, start, stop, restart); chkconfig for runlevels

### Safe Mode (Windows) vs Single-User Mode (Linux)

**Safe Mode (Windows):**
- Loads only essential drivers and services; no networking by default
- Accessed by pressing F8 during boot (or via recovery environment)
- Used to remove problematic drivers or roll back updates

**Single-User Mode (Linux):**
- Boots to a root shell without starting most services
- Accessed by adding 'single' or '1' to kernel boot parameters
- Used to repair file systems, reset passwords, or disable broken services

### Service Failure vs Application Crash

**Service Failure:**
- A background process stops or fails to start, managed by init system
- Often due to dependency issues, corrupt config, or resource exhaustion
- Logs appear in system logs (Event Viewer, journalctl)

**Application Crash:**
- An application (e.g., web server, database) terminates unexpectedly
- May be caused by code bugs, out-of-memory, or invalid input
- Logs are often in application-specific log files (e.g., /var/log/httpd/error_log)

## Common misconceptions

- **Misconception:** If the server displays a POST error, it's a software problem. **Reality:** POST errors indicate hardware issues (memory, CPU, motherboard). The OS hasn't even started yet. (Beginners assume any failure after power-on is OS-related, but POST failures are clearly hardware and require component replacement.)
- **Misconception:** Restarting a service always fixes it. **Reality:** Restarting only clears a temporary fault. If the underlying problem (bad config, missing dependency, resource exhaustion) persists, the service will fail again immediately or soon after. (It's a quick fix in the moment, so beginners think it's a permanent solution. The exam tests whether you dig deeper.)
- **Misconception:** If the server boots to a black screen, the OS is corrupted. **Reality:** A black screen after POST can be caused by a failed GPU, incorrect display cable, or a boot loader that can't find the kernel. OS corruption is only one possibility among many. (Beginners jump to the most dramatic conclusion. The exam expects systematic isolation—check video output, boot order, and boot loader first.)
- **Misconception:** All services set to 'automatic' start at boot time. **Reality:** On modern systems, services with 'automatic' start are only started when their dependencies are met. If a required service is missing or delayed, an automatic service may not start. (People assume 'automatic' is a guarantee. But dependency ordering and startup failures can prevent it, which the exam likes to test.)
- **Misconception:** A boot loop always means a hardware fault. **Reality:** A boot loop can be caused by a corrupt boot loader, failed OS update, or driver that causes the kernel to panic and reboot. It's often software-related. (The repeating restart feels like a hardware failure, but software issues (especially after updates) are common causes. The exam wants you to consider safe mode or recovery console.)

## Key takeaways

- The boot sequence is fixed: POST, BIOS/UEFI, boot loader, kernel, init, services—each stage has distinct failure symptoms.
- Service dependencies are chained; a service won't start if its prerequisite is missing or failed.
- Logs (Event Viewer on Windows, /var/log on Linux, systemd journal) are the first place to look for failure details.
- A boot failure after a recent update or driver change should be resolved by rolling back the change, not by reinstalling the OS.
- The difference between BIOS and UEFI is critical: UEFI supports GPT disks and secure boot, BIOS uses MBR and has 2TB partition limits.
- Troubleshooting must follow a logical order: isolate hardware vs. software, then check logs, dependencies, and recent changes.
- Safe mode (Windows) or single-user mode (Linux) loads only essential services, making it easier to diagnose problematic drivers or services.

## FAQ

**Why does my server show 'Operating System not found'?**

This means the boot loader cannot locate a valid OS on the boot device. Causes include a disconnected data cable, incorrect boot order in BIOS/UEFI, a corrupt master boot record (MBR), or a failed hard drive. Check connections and boot from a recovery media to repair the boot loader.

**What is the difference between BIOS and UEFI?**

BIOS (Basic Input/Output System) is older, uses MBR partition table, and supports disks up to 2TB. UEFI (Unified Extensible Firmware Interface) is newer, uses GPT partition table, supports larger disks, and includes Secure Boot to prevent unauthorised code from loading at startup.

**How do I check if a service is running in Linux?**

Use the command 'systemctl status <service-name>' (e.g., systemctl status httpd). It shows whether the service is active, inactive, or failed, along with recent log entries. On older Linux, you can use 'service <service> status'.

**What does 'dependency failed' mean in systemd?**

It means the service you're trying to start requires another service (a dependency) that is not running or has failed. Use 'systemctl list-dependencies <service>' to see the chain, then start the missing prerequisite service first.

**How can I fix a boot loop after installing new hardware?**

Boot into safe mode (Windows) or single-user mode (Linux) to load minimal drivers. If the system starts, remove or disable the driver for the new hardware. If safe mode doesn't work, use a recovery environment to roll back recent driver changes via Last Known Good Configuration (Windows) or kernel parameter edits.

**What is the purpose of Event Viewer in Windows?**

Event Viewer is a tool that logs system, security, and application events. When a service fails or a boot error occurs, it records error codes and descriptions. Look under Windows Logs > System for service-related errors, and under Applications and Services Logs for specific software issues.

---

Interactive version with quiz and diagrams: https://courseiva.com//learn/server-plus/troubleshooting-os-and-software-issues