Sunday 19 May 2024 - 01:33:18 UTC 
RSS Feed
SARPi Project - Slacking on a Raspberry Pi
Slackware Linux In A Docker Container
The Slackware Linux mini root filesystem can be built into a Docker image and run in a container. Running Slackware Linux in a Docker container may be useful and/or preferable for a multitude of reasons and purposes.
Not only can the Slackware Linux mini root filesystem be run in a Docker container on a system running Slackware Linux, it can also be run on other ARM-based Linux systems, such as Raspbian, Ubuntu, or CentOS (etc.) which have the Docker virtualisation environment installed. Therefore it can be used to; test new software or procedures, run instances of programs and/or scripts, create new projects, learn and gain more experience with the system without fear of breaking anything, or any other task that Slackware Linux can perform. It might also be interesting and useful for users of other Linux systems in order to test-run and tryout the Slackware Linux OS without affecting their host systems. The possibilities are virtually limitless.
About this SARPi Mini-Project
The information on this page contains instructions on how to run the Slackware Linux mini root filesystem in a Docker container. It also includes details of the Docker commands and functions required to successfully manage images and containers within that scope. That can be on the Slackware Linux operating system itself, or another Linux based system.This guide does not contain any details on how to install Docker on Slackware Linux. For that there is a "SARPi Project - HOW TO install and run Docker on Slackware Linux on a Raspberry Pi" guide, if needed. For other [Debian-based] Raspberry Pi operating systems there's a "How To Install Docker and Docker-Compose On Raspberry Pi" external website guide. For CentOS on the Raspberry Pi there's a "How to Install Docker on CentOS 7" external website guide.
NB: The information on this page assumes that Docker is already fully installed and working on a Raspberry Pi host operating system.
•
What's required to run Slackware Linux in a Docker container?
In order to run Slackware Linux operating system in a Docker container you will need to do the following:
• Run Docker containers under a normal 'user' on your system (i.e. not 'root').
• Create a Docker working directory. [if one doesn't exist]
• Create a Dockerfile.
• Download a Slackware Linux mini root filesystem tarball.
• Build a Docker image and run it in a container.
For convenience, instructions and examples to "Attach to and detach from an active Docker container", and for "Backing up a Docker image to a saved tarball" and "Loading a Docker image from a saved tarball", are also included.
All the Docker commands are provided and illustrated on this page, and the Dockerfile code content. The only thing you will need to do is decide the version of the Slackware Linux mini root filesystem tarball that you'll be using. It doesn't have to be Slackware AArch64 current.
We'll be using a Raspberry Pi 4 [4GB] but any version with an operating system that's running Docker will suffice. We'll be running the latest Raspberry Pi OS - Raspbian GNU/Linux 11 (bullseye) - as a proof of concept in this guide. This will demonstrate how Docker is so easily portable to other systems and platforms, because building a Docker image and running it in a container on Slackware Linux involves exactly the same process and procedure.
Throughout this "Slackware Linux In A Docker Container" guide, we will be logged in as the default 'pi' user on a fully updated Raspberry Pi OS (bullseye) latest release version with the default hostname of 'raspberrypi', with Docker and all its dependencies installed, on a Raspberry Pi 4 [4GB] Model B device.
•
Creating a working Docker directory
If you are not already aware, creating a "working directory" in which to store all the files for creating Docker images is a very good idea. It keeps everything in the same place and is easier to manage and maintain. Inside the docker directory will be another aptly named "repository directory" that holds the Dockerfile and any other required content which we want to be included when making a Docker image. It's practical, orderly, and sensible to to it like this. The '/home/pi/docker' directory is what's known as a "working directory" in this instance because that's the directory where our user will be entering the Docker commands, and where our "repository directory" is located. For further Docker projects we can just create more directories within the "working directory" and use them as a "repository directory" in the same way.
So, first we'll create a "working directory" for Docker purposes in our '/home/pi' directory. As we'll be running Slackware AArch64 current mini root filesystem in our Docker container, we'll name our "repository directory" (i.e. where the Dockerfile is located) as 'slackwarearm-current' so that we know which Docker image it relates to. Nice and simple, which is the Slackware way. We can create both directories with one easy 'mkdir -p' command option.
pi@raspberry:~ $ cd docker
The directories we need are now in place and we've changed our current directory ('cd') to the 'docker' working directory. On to creating a Dockerfile.
•
Creating a Dockerfile
A Dockerfile is a text document that contains any of the Docker commands a user could enter on the command line in order to build a Docker image. The Docker 'build' command will assemble an image from a Dockerfile that it uses as a template. A Dockerfile contains all the instructions, and the path/to/any/files (local and/or remote) that should be included, within the image.
We're going to be using the Slackware Linux mini root filesystem tarball within this image, and that will be downloaded into the same directory as our Dockerfile by the next step in this process but the code to add it into the image will be entered into the Dockerfile that's created. You can use any text editor that suits you to do this; vim, nano, gedit, elvis, pico, vi, geany, kate, or whichever. It really does not matter, but 'nano' is the text editor we'll be using here. However, the code involved is very important as it needs to be correct for the image to be built without any errors. Or it might not work as intended. Note the capital "D" in the Dockerfile filename!
Here we will enter the code that needs to be in the Dockerfile. Lines that start with a '#hash' are commented out and will not be read by the Docker build process. Everything else will.
What you need to do here is look to see which Slackware Linux mini root filesystem tarball you're intending to use in the Docker image. These tarballs are located at http://ftp.www.slackware.com/ports//slackwarearm/slackwarearm-devtools/minirootfs/roots/ and there are many. These files are all created by Stuart Winter (a.k.a. MoZes) the Slackware Linux developer and are therefore official Slackware mini root filesystem (xz compressed) archives. Suffice to say, whichever tarball you select is the filename that must feature on the "ADD slackarm-current-miniroot_08Oct21.tar.xz" line below in our example. Even a typo in the filename will cause an error. So, ensure that this file is named and referenced correctly.
The Slackware Linux mini root filesystem tarball we have chosen is 'slackarm-current-miniroot_08Oct21.tar.xz' which should be obvious by the filename we have specified on the ADD line in the Dockerfile - there might be a more updated version available since then. Check the URL above beforehand as that will be the file you download in the next step after this one.
This is what the Dockerfile content looks like:
# PATH: /home/pi/docker/slackwarearm-current/Dockerfile
FROM scratch
MAINTAINER SARPi Project [https://sarpi.penthux.net]
ADD slackarm-current-miniroot_08Oct21.tar.xz /
RUN echo -e "# Set Docker PS1\nPS1='\\u@slackware:\\w\\$ '" >> /etc/profile
CMD ["/bin/bash"]
You can cut and paste the text above into your Dockerfile. Or you can download the Dockerfile if it's easier. Just be mindful that, if the Slackware %A54_ISA_NAME% current mini root filesystem tarball filename you're working with is different to the one in the Dockerfile then you will need to edit the ADD line filename so it matches perfectly.
The next step is to download the Slackware AArch64 current mini root filesystem tarball.
•
Download a Slackware Linux mini root filesystem
We have already visited http://ftp.www.slackware.com/ports//slackwarearm/slackwarearm-devtools/minirootfs/roots/ and know what the filename of the Slackware AArch64 -current mini root filesystem tarball is. So, this will be very easy. We'll use 'wget' to download the file and use an extra option so that the file ends up in our 'slackwarearm-current' directory.
http://ftp.www.slackware.com/ports//slackwarearm/slackwarearm-devtools/minirootfs/roots/slackarm-current-miniroot_08Oct21.tar.xz \
-P slackwarearm-current/
Now we'll check to make sure the 'Dockerfile' and 'slackarm-current-miniroot_08Oct21.tar.xz' tarball are present and correct, where they should be. A simple 'ls' command will verify this.
They they are, right where they should be. now on to the final step, building a Docker image and running a container.
•
Build a Docker image and run it in a container
To assemble an image we use the Docker 'build' command. The '-t slackwarearm-current:latest' is a tag that means "REPOSITORY_NAME:TAG" with the path to our Docker repository directory following it. This tells Docker to build with that specified tag and use the repository directory to create an image. The Dockerfile within the repository directory includes the instructions that Docker will use to create the image successfully.
The screenshot below shows the results of running the Docker 'build' command.
Now there should be a Docker image available and ready to run. We can check to see with a Docker 'image' command.
The screenshot below shows that a Docker image has been created in the 'slackwarearm-current; repository with the 'latest' TAG and '259c70a96e03' ID.
This looks perfect. Incidentally, if we wanted to list all the Docker images on our system (as the default hides intermediate images) then we would use 'docker images ls -a' command.
Now we're going to use Docker 'run' command on this image and also give it a specific name so that it's appropriately identifiable and easier to work with. Some, if not most, of the container names that the Docker software auto-generates are extraneous.
When a Docker image is run it becomes a 'container'. That's the process which happens when Docker 'run' command is used. So, what does the Docker 'run' command below contain and what does it all mean?
Expaining the Docker 'run' command options and arguments;
-t = allocate a pseudo-TTY.
-i = make the container user-interactive.
--name = assign the value that follows as the container NAME (ours is "slackarm-docker").
--privileged = give the container extended privileges to do almost everything that the host OS can do.
slackwarearm-current:latest = our Docker node IMAGE:TAG.
bash -l = run 'bash' and make it act as if it had been invoked as a login shell.
The screenshot below is the result of running this command.
Try it out, play with Slackware Linux, add a few users, do all the things you like to do or never dared to do. Or, if you're stuck for ideas, why not try something like this?
root@slackware:/# slackpkg install slackware
WARNING! The caveat to running containers, with or without the '--privilege' option, is NEVER run them as 'root' user. Always use a normal, limited, user for this purpose. Running anything in a container should be treated with the same level of condsideration as if it were running on the host OS. Security concerns and implications are the same for running any software in a container as 'root' user as they are on the host system. After all, they use the same kernel meaning there's all the more reason to be wary. The 'root' user has access to everything and, even though it may be running in a container, it's no different from any other process that can be executed.
OK! So, how do we exit the container when we're done? We simply type 'exit' and it stops the container and puts us back at the colourful Raspbian command prompt once again.
Then we can list the container(s) and see their attributes. Now we'll use the 'docker containers ls -a' command to list ALL containers, whether they are active (i.e. running) or not. Without the '-a' option only active containers will show but we know ours is stopped and that's exactly why we need it here.
The screenshot below shows us that the Docker container has; 'd3291c3accd7' CONTAINER_ID and 'slackarm-docker' NAME. There's other information given about this container but these are the values we need to note. They will be useful for when we want to start and stop the container, or do other things with it.
So we will run the slackarm-docker" container again with the Docker 'start' command.
That's fired up the container. Now we need to attach to it and we do that with the Docker 'exec' command.
Then we should see ourselves back in the container on the 'root@slackware' command line prompt. In the screenshot below we do, as expected.
So when we've finished with the container, and want to 'stop' it from running, we can just 'exit' and leave it until we need it for something else. At which time we can just 'start' it up again.
Attach to and detach from an active Docker container
To exit (detach) from a Docker container and leave it running, we'd use the + , + key combination. That would detach us from the container successfully.
To attach to a running container we use the Docker 'attach' command.
This will put us back in the running container at the 'root@slackware' command prompt. The following screenshot 'docker container ls' command shows an active (running) container, the 'docker attach <CONTAINER_NAME>' command, and the + , + detach keystrokes used. Another 'docker container ls' command shows that the container is still running and active after we've detached from it.
That's an example of how to detach from an interactive container and leave it running and active, in the event that stopping it is not desirable.
It's very possible to do something similar, and a whole lot more, with any software that runs in a container. For example, there's interactive containers and there's also containers that run in the background which require no direct user interaction. Imagine the potential and possibilities. The mind boggles.
Backup a Docker image to a saved tarball
When we are happy with the image that's been created, modifed, and/or updated, and want to save its current state as a backup it can be achieved with the Docker 'save' command. This enables the image to be compressed, to cut down on filesize, using 'tar', 'gzip', or 'xz' and saved on our system as a tarball.
This will use 'xz' maximum compression to save the image tarball to our 'docker' working directory.
We could just as easily have used 'tar' or 'gzip' instead of 'xz' to achieve this. It's entirely up to you which compression format you use and prefer. Some systems may need these tools installing, but gernally they are provided as standard on most modern Linux distributions.
pi@raspberry:~/docker $ docker save slackwarearm-current:latest | gzip > slackwarearm-current-latest.tar.gz
All these methods of saving images to tarballs work just as well. The size of the resulting tarball is the only factor to consider. Compare the difference in file sizes from the example screenshot below.
Now that these image tarballs exist they can be managed, shared, uploaded to a repository for others to download and use, kept as a backup or snapshot, etc. It can also be loaded as an image again on the system or any other, by you or by someone else you share the image with. We will show how easy it is to work with saved Docker images in the next illustration.
Load a Docker image from a saved tarball
As an example to show how convenient images and containers are, and how effortless they are to manage, we will wipe our incumbent 'slackwarearm-current:latest' image from the system and load it again using the image tarball we've just created.
First we need to remove the container, before removing the image. We are not allowed to remove an image that has an adjoined active/inactive container, for obvious reasons. So we use the 'docker container list' command to find out the container ID and then use that to remove it.
The container had an ID of 'd3291c3accd7' so that's the one which was removed.
There's a very useful Docker 'rmi' command that removes one or more images and their tags all in one go. We can use that here.
As you can see from the screenshot above, we used 'docker rmi slackwarearm-current' command to remove all images in our Docker 'slackwarearm-current' repository. This removed the image and any child images along with it. Then, when we listed all the images available in our repository, using 'docker image ls -a' command, none were found. This is exactly what we wanted to achieve.
So, now with no images in our Docker repository, we can load the image from the tarball we created previously. Of course, it's the same image that we've just deleted, but for this example it serves the purpose. To load an image tarball into our repository as an image we will use the Docker 'load' command.
The screenshot below shows the results of using this command.
The same as we did previously, we need to run the image to create a container and we'll invoke the 'bash -l' command to log into it as if it were a regular shell.
This, as before, connects us to the container where we find ourselves at the 'root@slackware' command prompt.
The saving of an image to a tarball, deleting existing images, and loading an image tarball, all worked 100% successfully.
These examples hopefully show how convenient and useful containers are, not just for using on your own system but for porting and sharing with other systems or over the Internet.
Slackware Linux mini root filesystem in a container - conclusion
Pretty neat. Huh? This guide is just one example of how users can run containers with images of the Slackware Linux mini root filesystem (or any operating system that will run and is available as a Docker image) and use it just like the real thing. It virtually is the real thing, is why! There are some limitations but we're not going to cover them here, along with a lot of other topics and examples of how to use Docker images and containers. That's for you to find out about yourself. This guide only attempts to open the door and show what's at the other side. It does not try to re-invent the wheel. Just remember that https://docs.docker.com website may be one of the more valuable resources, along with many others.
Did anybody notice there was a Slackware AArch64 mini root filesystem tarball on http://ftp.www.slackware.com/ports//slackwarearm/slackwarearm-devtools/minirootfs/roots/ repository?
The screenshot above shows the latest Raspberry Pi GNU/Linux 11.1 (bullseye) 64-bit OS with Docker installed, running Slackware AArch64 -current miniroot image tarball in a container.
Have fun, whatever you may find yourself doing with Docker, images, and containers.
•
Thanks!
Thank you for reading and taking part in this SARPi mini-project. We hope you enjoyed it and found it interesting and educational.
Thanks also to Patrick Volkerding, and the entire Slackware Team, for producing a truly wonderful OS. Without you, and the work you do, the SARPi Project would not exist.
If you have any questions or need help, visit the Slackware Linux Forum on Linux Questions. Or get in touch on the #SARPi IRC channel on irc.libera.chat.
•
