Booting, the Desktop, and the Linux Terminal on the Pi 500+¶

Summary¶

This chapter introduces the Raspberry Pi 500+ as a classroom Linux desktop computer. It covers how Raspberry Pi OS boots from an SD card image written with Raspberry Pi Imager, the desktop environment and window manager, and the terminal emulator and Bash shell that give direct access to the system. It walks through the file system hierarchy, user permissions (root, sudo, chmod, chown), and the core navigation commands -- listing files, changing directories -- needed to work comfortably at the command line. Students finishing this chapter will be able to boot a Pi 500+, open a terminal, and navigate the file system from the shell.

Concepts Covered¶

This chapter covers the following 23 concepts from the learning graph:

Raspberry Pi OS
Linux Kernel
Boot Process
SD Card Imaging
Raspberry Pi Imager
Desktop Environment
Window Manager
File Manager
Terminal Emulator
Command Line Interface
Shell
Bash Shell
Shell Prompt
Working Directory
File System Hierarchy
Home Directory
Root User
Sudo Command
File Permissions
Chmod Command
Chown Command
List Files Command
Change Directory Command

Prerequisites¶

This chapter builds on concepts from:

Chapter 2: Choosing the Right Raspberry Pi Product

Welcome to a Whole New Machine!

Berry waving welcome Everything up through Chapter 10 ran on a Pico — a tiny microcontroller that does exactly one job at a time. This chapter hands you something very different: a real computer. Let's build something — starting with figuring out how it even turns on!

Every project so far in this book has run on a Raspberry Pi Pico or Pico W: a microcontroller, a single chip that runs one MicroPython program at a time, with no operating system underneath it. Plug it in, and your code starts running within a second or two — there's nothing else going on. The Raspberry Pi 500+ is a completely different category of device: a full computer built into a keyboard, with enough processing power and memory to run a real operating system — software that manages a computer's hardware and runs multiple programs at once, handling things like memory, storage, and multitasking so individual programs don't have to. That single difference — an operating system sitting between your code and the hardware — changes almost everything about how you'll interact with this machine, and this chapter is where you learn the new rules.

What Changed: From Microcontroller to Linux Computer¶

The operating system running on a Pi 500+ is called Raspberry Pi OS, a version of the Linux operating system built and customized specifically for Raspberry Pi hardware. At the center of any Linux-based operating system sits the Linux kernel: the core piece of software that directly controls the computer's hardware — the processor, memory, storage, and connected devices — and decides which program gets access to what, and when. Everything else on the system, from the desktop you'll see in a moment to the terminal commands later in this chapter, is built on top of the kernel rather than talking to the hardware directly.

This is worth pausing on, because it explains nearly every new skill in this chapter. A Pico has no kernel, no file system, no user accounts, and no way to run two programs simultaneously — your MicroPython script is the whole show. A Pi 500+ running Raspberry Pi OS can run a web browser, a code editor, and a terminal all at the same time, store thousands of files in an organized structure, and even support multiple people with separate accounts on the same machine. The table below summarizes that shift now that both sides of it have been explained.

	Pico / Pico W (earlier chapters)	Raspberry Pi 500+ (this chapter onward)
Runs	One MicroPython program at a time	A full Linux operating system running many programs at once
Storage	A small amount of flash memory for one program	An SD card or SSD holding an entire file system
Starts by	Running your code immediately on power-up	Booting an operating system before any program runs
You interact through	A single Python file, edited in Thonny	A desktop, a file manager, and a terminal
Users/permissions	None — there's only ever one program in control	Multiple user accounts, each with their own permissions

Berry's Key Insight

Berry thinking Don't worry — nothing you learned about computational thinking, sensors, or actuators becomes useless here. The sense-think-act cycle still applies on a Pi 500+. What's new is how you get code running: instead of just uploading a script, you're now working inside a full operating system that has to start itself up first.

Booting the Pi 500+: From SD Card to Desktop¶

