LAB-HW-01 - Exploring System Hardware

Part A: The Field Guide

---

🎯 What & Why

You just SSH’d into a remote server 2,000 miles away. You have no idea what it is. Is it a massive 64-core database server, or a tiny Raspberry Pi? Does it have a dedicated GPU attached? Is the USB backup drive physically plugged in?

You cannot open the box to look. You must ask the Linux Kernel.

The Kernel maintains a constant, live inventory of every single piece of silicon and metal attached to the motherboard. We retrieve this inventory using the ls* family of hardware commands (List CPU, List PCI, List USB).

---

🧠 Mental Model: The Three Busses

When electricity flows through a motherboard, it travels down three primary highways (Busses):

1. The Core Block: The CPU and the RAM. These are accessed via highly specific core commands (lscpu and free).
2. The PCI Bus: The high-speed internal highway. This is where Graphics Cards (GPUs), Network Cards (NICs), and NVMe solid-state drives plug in. Evaluated using lspci.
3. The USB Bus: The slower, external highway. This is where keyboards, mice, flash drives, and external backup arrays plug in. Evaluated using lsusb.

---

📖 Command Reference

The Core Block

The Expansion Busses

---

🌍 Real Scenarios

Scenario 1: Sizing the Database You are hired to tune a PostgreSQL database. The very first thing you do is run lscpu and free -h. You discover the server has 32 CPU cores but only 8GB of RAM! This is an insane hardware bottleneck. You instantly know why the database is struggling and tell the client they need to upgrade the RAM before you even touch a config file.

Scenario 2: The Missing Network Card You plug a brand new 10-Gigabit fiber network card into the server slot. You boot Linux. You run ip link, but the fiber card doesn’t show up. Is the card dead, or is Linux missing the software drivers? You run lspci. You see Ethernet controller: Intel X710 10GbE SFP+. The kernel does see the physical metal card! You conclude the card is physically fine, but you need to manually install the i40e Linux driver software for it to work.

---

⚠️ Gotchas & Pitfalls

1. Virtual Machines lie to you If you run lscpu inside an AWS EC2 instance or a VirtualBox VM, you do not see the real physical hardware of the remote host. You explicitly see the virtualized slice of hardware the hypervisor (VMware/KVM) chose to show you. Look for the Hypervisor vendor: line in lscpu to confirm.
2. free -m vs free -h Many older Sysadmins have rigid muscle memory for free -m (Megabytes). If a server has 128 Gigabytes of RAM, free -m will output 131072. This is unreadable. Train yourself to use free -h (Human) so it outputs 128Gi.

---

Part B: The Drill Deck

Terminal Required: Open any Linux terminal. It doesn’t matter if it’s a VM, a Raspberry Pi, or WSL; the kernel will report what it sees.

---

G

Guided Step by step - type exactly this and compare the result

>

Exercise G1: The Brain

1. Interrogate your processor: lscpu
2. Find the line that says Architecture:. Is it x86_64 (Standard Intel/AMD PC) or aarch64 (ARM / Apple Silicon / Raspberry Pi)?
3. Find the line that says CPU(s):. How many total logical processing cores do you have?
4. Look at Model name:. What exact brand of silicon is running your machine?

Exercise G2: The Memory

1. Check your available RAM: free -h
2. Look at the Mem: row (NOT the Swap row yet).
3. Identify your total RAM capacity.
4. Identify how much is available. (Note: Do not look at free. Linux intentionally fills up free RAM with cached files to speed up the system. available is the true amount of RAM you can safely use before the system crashes).

Exercise G3: The Peripherals

1. Let’s see what is plugged into the motherboard. Run: lspci
2. If you are in a Virtual Machine, you will see fake simulated devices (like VMware Virtual Machine Communication Interface).
3. If you have a dedicated Graphics Card (Nvidia/AMD), you will see a VGA compatible controller: line.
4. Run: lsusb to see your virtual or physical USB hubs.

S

Solo Task described, hints available - figure it out

>

Exercise S1: Verbosity is Power

The lspci command output is extremely brief. If you are troubleshooting a specific manufacturer defect, you need the nitty-gritty silicon details.

1. Add the Verbose flag to PCI: lspci -v.
2. Scroll up. Notice how an entry that was previously one line is now 10 lines, detailing the precise memory addresses, latency timers, and exact Linux Kernel modules (Drivers) assigned to the card.
3. If you need even more depth, you can run -vv (Very Verbose).

Exercise S2: Grepping the Metal

You run lspci on a massive enterprise server and receive 80 lines of chaotic output connecting to dozens of bridges. You only care about Network connectivity.

1. Pipe lspci into grep.
2. Instruct grep to search for the word Ethernet or Network (Case-insensitive!).
3. The output should be cleanly reduced to just your network interface cards.

M

Mission Real scenario - no hints, combine multiple skills

>

Mission M1: The Raw Source of Truth

Where do commands like lscpu actually get their information? They don’t cast magic spells. They simply read text files that the Kernel constantly generates inside the mysterious /proc virtual filesystem.

Whenever you run lscpu, the tool is secretly just formatting the raw text found in /proc/cpuinfo.

Your Mission: Bypass the lscpu tool entirely.

1. Use the cat command to read the raw Kernel stream directly at /proc/cpuinfo.
2. Marvel at the raw data block for {'{}'}processor : 0{'}'}.
3. Use the same technique to find the raw Kernel source file for Memory statistics. (Instead of cpuinfo, the file is called meminfo).
4. Read /proc/meminfo. Notice it contains 50x more detailed RAM statistics than the simple free -h command summarizes!

(When you truly understand Linux, you realize that absolutely everything is just a text file. Even the hardware!)