Labs

How it works

There are two tracks, and both run alongside the theory. On track A you write systems code in C and implement the mechanisms you read about. On track B you administer a system and watch the same mechanisms on a live machine.

The tracks don’t depend on each other. You can do one, you can do both, or you can pick labs selectively: each one stands on its own and lists the modules to read before it.

The three difficulty levels describe how deep a lab goes; you don’t have to go through them in order. Basic checks whether you understood the mechanism. Intermediate asks you to apply it. Advanced asks you to measure the result and explain it.

Every lab comes with an automated check: a script that runs your solution and tells you exactly what doesn’t work. The course is designed for self-study, so the check does not depend on anyone looking at your code.

All lab pages share the same structure. “Goal” says what you’ll be able to do after the lab and where it will come in handy. “Task” describes the result, the limits, and the “done” criterion. “Before you start” lists what to read and prepare. Then come the stages, the check, and common mistakes.

What you need

You need a Linux system you don’t mind breaking. Some labs involve partitioning disks, building RAID arrays, and driving the system into emergency mode, so you definitely shouldn’t do this on your work machine.

Virtual machine (recommended)Full access to the kernel, disks, and bootloader. Works for all thirteen labs.

WSL2A real Linux kernel, fine for most labs. Not suitable for B1: Windows controls the boot process.

ContainerQuick for track A, except A6. The kernel is shared with the host, so B1, B5, and B6 won't work.

Cloud machineAny cheapest instance. For B1 and B5 you'll need to be able to attach disks.

Why a container doesn't work everywhere

A container shares the kernel with the host (module 17), so inside it lsblk and /proc/interrupts show the host’s devices and interrupts, dmesg and perf are unavailable, and /sys/firmware/efi doesn’t exist at all.

All of track A works in a container except A6: it needs the /dev/fuse device, which an unprivileged container doesn’t have.

From track B, B2, B3, and B4 will run in a container, the last two provided nesting is enabled. But B1 with its boot process, B5 with block devices, and B6 with performance counters need a virtual machine.

Lab files

The checks, starter code, and setup scripts are all in one archive:

curl -fsSL https://os.easy-tech.blog/os-course-labs.tar.gz | tar xz
cd os-course-labs

All commands on the lab pages are run from this directory. If you need just one file, you can fetch it on its own, for example https://os.easy-tech.blog/labs/a1-shell/check.sh.

The archive contains no reference solutions.

Ready-made environment

The archive has a setup/ directory with a Vagrant machine on Debian 12 that already has everything installed:

cd setup && vagrant up && vagrant ssh

Inside are gcc, make, gdb, strace, ltrace, perf, bpftrace, lsof, sysstat, numactl, libfuse3-dev, and libcap2-bin, and the machine has four extra 1 GiB disks attached for B5.

If Vagrant doesn’t suit you, setup/provision.sh installs the same thing on any fresh Debian or Ubuntu:

sudo bash setup/provision.sh

How to check yourself

cd labs/a1-shell
./check.sh ./myshell

The script prints a list of checks and shows which ones failed. It doesn’t assign grades and doesn’t send anything anywhere.

Track B labs are checked differently, because there is no program there to run. Each of them ends with a list of statements, and you should be able to back up each of those statements with a command on your own system.

Report

Almost every lab asks you to “write something down in the report”. The report here isn’t a document for an instructor; nobody will collect it. It’s a text file next to your code, a page or two long, where you record:

• the numbers you got: measurements, sizes, fault counts;
• answers to the questions asked in the lab stages;
• what didn’t work the first time and why.

While a number is only on the screen, it seems like everything is clear. When you have to write down why it is what it is, the gaps become visible. For track B labs the report replaces the automated check: it is the result of the lab.

Labs

Track A: systems programming in C

	Lab	Level	Builds on
A1	Your own shell	basic	3, 6
A2	Scheduler simulator	basic	7
A3	Producer–consumer	intermediate	8, 9
A4	Your own allocator	intermediate	10, 12
A5	Page replacement	advanced	11, 12
A6	A file system with FUSE	advanced	15
A7	An HTTP server in three versions	advanced	13

Track B: administration and infrastructure

	Lab	Level	Builds on
B1	Installing the system	basic	5
B2	Your own mini-top	basic	2, 6
B3	cgroups and the OOM killer	intermediate	12, 17
B4	A container by hand	intermediate	16, 17
B5	LVM and RAID	advanced	14
B6	Profiling	advanced	13, 18