These labs are written for a reader who has cloned SlOS and wants a practical route through
boot, causal history, timelines, SlFS, user programs, actors, mesh identity, and the
showcase references.
Starting point
Build once, then operate from the shell.
git clone https://github.com/slepp/slos.git
cd slos
make
make run-nographic
Operator notes
Keep the session observable.
Run the commands exactly at first. Record event IDs as they appear on your machine. When a
lab asks for <event-id>, choose a recent event from the preceding
events output.
SlFS state lives in disk.img. Keep it between reboots for persistence labs,
and reset it when you intentionally want a fresh filesystem.
Lab 01
Boot and identify the machine
Purpose
Establish a clean QEMU session, confirm the kernel reached the shell, and record the machine identity before changing state.
Commands
# host terminal
make run-nographic
# SlOS shell
help
uname
status
neofetch
ps
Expected observation
Boot output reports memory, interrupts, SlFS, networking, timelines, actors, and the mesh as they initialize.
The prompt reaches slos:/$, and uname/status identify the x86 QEMU target, uptime, memory, tasks, and devices.
neofetch runs as an embedded user ELF and returns to the shell when it exits.
Source files to read next
arch/x86/boot.asm
kernel/core/main.c
kernel/apps/shell.c
kernel/apps/cmd_system.c
programs/neofetch.c
Cleanup / reset
Exit nographic QEMU with Ctrl-A then X, or run halt from SlOS. make clean removes build products. Keep disk.img if you want later labs to observe persistence.
Lab 02
Observe recent causal events
Purpose
Learn the event surface before relying on it. The goal is to see event IDs, timestamps, subsystem labels, parent links, and graph health.
events prints records such as [id] T+tick type subsystem: description, with parent and child markers when present.
Type filters show recent filesystem or syscall activity if the ring still contains those records.
graph summarizes the ring and prints recent parent edges. graph-health reports event rate, orphan count, depth, and multi-parent count.
Source files to read next
include/causal.h
kernel/graph/causal.c
kernel/apps/cmd_graph.c
kernel/apps/shell.c
Cleanup / reset
No reset is needed. The causal ring is recent history; new activity naturally advances it.
Lab 03
Create timeline-backed notes and inspect why/trace
Purpose
Create application state through the notes timeline, then inspect the causal path that explains the resulting note and tag.
Commands
note add operator lab note one
note tag last lab
note search operator
note show last
tl show notes
tl tail notes -n 5
events user
why <event-id-from-notes>
trace <event-id-from-notes>
Expected observation
note add returns a note number. note tag records metadata. search and show reconstruct the current notes view.
tl show notes and tl tail notes show the notes timeline entries behind that view.
events user should include notes activity. Use the note-added or tag-attached event ID with why and trace to walk parent edges back toward the shell command or syscall context.
Source files to read next
kernel/apps/notes.c
include/notes.h
kernel/graph/timeline.c
include/timeline.h
kernel/apps/cmd_graph.c
Cleanup / reset
note delete last removes the note from the current reconstructed view and records a deletion event. The timeline remains useful for inspection.
Lab 04
Write/read files through SlFS and inspect persistence commands
Purpose
Exercise the persistent VirtIO-backed filesystem and read the metadata commands used to confirm what changed on disk.
Commands
diskmkdir -p /labs
diskwrite /labs/operator.txt SlFS lab line one
diskappend /labs/operator.txt SlFS lab line two
diskcat /labs/operator.txt
diskstat /labs/operator.txt
diskdf
fsck
diskcache
halt
# host terminal after QEMU exits
make run-nographic
# SlOS shell after reboot
diskcat /labs/operator.txt
disktree /labs 2
fsck
Expected observation
diskcat prints both lines. diskstat reports inode, file type, size, block count, ctime, mtime, and flags.
diskdf reports SlFS block and inode usage. fsck should report a clean filesystem for the normal path.
After reboot, the file remains readable because disk.img backs the VirtIO block device.
Source files to read next
kernel/fs/blockfs.c
include/blockfs.h
kernel/drivers/virtio_blk.c
kernel/apps/cmd_files.c
Makefile
Cleanup / reset
Use diskrm -r /labs to remove lab files. To reset all persistent SlFS state, intentionally replace or remove disk.img before the next boot.
Lab 05
Run a user ELF or built-in program
Purpose
Confirm that embedded user programs run through the ELF loader, then install one to SlFS and run it from a persistent path.
actors prints active local and remote actors, message counters, and mailbox depth. The shell, kernel, fs, net, mail, and dead-letter actors are useful landmarks.
send shell queues a message to the shell actor. recv shell consumes it and prints the type, sender, timestamp, and payload.
mesh prints the local SPIFFE ID and public key. A single-node run may report no discovered peers; a multi-node run lists peer state and transport.
Source files to read next
kernel/graph/actor.c
include/actor.h
kernel/graph/mesh.c
include/mesh.h
kernel/graph/federation.c
Cleanup / reset
Run recv shell until the lab message is gone if you repeat the test. No persistent file state is created.
Lab 07
Use showcase videos as expected-observation references
Purpose
Use the recorded reels as a visual reference while keeping the local QEMU run as the primary observation.
The video frames give approximate screen shape, command order, and output density for each topic.
Local event IDs, ticks, IP addresses, peer IDs, file sizes, and task numbers may differ from the recordings.
When a local result differs, prefer current source and command output, then use the reel to orient what to inspect next.
Source files to read next
programs/showcase.c
kernel/apps/demo.c
kernel/apps/cmd_graph.c
src/pages/showcase.astro
Cleanup / reset
No cleanup is needed. If a demo command leaves files or actors behind, use the relevant lab cleanup above.
Use the showcase as a reference trace alongside local observation. The useful
comparison is command shape, subsystem order, and where to look next in the source.