Before Raspberry Pi OS can run at all, it has to exist somewhere the Pi 500+ can read from, and it has to be started correctly every time the machine powers on. SD card imaging is the process of writing a complete, ready-to-boot copy of an operating system onto an SD card, replacing whatever was on it before — you're not just copying files, you're writing the exact structure the Pi 500+ expects to find. The standard tool for this is the Raspberry Pi Imager, official software that downloads a chosen version of Raspberry Pi OS and writes it to an SD card (or USB drive), while also letting you pre-configure settings like the Wi-Fi network and a default username before the card is ever inserted into the Pi.

Once a correctly imaged SD card is in place and the Pi 500+ is powered on, it goes through its boot process: the fixed sequence of steps a computer follows between power-on and having a usable, running operating system. At a high level, the Pi 500+'s firmware locates the SD card, loads the Linux kernel into memory, the kernel takes over and initializes the hardware, and finally the operating system starts the programs needed to show a desktop.

Before looking at that sequence as a diagram, notice that SD card imaging happens once, ahead of time, on a different computer — the boot process happens every single time the Pi 500+ powers on, using whatever was imaged onto the card.

Diagram: Boot Process Explorer¶

Run the Boot Process Explorer MicroSim fullscreen

Boot Process Explorer (interactive diagram)

Type: interactive-diagram sim-id: boot-process-explorer
Library: p5.js
Status: Specified

Learning objective: Students will explain (Bloom L2: Understand) the sequence of steps a Raspberry Pi 500+ follows between power-on and a usable Linux desktop.

Canvas: 700x440px default, responsive — recompute step-box positions as fractions of width inside windowResized(), reflowing from a horizontal row to a stacked column below 480px wide.

Layout: a horizontal row (vertical stack on narrow screens) of five connected step boxes with arrows between them: "1. Power on — firmware finds the SD card," "2. Bootloader loads the Linux kernel," "3. Kernel initializes hardware," "4. Operating system starts background services," "5. Desktop environment appears." Boxes are tinted a gradient from copper gold #D4AF37 (early, low-level steps) to circuit green #2E7D32 (later, higher-level steps) to visually reinforce the hardware-to-software progression.

Controls: a createButton() labeled "Step Forward" advancing a highlighted marker one box at a time, and a createButton() labeled "Reset." A createSlider() labeled "Auto-Play Speed" (0 = off to 5 = fast) auto-advances the marker.

Interaction: clicking any step box jumps the marker there and opens an infobox with a one-sentence explanation matching the chapter's prose (e.g., clicking box 2 explains what the Linux kernel is and that it's now being loaded into memory). Only one infobox is open at a time. A small always-visible caption above the diagram reads "SD card imaging (Raspberry Pi Imager) happens before step 1, on a separate computer."

Implementation: p5.js. Store the five steps as an array of {label, definition} objects. Track currentStep; redraw all boxes each frame with the active box outlined in a brighter stroke. Rectangle bounds-checking for click hit-testing in mousePressed(). Parent the canvas to the enclosing <div> per project convention.

Berry's Tip

Berry sharing a tip Always use the official Raspberry Pi Imager rather than a random download of an OS image from the internet. It verifies the download, writes it correctly, and lets you set up Wi-Fi and a username before you ever plug the SD card into the Pi — that's berry convenient for a classroom set of boards.

The Desktop Environment¶

Once the boot process finishes, most Pi 500+ sessions land on a graphical desktop rather than a blank screen — a very different starting point from anything a Pico ever gave you. A desktop environment is the complete graphical interface a user sees and interacts with: icons, a taskbar, menus, and the visual style that ties them together. Underneath the desktop environment, a window manager is the specific piece of software responsible for positioning, resizing, minimizing, and switching between the windows of open programs — it's what lets you drag a code editor to one side of the screen and a terminal to the other.

One program you'll use constantly on the desktop is the file manager: a graphical application that lets you browse, open, copy, move, and delete files and folders using icons and windows instead of typed commands. It shows the same files and folders you'll later learn to navigate from the command line — just with a different, point-and-click interface layered on top of the same underlying file system.

Opening a Window Into Linux: The Terminal¶

The file manager and desktop are convenient, but they hide a lot of what's actually possible on a Linux computer. A terminal emulator is a program that opens a text-based window for typing commands directly to the operating system, standing in for the physical terminals that early computers used before graphical desktops existed. Inside that window, you interact through a command line interface (CLI) — a way of controlling a computer entirely by typing text commands and reading text responses, rather than clicking icons.

