SnipeOS system check

Open a terminal and run one command

The system check is a script you download and run once. It needs administrator access (your normal login password) because it updates packages, installs diagnostic tools if they are missing, and writes log files under system directories.

To run it:

1. Open the Snipe start menu (bottom-left).
2. Go to System Tools, or Favourites if you keep QTerminal pinned there.
3. Open the terminal (QTerminal).
4. Paste the command below and press Enter.

curl -fsSL https://snipebrowser.com/os/system-check.sh -o /tmp/system-check.sh && sudo bash /tmp/system-check.sh

When asked for your password, type it and press Enter. Characters will not appear on screen while you type; that is normal on Linux.

Before the long tests begin, the script shows a warning about how much time and disk space the run will use. Read it, then type YES in capitals to continue. If you are re-running the script and already know the warning by heart, you can skip the prompt with SNIPEOS_SYSTEM_CHECK_YES=1 (see environment overrides).

Early on, the script follows the same update path as the Java install script: it fixes a common apt CD-ROM issue, runs apt update and apt upgrade, and makes sure Java is available for tools that need it. It then repairs SnipeOS patches, collects system information, runs the scans, and writes the report file.

Before you start

This is not a quick five-minute fix. Plan to leave the PC alone for a while, ideally plugged in on a laptop. You will need:

• Installed SnipeOS, not a live USB session. The script changes packages on the system and expects a normal install.
• Your login password, because the script runs with sudo (administrator rights).
• Internet access, so apt can fetch updates and ClamAV can download virus definitions.
• At least 4 GiB of free disk space on the system drive and in your home folder. The script checks this first and stops if you are too low. You can lower the threshold with SNIPEOS_SYSTEM_CHECK_MIN_FREE_GIB if you know what you are doing.

Most runs take 1 to 3 hours or longer. The opening steps (updates, hardware snapshot, copying recent logs) usually finish in a few minutes. The antivirus scan is what takes the longest, often around one to two hours, because it walks through your home folder, temporary directories, and common places where applications are installed (including large Wine prefixes if you use the Windows subsystem). After that, the script asks your disks to run a long SMART self-test where the hardware supports it; on a physical drive that can add hours per disk. Many virtual machines report no SMART data, so that step may finish almost immediately on a VM.

What the script does

The script works through a fixed sequence. You do not need to babysit each step; the terminal will show progress. Here is what happens, in order.

Checks and updates

First it makes sure you have enough free disk space, then shows the time and resource warning and waits for YES. It applies the same CD-ROM apt fix used by the Java installer, runs a full apt update and apt upgrade, and installs OpenJDK if it is not already present. If you do not already have antivirus software, it installs ClamAV. It also installs helper tools such as inxi, fastfetch, smartmontools, memtester, and lshw when they are missing, then repairs SnipeOS patches so the system matches what SnipeOS expects.

Building the report

Next it writes the main body of the report: a quick machine snapshot (fastfetch or neofetch, plus inxi), detailed hardware listing, a best-effort Intel or Xeon generation decode from the CPU model name, a driver inventory (stock vs proprietary), and a search through logs for common “freeze” signals such as GPU hangs, out-of-memory events, and display-server errors. It then copies the last 12 hours of system journal output into the report. If that log is enormous, it saves the overflow into a separate sidecar file next to the report instead of bloating the main file.

The quick snapshot is not the disk test. Think of it as a label on the box: OS version, kernel, desktop, CPU, GPU, RAM, and how full your disks are. The actual disk health work comes later with SMART.

On Intel and Xeon CPUs, the script tries to decode the generation from the model string (for example E5 v2/v3/v4 or Scalable Platinum/Gold) and from CPUID. Unusual or rebadged chips may need a manual check on Intel ARK.

Antivirus scan

ClamAV updates its signature database with freshclam, then scans your home directory, temporary folders (/tmp, /var/tmp, /dev/shm), /opt, and /usr/local. It does not walk the entire root filesystem. System pseudo-filesystems such as /proc, /sys, /dev, and /run are skipped. It covers where your files and most user-installed software live without spending a day on every system package under /usr.

Disk and memory tests

For each disk that supports SMART, the script records health data and starts a long (extended) self-test. That is not the two-minute short test you might see in other tools; it is meant to catch problems a quick check can miss. Finally, memtester exercises a slice of RAM (about half of what is currently free, capped at 5 GiB) while the desktop is still running. That is useful, but it is not the same as booting memtest86+ from GRUB overnight, which tests the full stick with nothing else loaded.

Where the report lands

When everything finishes, your main copy is on the Desktop with a date and time in the filename:

~/Desktop/SnipeOS-system-check-YYYY-MM-DD_HHMM.txt

The tilde (~) means your home folder. A second copy with the same name is saved under /var/log/snipeos/ for safekeeping. When you open a support thread, attach the Desktop file. Forum helpers can read one text file instead of asking you to run ten separate commands.

If it stops before finishing

Power loss, a forced reboot, or closing the terminal can interrupt a long run. The script writes a progress log before each major step so you can see how far it got. Look here:

