OS customization is a very easy task with WALT, and it is probably one of the most popular features. Users can very quickly adapt one or more OS images to their research experiment or industrial test, and then boot these custom OS images on nodes in a snap.

Let’s start by a quick reminder. Behind the scene, WALT OS images are just docker-compatible container images. However:

  • WALT only uses this container image format for packaging OS images. The deployment on nodes relies on Network Boot instead.
  • Unlike a usual container image, a WALT image contains not only an application but the whole OS, including a Linux kernel and bootloader scripts.

For more info, check out the blog post presenting the concept of Network bootable containers.

WALT usage workflow

WALT usage is usually a two-steps process:

  1. Adapt OS images for a research experiment or industrial test, automating everything at OS bootup.
  2. Let nodes (re-)boot these custom OS images.

Step 1 can be handled in various ways, as shown in the following section. Step 2 is usually repeated N times for getting sensible statistics.

The various options for modifying a WALT image

Command walt image shell: “Quick and easy” OS editing

This terminal recording shows how quickly and easily you can update an OS image. Here, we modify a Debian-based OS image currently booted by two virtual nodes. We install a variant of the Linux kernel which is patched for real-time constraints.

Do not confuse walt image shell with walt node shell. With walt image shell, we are just preparing an OS image, not working with nodes yet. See the help topic about shells for more info.

For a real case, one will also have to automate the startup of an experiment script when the node has completed its boot procedure1.

The default OS images we provide are based on Debian, but WALT is not restricted to this OS. A few alternative images based on Alpine Linux or OpenWRT already exist. Type walt image search <keyword> to find them.

Command walt image build: reproducible image building

This terminal recording builds the same WALT image but uses a Dockerfile instead, for a more reproducible image building process.

You can also use --from-url instead of --from-dir to target build files of a remote git repository (e.g., a repository published on github).

This new image linux-rt-2 might actually be a little different compared to linux-rt built in the previous section. Here, the Dockerfile starts with FROM waltplatform/pc-x86-64-default:latest, which targets the image pc-x86-64-default of user waltplatform. User waltplatform is a kind of “default user” in WALT2. For using the same base image as I did with walt image shell, I should have specified FROM <myself>/pc-x86-64-default:latest instead, where <myself> is my username3. Initially my version of pc-x86-64-default was just a clone of waltplatform/pc-x86-64-default:latest, but those images may have diverged over time.

Note that if the image specified by the FROM directive is not found locally on the server, it will be downloaded from the docker hub (or any other registry configured on the WALT server).

Command walt node save: save changes made on a node

The following terminal recording describes a third way to build the same image. This feature is available since WALT v10. Instead of modifying an OS image and then booting it on nodes, proceeding in reverse is now possible too. This means one can do the changes directly on a node, and then use walt node save to save these changes as a new OS image.

Note that making heavy file system operations like this, in a walt node shell session, may not work properly unless you are using our most up-to-date Debian images and a WALT v10 server4.

Among other uses, walt node save will allow to overcome limits of walt image shell and walt image build. Behind the scene, walt image shell and walt image build both rely on the container technology. For instance, walt image shell relies on podman run to start a container and then give you access to a shell rooted in this container. But this container environment is not a real machine, so some setup scripts you may want to reuse could fail if they try to communicate with node hardware or peripherals. Privileged operations (e.g., configuring firewall rules) will also fail. An alternative workflow made of walt node shell and walt node save can easily work around those limits.

This idea of doing a part of OS image building on a real node may even be extended to walt image build in the future. See this improvement proposal for more info.

Command walt image cp: copy files from or to an OS image

Command walt image cp resemble walt node cp or the standard scp, but instead of communicating with a remote machine, it transfers files to (or from) one of your OS images.

The 1st form, walt image cp <local-file-or-dir> <image-name>:<path>, will transfer a file or directory of your local machine and integrate it at <path> in <image-name>.

For the sake of completeness, let us also mention the 2nd form: walt image cp <image-name>:<path> <local-path>. This form will fetch a file or directory contained in <image-name> and make a copy on your local machine. But obviously this form will not modify the OS image <image-name>.

Ending words

Even if it is possible to build a WALT image from scratch, most WALT users typically modify our default images to suit their needs, using one of the methods described above.

You can get more details in the documentation pages for walt image build, walt image cp and the topic about shells.

Thanks to Jérémie Finiel for proofreading. If you have questions, we can answer you on the mailing list. Last edit: july 18, 2025, for reflecting the features now public with WALT v10.

  1. There are several ways to automate the startup of an experiment script when the node has completed its boot procedure. If the OS image is based on systemd, this can be done by adding a custom systemd service in /etc/systemd/system/. Alternatively a job can be added in crontab with a @reboot directive. Or, even simpler, if an executable file is found at /bin/on-bootup, WALT nodes will run it at the end of their boot procedure. ↩︎

  2. waltplatform is a “default user” in WALT, and the user corresponding to “free nodes”. The first time a node is detected, it boots a default image named waltplatform/<node-model>-default:latest, and it appears in the list of “free nodes” (when typing walt node show --all). Later, when a user “acquires” this node (using walt node acquire), the node is then associated with an OS image of this user (i.e., <username>/<image-name>[:<tag>]). Finally, if the user releases the node (using walt node release), it is again associated to its default image waltplatform/<node-model>-default:latest, and it appears back in the list of free nodes. ↩︎

  3. If you forgot which username you chose when you started to use walt, you can retrieve it in $HOME/.walt/config. ↩︎

  4. In the default boot mode, the local storage of the node is not used, so file modifications are stored in RAM. This ensures “reproducibility at each reboot”: the node only relies on the read-only OS image, free of any artefact from previous runs. But this also implies a limited space for file modifications due to the limited RAM space. However, our latest Debian images include package nbd-client, allowing nodes to use a remote swap space on the server and to properly deal with this kind of situation. ↩︎