The program that actually reads your typed commands, interprets them, and runs them is called a shell. On Raspberry Pi OS, the default shell is the Bash shell (Bourne Again SHell), one of the most widely used command interpreters across Linux and other Unix-like systems. Every time the shell is ready for a new command, it displays a shell prompt: a short line of text — often showing your username, the computer's name, and your current location in the file system — that tells you the shell is waiting for input.

Before exploring a real shell prompt piece by piece, it helps to know that its exact appearance is configurable, but it almost always follows the same general pattern of "who you are, where you are, and a symbol showing the shell is ready."

Diagram: Shell Prompt Anatomy¶

Run the Shell Prompt Anatomy MicroSim fullscreen

Shell Prompt Anatomy (reused MicroSim)

Type: interactive-diagram sim-id: shell-prompt-anatomy
Library: p5.js
Status: Reused
Source: https://dmccreary.github.io/learning-linux/sims/shell-prompt-anatomy/
Source Repo: https://github.com/dmccreary/learning-linux/tree/main/docs/sims/shell-prompt-anatomy

Reused from the MicroSim catalog (WHAT match score 0.8415). Learning objective: Students will identify (Bloom L1: Remember) the components of a Bash shell prompt, including username, hostname, and current working directory.

Berry's Key Insight

Berry thinking A terminal emulator, a shell, and a command line interface are three different layers, even though people often say "terminal" to mean all three. The terminal emulator is just the window; the shell is the program actually reading your commands inside it; the CLI is the overall style of interaction. You'll mostly just say "open a terminal" — but knowing the layers helps when something goes wrong.

Finding Your Way Around: The File System¶

Every file and folder on a Pi 500+ lives somewhere in a single, organized structure. The file system hierarchy is the tree-shaped arrangement of every directory (folder) and file on a Linux computer, starting from one top-level directory, written as a single forward slash (/) and called the root of the tree. Inside that hierarchy, every user account gets its own home directory — a personal folder (typically /home/<username>) where that user's own files, downloads, and settings live by default, separate from system files everyone shares.

At any given moment, a running shell is "standing" in exactly one location within that hierarchy — its working directory: the directory a shell or program is currently operating in, so that a file name typed without a full path is assumed to live there. A quick way to check your current working directory is the pwd command (print working directory), which simply prints that path back to you.

Now that root, home directories, and the working directory have all been defined, the diagram below lets you explore how they sit inside the larger file system hierarchy.

Diagram: Linux File System Hierarchy Explorer¶

Run the Linux File System Hierarchy Explorer MicroSim fullscreen

Linux File System Hierarchy Explorer (graph data model)

Type: graph-data-model sim-id: file-system-hierarchy-explorer
Library: vis-network
Status: Specified

Learning objective: Students will analyze (Bloom L4: Analyze) how directories are organized in the Linux file system hierarchy, and locate the home directory and current working directory within it.

Canvas: 700x480px vis-network hierarchical graph, responsive — call network.fit() inside a window.addEventListener('resize', ...) handler so the tree re-centers and rescales to its container.

Layout: a top-down hierarchical vis-network graph rooted at a node labeled / (root). Root branches to common top-level directories: /home, /etc, /usr, /var. The /home node branches to two example user home-directory nodes, /home/pi and /home/student, colored raspberry #C2185B and marked with a small house icon label to reinforce "home directory." One file node, robot_control.py, hangs beneath /home/pi, colored copper gold #D4AF37, with a highlighted border representing "current working directory contains this file."

Controls: a createButton()-style HTML button labeled "Show My Working Directory" that animates a highlight pulse to the /home/pi node and its file, reinforcing that the working directory is just one specific node in the larger tree; a "Reset View" button that calls network.fit() again.

Interaction: clicking any directory node opens an infobox below the graph naming it and, for /home/pi specifically, explaining that this is a home directory. Clicking the robot_control.py file node explains that its full path (/home/pi/robot_control.py) is built by following the tree from the root down. Hovering any edge shows a tooltip reading "contains."