/var/log/snipeos/system-check.progress
~/Desktop/SnipeOS-system-check-progress.txt

Each line is timestamped and marked STARTING:, FINISHED:, or RUNNING:. If the last line says RUNNING: clamscan (for example), you know the antivirus pass was in progress when something went wrong. Attach the progress file along with the partial report if you post for help.

What the report contains

You do not need to understand every line in the file. Support volunteers do. The report is structured so someone remote can see what machine you have, what software was running, and whether anything already looked unhealthy in logs or tests.

Expect sections covering:

• Machine identity: OS name and version, kernel, desktop environment, CPU, GPU, RAM, and disk usage from fastfetch and inxi.
• Hardware and drivers: PCI devices and which kernel driver each one uses, classified as proprietary, in-tree, or unknown/DKMS. Intel and Xeon generation notes when applicable.
• Freeze clues: lines from logs that often explain crashes or hangs, such as GPU resets, out-of-memory kills, I/O stalls, failed services, Xorg warnings, and thermal events.
• Recent history: the last twelve hours of journalctl output, inline or in a sidecar file if it was too large for one document.
• Antivirus results: a ClamAV summary for home, temp folders, /opt, and /usr/local.
• Disk health: SMART status and long self-test results when your drives expose SMART (many VMs do not).
• Memory test: the memtester result for the RAM slice that was tested.
• Progress trail: timestamped step markers from the run itself.

Drivers: stock vs proprietary

Graphics cards, Wi-Fi adapters, and other hardware need a driver: software that lets the kernel talk to the device. Some drivers ship inside the Linux kernel (free and maintained with the OS). Others come from the vendor (proprietary) or are built on your machine with DKMS.

The report lists each PCI device and classifies the driver actually in use:

• Proprietary, for example NVIDIA’s nvidia module or Broadcom’s wl driver.
• Stock (in-tree), built into the kernel, for example i915 or amdgpu for graphics, nouveau for NVIDIA without the proprietary stack, or iwlwifi for many Intel Wi-Fi chips.
• DKMS or unknown, when the driver was compiled locally or the script could not confidently classify it from modinfo.

Mismatched or missing drivers are a frequent cause of freezes and poor performance. If the report shows something unexpected, our dedicated guides may help: NVIDIA and Broadcom Wi-Fi.

What this check can and cannot catch

The system check is thorough for a single automated pass, but no script can guarantee a clean bill of health. It helps forum support narrow down hardware vs software vs heat vs power issues. It does not replace professional repair or weeks of stress testing.

ClamAV, disk, and RAM

These three checks are the slowest parts of the run. Here is what each one actually covers:

Problems the report is good at surfacing

Because it pulls live logs and hardware state, the report often already contains evidence of GPU hangs, out-of-memory kills, high I/O wait, failed systemd units, Xorg errors and warnings, thermal throttling, display-manager or D-Bus issues, stuck network mounts, and package manager locks. If any of those happened in the last twelve hours, they are likely in the file.

Problems it may still miss

Some faults are intermittent or physical in a way logs never record. The check cannot reliably detect:

• RAM defects that only show up outside the small memtester slice, or only after many hours of use.
• Bad disk sectors that SMART’s long test still did not trip over.
• A failing power supply or marginal voltage under load.
• Overheating that only appears after sustained gaming or rendering.
• Loose cables, bad USB docks, or flaky external drives.
• A frozen desktop compositor that never wrote an error line.
• Application-specific bugs (Wine, browsers, games) mistaken for an OS fault.
• Firmware bugs that fail silently with no kernel message.

If the desktop freezes while this script is running, treat that as useful data too. Heavy disk scanning and memory testing can stress I/O and RAM; a hang during those steps can point to the same bottleneck you were trying to diagnose.

Environment overrides

Most people never need these. They exist for repeat runs, tight disks, or shorter memory tests on low-RAM machines. Set the variable on the same line as sudo bash:

sudo SNIPEOS_SYSTEM_CHECK_YES=1 bash /tmp/system-check.sh
sudo SNIPEOS_SYSTEM_CHECK_MIN_FREE_GIB=2 bash /tmp/system-check.sh
sudo SNIPEOS_SYSTEM_CHECK_MEMTEST_MIB=256 bash /tmp/system-check.sh

SNIPEOS_SYSTEM_CHECK_YES=1 skips the interactive YES warning (use only if you have read this guide and know the run is long). SNIPEOS_SYSTEM_CHECK_MIN_FREE_GIB lowers the minimum free disk space below the default 4 GiB. SNIPEOS_SYSTEM_CHECK_MEMTEST_MIB sets the memory test size in mebibytes instead of the automatic half-of-free-RAM calculation.

SnipeOS only (do not run elsewhere)

This script is tailored to SnipeOS package names, patch layout, and support workflow. It is not a generic Linux health checker.

Not sure what you are running? Open a terminal and type fastfetch. SnipeOS identifies itself clearly in that output.