Linux Filesystem & Shell

Embedded → Embedded Linux: Userspace & Toolchain

Why a board's filesystem looks nothing like your laptop's

The first time you SSH or serial-console into an embedded Linux board, the filesystem looks familiar —/etc, /bin, /home— but it's a fraction of the size of a desktop install, usually built with BusyBox (dozens of common Unix tools compiled into a single small binary, symlinked under every command name it implements) instead of the full GNU coreutils. Same kernel, same directory-hierarchy standard, a deliberately reduced and custom-configured set of userspace components on top.

This video is a conceptual framing piece — what embedded Linux actually is, and how it differs from a desktop distro like Raspberry Pi OS. It does not walk through the directory hierarchy or shell commands themselves — that's what the rest of this lesson, and the hands-on practice ladder linked at the bottom, actually teach.

The directory hierarchy — what's actually load-bearing

Every one of these directories exists on a real target board and answers a different question about the system — knowing which is which is what lets you find a config file, a running peripheral, or a kernel setting without guessing:

/
├── etc/     configuration files — static text, read at boot or on-demand (e.g. /etc/passwd, /etc/fstab)
├── dev/     device nodes — every peripheral the kernel knows about shows up here (/dev/ttyUSB0, /dev/i2c-1)
├── proc/    a live view into running processes and kernel state — not real files, generated on read
├── sys/     kernel objects and driver attributes exposed as files — e.g. toggle a GPIO by writing here
├── lib/     shared libraries (.so files) every dynamically-linked binary on the system depends on
├── usr/     the bulk of installed software — /usr/bin, /usr/lib — historically 'user-installed'
├── bin/     the small set of commands needed even in single-user/recovery mode (often -> usr/bin)
├── var/     data that changes while the system runs — logs, PID files, sometimes a runtime database
├── boot/    the kernel image and boot configuration the bootloader hands off to
├── home/    per-user data — on a headless board, often just /home/root or doesn't exist at all
└── tmp/     scratch space — frequently a RAM-backed tmpfs, wiped clean on every reboot

/proc and /sys are not files you edit by hand casually — they're live handles into the kernel

/proc and /sysare the two directories that surprise people coming from a desktop background the most. Nothing under either is real data sitting on flash — every “file” is generated by the kernel the instant you read it, and writing to certain files directly changes running kernel behavior.

cat /proc/cpuinfo          # generated live — CPU model/features, not a stored file
cat /proc/meminfo          # live memory stats

# /sys is how you drive hardware without a dedicated userspace tool at all —
# this is the raw mechanism GPIO/LED/PWM sysfs interfaces use:
echo 47 > /sys/class/gpio/export     # ask the kernel to expose GPIO 47 as a sysfs entry
echo out > /sys/class/gpio/gpio47/direction
echo 1 > /sys/class/gpio/gpio47/value  # drives the physical pin HIGH, right now

When a driver misbehaves, /sys/class/<subsystem>/ and dmesg(which reads the kernel's ring buffer, itself exposed through this same mechanism) are usually the first two places to look, before reaching for a debugger.

Try it — explore a real embedded-target hierarchy

Click a directory to see what it's actually for and a real example of what you'd find inside it on a running board:

/etc

Static configuration files, read at boot or on demand.

$ # example on a real target
/etc/fstab lists which partitions get mounted where at boot.

Where shell fluency actually gets built: the real practice ladder

This lesson deliberately doesn't re-teach cd/ls/grep/pipes command-by-command — this site ships a real Linux shell, running an actual kernel via a browser-based emulator, with graded exercises that check your real command output:

Go work through Linux Command-Line Practice — navigation, file operations, permissions, pipes/redirection, and more, against a real bash shell, not a simulated one.

Completion saves automatically after you read through to the end.

Next lesson →

← Back to learning path