Implementation: vis-network with layout: {hierarchical: {direction: 'UD', sortMethod: 'directed'}}. Node and edge data defined as vis-network DataSet objects with a small lookup table mapping node id to its infobox text. Register a click event handler for the infobox behavior described above.

Navigating and Listing Files: Your First Commands¶

With the file system hierarchy in mind, two commands handle almost all of your day-to-day movement around it. The list files command, ls, displays the files and directories contained in a given location — run with no arguments, it lists the working directory; given a path, it lists that path instead. The change directory command, cd, moves the shell's working directory to a new location, so that future commands (including ls) operate somewhere else.

The example below opens a terminal already sitting in the pi user's home directory, lists what's there, then moves into a subdirectory and confirms the change.

$ pwd
/home/pi

$ ls
Desktop  Documents  Downloads  Pictures  robot_control.py

$ cd Documents
$ pwd
/home/pi/Documents

Before the next diagram, notice that ls shows what exists at your current stop in the file system hierarchy, while cd is what actually moves that stop — together they're how you'll explore everything the file manager showed you graphically, but from the command line instead.

Diagram: Command Syntax Explorer¶

Run the Command Syntax Explorer MicroSim fullscreen

Command Syntax Explorer (interactive infographic)

Type: interactive-infographic sim-id: command-syntax-explorer
Library: p5.js
Template: https://github.com/dmccreary/learning-linux/tree/main/docs/sims/command-syntax
Status: Specified

Learning objective: Students will analyze (Bloom L4: Analyze) how a Linux command is built from a command name, options, and arguments, using ls and cd as examples.

Canvas: 700x380px, responsive — recompute segment widths as fractions of width inside windowResized().

Layout: a large monospaced text rendering of ls -la Documents, broken into three color-coded, boxed segments: ls (command name, raspberry #C2185B), -la (options, copper gold #D4AF37), Documents (argument, circuit green #2E7D32). A createSelect() dropdown labeled "Example Command" lets a student switch between three preset commands: ls -la Documents, cd Documents, and ls /home, each re-rendering the color-coded segments (the cd Documents example has no options segment, illustrating that options aren't always present).

Interaction: clicking any colored segment opens an infobox explaining that part's role in general (command name = the program being run, options = flags that change its behavior, argument = the target the command acts on) and, specifically for -la, notes that -l shows details like permissions and -a includes hidden files. Hovering a segment (desktop) lightens its border color before a click opens the infobox, supporting both mouse and touch interaction.

Implementation: p5.js. Store each preset command as an object {command, options, argument, notes}; render with text() at fixed monospaced positions recalculated on resize. Hit-test each segment via its bounding box in mousePressed().

Berry's Tip

Berry sharing a tip ls on its own is useful, but ls -la is the version working makers actually type: -l gives you the "long" listing with permissions and size, and -a shows hidden files (the ones starting with a dot) that a plain ls skips.

Who's In Charge? Users, Permissions, and Sudo¶

A Pico never needed the idea of a "user" — there's only ever one program running, with total control over the chip. Linux was built from the start to support multiple people sharing one computer safely, and that requires a system for deciding who can do what. Every Linux system has a special account called the root user — the superuser account with unrestricted access to every file and every operation on the system, able to override any restriction the operating system would otherwise enforce.

Because the root user is so powerful, Raspberry Pi OS doesn't normally let you work as root directly. Instead, an ordinary user account can use the sudo command ("superuser do") to run one specific command with root-level privileges, just for that one command, after confirming the request. Typing sudo before a command is a deliberate, visible signal that you're asking for elevated power — and it should never be reached for casually.

Berry's Gentle Warning

Berry warning Take sudo seriously, every single time. A command that would normally fail safely on an ordinary account can delete files, overwrite system settings, or break your Pi 500+ entirely when run as root — there's no undo button. Read a sudo command fully before pressing Enter, especially anything involving rm (remove). This isn't a place for a pun; it's the one rule in this chapter with zero exceptions.

Root access is the extreme case, but everyday file access on a Linux system is controlled by something more fine-grained: file permissions, a set of rules attached to every file and directory that determine who can read it, write to it, or execute it as a program, split across three categories — the file's owner, a group of users, and everyone else. Running ls -l on a file reveals these permissions as a ten-character string, like -rwxr-xr-x, where each group of three letters (read r, write w, execute x) describes one category's access.

Two commands let you change those rules once you understand them. The chmod command ("change mode") modifies a file's permissions — for example, adding execute permission so a script can be run directly instead of only read. The chown command ("change owner") changes which user (and optionally which group) owns a file, useful when a file needs to be handed off to a different account.

$ ls -l robot_control.py
-rw-r--r-- 1 pi pi 245 Jul 24 10:15 robot_control.py

$ chmod +x robot_control.py
$ ls -l robot_control.py
-rwxr-xr-x 1 pi pi 245 Jul 24 10:15 robot_control.py

$ sudo chown pi:pi robot_control.py

In this example, chmod +x robot_control.py adds execute permission for every category, changing -rw-r--r-- to -rwxr-xr-x so the file can now be run directly rather than only opened and read. The sudo chown pi:pi robot_control.py command uses sudo because changing ownership is itself a restricted operation, and sets both the owning user and owning group to pi.

Now that read, write, and execute have all been explained, the table below summarizes what each letter means for a file.

Letter	Permission	What it allows
`r`	Read	View the file's contents (or list a directory's contents)
`w`	Write	Modify the file's contents (or add/remove files in a directory)
`x`	Execute	Run the file as a program, or enter a directory with `cd`

