CompTIA A+ Core 2 exam objective 3.3 requires you to troubleshoot common macOS and Linux operating system issues. This chapter gives you a clear, repeatable process for diagnosing problems like a system that won't boot, an application that crashes on launch, or a network connection that has stopped working, regardless of whether you are sitting in front of the computer or managing it remotely.
Jump to a section
A simple way to picture Troubleshooting macOS and Linux Issues
A functioning city depends on a complex network of roads, traffic lights, and utility lines. The network is the operating system. When a road is suddenly blocked by a burst water main, the immediate problem is the blocked road, but the root cause might be a corroded pipe or a mistake by a construction crew working on a different project. Similarly, when a macOS or Linux system fails to start or an application crashes, the visible symptom is just the tip of the iceberg. Troubleshooting is the process of a city's road management team. They don't just tow the car blocking the road; they check the traffic light sequence, look at the traffic camera feeds (system logs), and talk to the utility companies (different system services) to find the real cause. The team has a standard process: first, identify the blocked intersection (the symptom). Second, isolate the area (check if only one road or multiple are affected). Third, check the traffic logs (system logs) for patterns. Fourth, test a temporary fix (a detour) and see if it works. If the detour causes a massive jam elsewhere, they revert it and try a different solution. This city analogy maps precisely to the structured, methodical troubleshooting methodology—always check the simplest things first, gather information before acting, and document every step to avoid repeating the same mistake.
Troubleshooting macOS and Linux issues means using a logical, step-by-step process to identify, isolate, and fix problems. The process is not random guesswork. It is built on a framework called the CompTIA A+ troubleshooting methodology. You will apply this same methodology to Windows, macOS, and Linux systems, but the specific tools and commands differ.
The first stage is always to identify the problem. This is not just noting a symptom. For example, a user says 'My Mac won't turn on.' The symptom is a black screen. The problem could be a dead battery, a failed power adapter, a faulty display, or a corrupted operating system. You must gather information. Ask the user: 'What happened just before it stopped working? Did it make any sounds? Did you see any error messages?' A question like 'Was the laptop plugged in?' is a crucial step. You then duplicate the problem, if possible. If you can reproduce the crash by opening a specific application, that is a huge clue.
The second stage is to establish a theory of probable cause. Based on the information you have gathered, you make an educated guess. For macOS, common causes include: a full startup disk, a corrupted user account, a failed system update, or a damaged third-party kernel extension (a piece of software that adds features to the operating system kernel, often called a 'kext'). For Linux, common causes include: a misconfigured bootloader (the software that starts the operating system), a full filesystem, a faulty systemd service (the system and service manager that starts processes at boot), or incorrect file permissions.
The third stage is to test your theory. You start with the simplest, most likely cause. For a Mac that won't boot, the simplest test is to try starting in Safe Mode (hold the Shift key after the chime). Safe Mode loads only essential system components and checks your startup disk for problems. If it boots in Safe Mode, the cause is likely a conflicting startup item or system extension. For a Linux system that won't connect to the internet, the simplest test is to use the 'ping' command to test connectivity to a known address like 8.8.8.8. If that works, the network hardware is fine. If not, check your network configuration file.
The fourth stage is to establish a plan of action and implement the solution. This might involve running the Disk Utility First Aid tool on a Mac, which checks and repairs the disk's directory structure. On Linux, it could mean using the 'fsck' command (file system check) on a partition, or reinstalling a broken package using a package manager like 'apt' (on Debian/Ubuntu) or 'yum' (on Red Hat/CentOS).
The fifth stage is to verify full system functionality. This is often skipped by beginners. After you have 'fixed' the issue, do not just close the ticket. Test the system thoroughly. Can the user log in? Does the internet work? Does the application launch? Have you introduced any new problems? For example, if you fixed a boot issue by disabling a startup service, does the user still have the functionality they need?
The final stage is to document the findings, actions, and outcomes. This is critical for the exam and for real-world work. Write down the symptom, the probable cause you identified, the exact solution you applied, and how you verified it worked. This documentation helps you solve similar problems faster in the future and helps your colleagues.
Specific tools for macOS include:
Activity Monitor: Shows running processes, CPU and memory usage, and disk activity. Use it to find an application consuming 100% CPU.
Console: The log viewer for macOS. It displays system messages, application crash reports, and kernel panic logs (the macOS version of a 'Blue Screen of Death').
Disk Utility: Used to repair disk permissions and verify the disk structure.
Terminal: The command-line interface where you can run commands like 'top' (to see processes) and 'dmesg' (to see boot messages).
Specific tools for Linux include: - journalctl: Views logs from the systemd journal. Use 'journalctl -xe' to see recent errors and their context. - top or htop: Shows real-time process information. - dmesg: Prints kernel ring buffer messages—useful for hardware and driver issues. - ping and traceroute: Network troubleshooting commands. - lsblk and fdisk: Commands to view and manipulate disk partitions.
1. Identify the Problem
This is the first step of the official CompTIA troubleshooting methodology. You must gather information from the user, ask about recent changes, and try to reproduce the issue. For example, if a Linux user says 'my internet is down', ask 'does a wired connection work?' and 'has anyone changed the network settings recently?' Duplicating the problem confirms you have a real issue to solve.
2. Establish a Theory of Probable Cause
Based on the symptoms and user input, make an educated guess about the root cause. List multiple possibilities, starting with the simplest and most likely. For a Mac that won't boot past the Apple logo, your theory might be a corrupted system cache, a failing hard drive, or a recently installed incompatible kernel extension. Write these down mentally or on paper.
3. Evaluate the Theory and Test It
Test your most likely theory first, using the simplest method. For the Mac boot issue, try booting into Safe Mode by holding Shift. If it boots successfully, your theory that a third-party extension is to blame is strengthened. If it fails, you move to the next theory, such as running Disk Utility First Aid from Recovery mode.
4. Establish a Plan of Action and Implement the Solution
Once you have a confirmed theory, decide on the specific fix. The plan might be 'reinstall the printer driver' or 'run fsck on the root partition from a live USB'. Implement the plan carefully, following manufacturer instructions. If the fix causes a new problem, be prepared to revert the change (this is called a rollback plan).
5. Verify Full System Functionality and Implement Preventative Measures
The fix is not done until you verify that the original problem is solved and that no new problems have been introduced. Test multiple scenarios: can the user log in, launch the app, print, connect to the network? For the printer driver fix, test printing a test page, scanning, and checking that other applications still work. Then, suggest preventative measures like setting up automatic backups.
6. Document the Findings, Actions, and Outcomes
Write down the exact steps you took, the error messages you saw, the root cause you identified, and how you fixed it. This documentation is not just for your manager; it is for your future self. If the same issue happens again in six months, you can look up your notes and solve it in five minutes instead of an hour. It also helps other team members.
You are the sole IT support person for a small marketing agency with ten employees. Five use MacBooks on macOS Sequoia, and five use Linux laptops running Ubuntu 24.04. One Tuesday morning, a senior graphic designer calls you. Her MacBook will not start. She says she pressed the power button, the screen stays black, and the only sound is a series of three short beeps repeating every five seconds.
Your troubleshooting process begins immediately. You identify the problem: the laptop powers on but gives a beep code. The specific pattern of three short beeps on modern Macs usually indicates a memory (RAM) issue. You do not simply order a new logic board. You start with the simplest cause. You ask the designer a specific question: 'Did you recently install any new RAM modules?' She says her friend installed 32GB of third-party RAM last night.
Your theory is that the laptop has a RAM incompatibility or an improperly seated module. You decide to test this theory. You ask her to bring the laptop to your desk. You carefully remove the bottom case (after ensuring it is unplugged and the battery is disconnected internally, if possible). You reseat the existing RAM modules—you take them out and push them firmly back into their slots until the clips click. You remove the new third-party modules. You plug the laptop in and power it on. The laptop chimes normally and boots to the login screen. You have fixed the symptom.
Now you must verify full system functionality. You log in and open the Activity Monitor. You check that the system recognises the original RAM amount (8GB). You run Disk Utility First Aid on the internal drive—it passes. You open the design software she uses, Adobe Photoshop, and load a large file. It works. You then explain the situation: the third-party RAM was the cause. You reinstall her original RAM and advise her to purchase a certified kit from the manufacturer's compatibility list.
Later that day, a Linux user reports that his system cannot connect to the Wi-Fi. He is running Ubuntu. You start again. You ask him: 'Can you plug in an Ethernet cable to test the wired connection?' He does, and the internet works. This narrows the issue to the wireless subsystem, not the network configuration or the router. You run the command 'sudo journalctl -xe' and see errors about the 'iwlwifi' driver (the Intel wireless driver) failing to initialise. A common fix for Ubuntu is to reboot. You ask him to reboot. After the reboot, the Wi-Fi works. The theory was a transient driver issue. You document it: 'Wi-Fi not connecting on Ubuntu 24.04. Resolved by rebooting after driver error in journalctl. Driver iwlwifi failed to initialise on first cold boot. Full functionality verified.'
The 220-1202 exam tests your ability to apply a structured troubleshooting methodology to macOS and Linux, not your ability to memorise every obscure command. The questions are scenario-based. You will be given a description of a problem—a user states a specific symptom—and you must pick the best first step, best next step, or most likely cause.
The exam loves to test the order of operations in the troubleshooting methodology. A common trap is to jump to a complex solution when a simple one is available. For example:
Question: 'A Mac user says the system is running slowly. What is the FIRST step the technician should take?' The answer is NOT 'Reinstall macOS' or 'Check for malware.' The correct answer is 'Ask the user what has changed recently.' The exam is testing you on 'Identify the problem' first.
Another trap: confusing 'verify full system functionality' with 'implement the solution.' You must know that verifying is the step that comes after you have implemented your fix.
Concepts they love to test about macOS specifically:
Safe Mode: When to use it (to isolate startup items, kernel extensions, or disk issues). The exam might give a scenario where a Mac crashes when a specific application opens, and the technician boots into Safe Mode. The correct answer will state that Safe Mode loads only essential software, so if the crash doesn't happen, the cause is a third-party startup item or extension.
Disk Utility First Aid: That it repairs the disk's file system structure, not just 'frees up space.'
recoveryOS (the recovery partition): How to boot into it (Command-R at startup). You might be asked what to do if a Mac will not boot from the normal startup disk. The answer is to boot from macOS Recovery and run Disk Utility or reinstall macOS.
Activity Monitor: That it shows CPU, memory, energy, disk, and network usage. A question might describe a slow system and ask which tool to use to find a process using 99% CPU.
The 'dmesg' command: For troubleshooting hardware-related boot issues on a Mac (when used from Terminal in Recovery mode).
Concepts they love to test about Linux specifically:
The command 'top' or 'ps aux': To identify a process consuming resources.
The 'journalctl' command: To view system logs, especially with the '-xe' flags for recent entries and extra explanation.
The 'fsck' command: Must be run on an unmounted filesystem. The exam might test that you should boot into a live USB or single-user mode to run it.
The concept of a 'process' and a 'daemon' (a background process). A question might detail a service that fails to start, and you must check its status with 'systemctl status [service name]'.
The difference between 'apt-get update' (refreshes the list of available packages) and 'apt-get upgrade' (installs newer versions of packages).
Traps to watch for:
They might present a Windows tool as the answer for a Mac or Linux question. For example, 'System Configuration' (msconfig) is Windows-only. The Mac equivalent is checking 'Login Items' in System Settings.
They might ask for a command that doesn't exist. 'ipconfig' is Windows; the Linux equivalent is 'ip addr' or 'ifconfig'.
They might list 'reboot' as an answer that is 'too simple' but it can be the correct first step for a transient issue (though not if the problem is reproduction after reboot).
For boot issues on both OSs, always consider the bootloader or startup disk first before blaming the kernel.
Always start troubleshooting by identifying the problem: ask the user specific questions about what changed, then duplicate the issue if possible.
The CompTIA A+ troubleshooting methodology is a six-step process that applies to both macOS and Linux: identify, theorise, test, plan, verify, document.
Safe Mode on macOS and single-user mode on Linux are the first tools to use when a system fails to boot properly, as they load only essential components.
The most common cause of a 'slow Mac' is a third-party application consuming excessive CPU cycles, diagnosed with Activity Monitor.
Linux uses different package managers for different distributions: 'apt' for Debian/Ubuntu, 'yum' or 'dnf' for Red Hat/CentOS, and 'zypper' for openSUSE.
System logs (Console on macOS, journalctl on Linux) are the most important source of information for diagnosing intermittent crashes and boot failures.
Never skip the 'verify full system functionality' step; a fix that breaks another feature is not a successful fix.
Document every troubleshooting session with the symptom, cause, solution, and verification steps to build a knowledge base for future problems.
These come up on the exam all the time. Here's how to tell them apart.
macOS Safe Mode
Accessed by holding Shift key at startup
Loads only essential kernel extensions and disables all third-party startup items
Also performs a directory check of the startup volume
Linux Single-User Mode
Accessed by adding 'single' or '1' to the kernel command line, or using 'systemctl rescue'
Starts the system at a minimal level with only a root shell, no network services
No automatic filesystem check; you must run 'fsck' manually if needed
apt (Debian/Ubuntu)
Uses repositories with .deb packages
Commands: 'apt update' and 'apt upgrade'
Relies on dpkg as the underlying package manager
yum/dnf (Red Hat/Fedora)
Uses repositories with .rpm packages
Commands: 'yum update' or 'dnf upgrade'
Relies on RPM as the underlying package manager
Console (macOS Log Viewer)
Graphical application found in /Applications/Utilities
Shows all system messages, crash reports, and log streams in real time
Logs are stored in binary format in /private/var/log
journalctl (Linux Log Viewer)
Command-line tool that queries the systemd journal
Common flag: 'journalctl -xe' for recent errors with context
Logs can be viewed as text, JSON, or other formats
Mistake
macOS and Linux never get malware, so security troubleshooting isn't necessary.
Correct
macOS and Linux can be infected by malware, though less frequently than Windows. You should still check for malicious processes using Activity Monitor (macOS) or 'top' (Linux) as part of your troubleshooting.
Users and even some IT pros believe the 'no viruses' myth because macOS and Linux are based on Unix, which has a strong security model. This leads them to skip basic security checks when troubleshooting performance issues.
Mistake
If a Mac or Linux system won't boot, you should immediately reinstall the operating system.
Correct
Reinstalling should be a last resort. First, try Safe Mode (macOS) or single-user mode / a live USB (Linux). Run Disk Utility First Aid (macOS) or 'fsck' (Linux) to repair the disk. Check the bootloader configuration.
Reinstalling is time-consuming and can cause data loss if the user hasn't backed up properly. Beginners panic and jump to nuke-and-pave because it feels definitive, but it's often unnecessary.
Mistake
All Linux distributions use the same package manager, so troubleshooting is identical across all of them.
Correct
Different families of Linux use different package managers. Debian/Ubuntu use 'apt', Red Hat/Fedora use 'yum' or 'dnf', and openSUSE uses 'zypper'. You must know which distribution you are working on before choosing a command.
New users hear 'Linux' and assume it's one thing. The exam tests your awareness of distribution differences, and a wrong package manager command can break the system further.
Mistake
The 'dmesg' command is only for kernel developers and has no use in everyday troubleshooting.
Correct
'dmesg' is extremely useful for diagnosing hardware issues at boot, such as a failed hard drive, a faulty USB device, or a driver that won't load. It prints messages from the kernel ring buffer, which is a log of the kernel's activity.
'dmesg' output looks intimidating with lots of technical jargon, so beginners assume it is useless for them. In reality, a single line like '[ 5.123456] sd 0:0:0:0: [sda] No Caching mode page found' can indicate a disk problem.
Mistake
If a Mac is running slowly, clearing the Trash and deleting files will always fix it.
Correct
While low disk space can cause slowdowns, a slow Mac is more often caused by a runaway process (high CPU usage), insufficient RAM (causing swapping to disk), or a corrupted user account. Use Activity Monitor to diagnose first.
Deleting files feels productive and is easy to do, so it is the default action for many beginners. The exam tests that you should measure before you act, and the tool for measuring is Activity Monitor, not Finder.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Three short beeps repeating on a Mac usually indicate a memory (RAM) problem. It could be a loose module, incompatible RAM, or a failed module. Try reseating the RAM first.
Turn on or restart your Mac, then immediately press and hold the Shift key. Release the key when you see the login window (you will see 'Safe Boot' in the menu bar). Safe Mode loads only essential system extensions and checks your startup disk.
'apt-get update' refreshes the list of available packages from the repositories, but does not install anything. 'apt-get upgrade' actually installs newer versions of the packages you have on your system.
First, check if the Wi-Fi adapter is physically switched on (some laptops have a hardware switch or an Fn key combo). Then, run 'sudo journalctl -xe' to look for driver errors. The driver might need to be reinstalled or blacklisted.
'fsck' stands for 'file system check' and is used to repair corruption in a Linux filesystem. You must unmount the partition before running it (or boot from a live USB). The command is 'sudo fsck /dev/sda1', replacing '/dev/sda1' with your partition identifier.
Open the Activity Monitor application (found in /Applications/Utilities). Click on the '% CPU' column header to sort processes by CPU usage. The process at the top is the one consuming the most CPU.
You've finished Troubleshooting macOS and Linux Issues. Continue through the 220-1202 study guide to build a complete picture of the exam.
Done with this chapter?