Diagram: File Permissions and Chmod Simulator¶

Run the File Permissions and Chmod Simulator MicroSim fullscreen

File Permissions and Chmod Simulator (MicroSim)

Type: microsim sim-id: file-permissions-chmod-simulator
Library: p5.js
Status: Specified

Learning objective: Students will apply (Bloom L3: Apply) a chmod permission change to a file and predict the resulting read/write/execute access for owner, group, and others.

Canvas: 700x420px, responsive — recompute the three permission-group panel widths as fractions of width inside windowResized().

Layout: three side-by-side panels labeled "Owner," "Group," "Others," each showing three toggle switches for Read, Write, Execute, drawn as small colored squares that fill in (circuit green #2E7D32) when "on." Above the panels, a live-updating monospaced readout shows the resulting ten-character permission string (e.g., -rwxr-xr-x) that matches the current toggle states.

Controls: clicking any toggle square flips that specific permission on/off, immediately updating the readout string above; a createButton() labeled "Reset to 644 (rw-r--r--)" restores the common default file permissions; a second createButton() labeled "Set to 755 (rwxr-xr-x)" sets the common "executable script" permissions used in the chapter's chmod +x example.

Interaction: hovering any toggle shows a tooltip naming which category and permission it controls (e.g., "Group: Write"). Below the readout, a short auto-generated sentence explains the current state in plain language, such as "The owner can read, write, and run this file. The group and others can only read it." — regenerated every time a toggle changes.

Implementation: p5.js. Store state as a 3x3 boolean array [owner, group, others] x [read, write, execute]. Rebuild the permission string and the plain-language sentence from that array on every draw() call. Toggle hit-testing via rectangle bounds-checking in mousePressed().

You've Got This!

Berry encouraging you Permissions and sudo feel abstract the first few times you meet them — that's normal. Nobody memorizes rwxr-xr-x on day one. Keep the three categories (owner, group, others) and the three letters (r, w, x) in mind, and the ten-character string on any ls -l line will start reading itself to you within a chapter or two.

Bringing It Together¶

You just crossed the biggest hardware jump in this book — from a single-purpose microcontroller to a full Linux computer with an operating system, a desktop, a file system, and real user accounts. Everything from here forward in the Pi 500+ and Pi 5 tiers builds on this chapter: the next chapter uses the same terminal to install software, manage running processes, and even reach your Pi 500+ remotely over the network — a skill that connects directly back to the Wi-Fi concepts from Chapter 10.

You Unlocked a Superpower!

Berry celebrating That's berry impressive — you booted a real Linux computer, opened a terminal, and can now navigate its file system and permissions with confidence. STEM is our superpower! Let's build something — see you in Chapter 12!

See Annotated References