site  news  contact

How Easy works, part 2

April 02, 2020 — BarryK

Page originally created December 20, 2018

A fairly technical introduction to how Easy works is part-1, here:

Part-1 examines the code executed at early bootup. Part-2 continues, from after bootup has completed, and this is of greater interest to the user. It is however, informative to at least scan through part-1 and pick up the salient points.

The layered filesystem

Recapitulating, here is a diagram from near the end of part-1, giving a pictorial view of the layered filesystem just after bootup:


The diagram shows a boot partition, which has the Linux kernel and various files required for bootup. Then there is the working partition, which is where you "are" after bootup.

In the above example, the working partition is /dev/sdb2, and it contains folders .session, releases/easy-0.9.14, home and containers. The example is for running Easy version 0.9.14, and one file is shown in the easy-0.9.14 folder: easy.sfs.

You can see how those layers are stacked. easy.sfs has all of the files of Easy, it is in fact the entire runtime filesystem. And folder .session has your current working session. Just think of that last one as where all your work occurs -- installed packages, downloaded files, setup, and whatever.

What you see at "/" after bootup is the top of those layers. It is very helpful to have an understanding of this, as after booting up Easy and you look at "/" in the file manager, you will no doubt wonder where are all those files physically located? ROX-Filer (the file manager) will show this:


So, what you are seeing above, is not the working partition! It is actually a kind of artificial construct, that you can think of as existing in RAM.

The working partition

Staying with the example of the drive being /dev/sdb, with sdb1 being the boot-partition and sdb2 the working-partition. How do you get at those folders and files in sdb2? Actually, it is quite simple and logical, look at the icons on the desktop:


This is on the Author's Mele PCG35 mini-PC, where drive sdb is a USB Flash stick that he has booted Easy off. The small orange rectangle at top-right of the sdb2 icon identifies it as unmountable. Click on sdb1 or sdb2 and you can view the contents.

Drive sda is an internal 240GB Kingston 2.5inch SATA3 SSD, and the little "x" top-right of the sda2 icon means that the partition is mounted (and clicking on the "x" will unmount it, in other words, it is a "close box").
A comment about these boot and working partitions. The descriptions so far have been treating them as separate, which is the case with the easy-0.9.14-amd64.img.gz download file (or whatever version you download). However, bear in mind that Easy is designed so that boot partition and working partition could be the same. in which case it would have to be a Linux partition. This will have to be a topic for another time.

Well, there is an installation tutorial that shows boot-partition and working-partition being the same: 

So, if you click on the "sdb2" desktop icon, this is what you will see:


ROX-Filer has been configured to display hidden folders and files, so that you can see .session and .tempwork -- you can look in those folders, but don't change anything, as the aufs/overlay manager will get upset.

The folders of interest to the user are containers, home, releases and sfs


This is where applications can be run in isolation. Each container is a layered filesystem, very similar to the main one, with ro layer easy.sfs, and a rw folder. Additional SFS files may be loaded as ro layers, for example the "devx" SFS for compiling source packages (Puppy users will know all about that!). Containers serve two purposes, isolation and/or security. There is a lot more to say on this topic!


Easy, like Puppy, is a single-user system. With Easy, the home folder has a different meaning to that in Linux/Unix, it is, quite literally, your "home". The basic idea is that this is where you store all your "stuff". Downloaded files, photos, videos, anything. It is a work-in-progress to get the apps in Easy to open in the home folder whenever "File -> Open..." menu operation is performed.
The home folder is permanent storage, it is not affected by the version control mechanisms, upgrading, downgrading, snapshots.


This is a releases for Easy versions and snapshots. For example, if you upgrade from version 0.9.13 to 0.9.14, all of version 0.9.13 is saved in folder releases/easy-0.9.13, and you can at any time roll back -- the menu "Filesystem - > Easy Version Control" handles this.

All SFS files are kept in here, to keep them nicely categorised and avoid duplication.

Now that you are in a running Easy Linux, we can explore from this new viewpoint...

Easy is now running, and the architecture can be further examined. To start, there has been the intriduction in part-1 of "How Easy works", of upgrading Easy. But, how actually do you perform an upgrade?

Upgrade to new version

This is now a separate tutorial:

In a nutshell, it is very easy to upgrade and to rollback.

As the above link explains, there is a nice GUI to manager roll-back and roll-forward. Reproducing a snapshot here:


...which shows after upgrading from 0.9.13 to 0.9.14, and a snapshot was taken in 0.9.13. Roll-back and roll-forward can be to any of these.

You can take a snapshot at any time. All that this does is save the current .session folder, the rw layer, as a file named rw-<date>.sfs, in the releases.

Obviously, saving a complete record of past versions is going to occupy a lot of the working partition. However, the history is saved as compressed SFS files. To avoid the history growing to fill all of the partition, there is a maximum depth setting, set to "3" in the above photo -- meaning that only the current version and two prior are kept.

Another thing to consider, is that the user's "home" is outside of this rollback/snapshot mechanism. /mnt/sdb2/home (for the example of sdb2 being the working partition) is where you can keep all your personal files. Downloads, videos, photos, etc. Try and put as much as you can in here, instead of bulking up the .session folder.

releases sub-folder

All of the files belonging to a particular version of Easy are in a sub-folder inside the releases folder, for example releases/easy-0.9.10. If you were to look inside one of these sub-folders, this is indicative of what you would see:


The configuration files have various configuration variables. SFS file devx.sfs is familiar to Puppy users -- it contains everything to turn Easy into a compiler environment, and can be selected to mount as a layer at bootup. Extra SFS files such as devx.sfs are optional, and can be selected to be added to the layered filesystem at bootup.

It is very easy to add, or remove, an extra SFS file to/from the layered filesystem: see the menu "Filesystem -> Easy BootManager":


...a ticked checkbox will mean it is already loaded.

sfs sub-folder

Notice in the above snapshot, the sfs folder, and in second-from-last "easy.sfs" and "devx.sfs" are symlinks. The purpose of sfs folder is to keep all of the SFS files organised, into categorised sub-folders, and to ensure there isn't unnecessary duplication.

Here is a picture of one such sub-folder under sfs:


Downloading of SFS files is managed via the "sfsget" icon on the desktop.


The init script, the first thing executed at bootup, as explained in part-1, now has an option to encrypt folders in the working-partition. It is not described in part-1, that is a feature added later to the script.

What the init script does now, is ask for a password. If the user decides to provide one, then the containers, releases, home and .session folders in the working-partition are encrypted.

This can only be done when the folders are newly created, with nothing in them. From then on, at every bootup, the password must be entered to unlock them.

The encryption mechanism is only provided for the ext4 filesystem, using "fscrypt", which is a feature built-in to ext4. It provides AES-256 encryption.

Note that the sfs folder is not encrypted. This is because there is no point in encrypting the SFS files, and doing so would only slow down operation.

So, what does a folder look like if you don't have the password to unlock it? In the case-study, sda2 is an installation of EasyOS on internal SSD, whereas have booted up on sdb, a USB-stick.
So, looking into sda2:


...the only way to see the contents of folder home correctly, is to bootup Easy on the internal SSD.

Note that the password entered at bootup is also assigned as the password for "root" and "zeus" users.

Moving on, Easy is designed from scratch to support containers...

Easy containers

Easy has been designed as "container friendly". It was carefully considered how containers would fit in, that is, be highly integrated with the rest of Easy, extremely easy to setup and use, and be very efficient.

There are ready-made container solutions out there, such as LXC and Docker, however, for now Easy is built with a "homebrew" container. The Author is far from being a security or container expert, but for his own satisfaction wanted to play with containers created from basic principles.

So, Easy Containers are not going to be guaranteed secure isolation, and may have other issues, but it is an on-going learning process, and hopefully they will be refined in the months ahead.

It should also be noted that one of the existing solutions such as LXC or Docker could be made to work in Easy linux.

Starting by looking at containers already created in the currently running Easy. ROX-Filer shows the containers folder in the working partition:


Burrowing down, looking inside the easy folder:


This is a container for EasyOS, to run the entire Easy desktop in a container. It runs as a layered filesystem, just like the main Easy filesystem, with easy.sfs on the bottom (the .ro0 folder), a read-write layer (the .session folder), and the "top" (the container folder).

But, back-tracking for a moment. How did the easy container get created? And how to run it?

Well, Easy is setup so that easy, console and www are pre-created, however, it is very easy to create a container for any application -- there is a nice GUI, called Easy Containers.

It is launched via the Filesystem menu:


Here is a snapshot:


An existing container can have its behaviour modified, or be deleted, as shown.

To create a new container, it is just a matter of selecting an app from the drop-down list, choose appropriate security options, then click the "create" button.

There is help available for making the best decisions regarding security, but also there are templates that will preset the checkboxes when you choose an app.

Technical note: these templates are located at /usr/local/easy_containers/templates

A desktop icon is automatically created. These are the pre-created container icons:


...just click on an icon to launch it!

Furthermore, a new menu entry is automatically created, just like this one for SeaMonkey:


...two SeaMonkey entries. You can choose to run it normally or in the container.

Note the special icon used to denote apps that run in a container.

There isn't anything more to say, that's it, container created and ready to use.

What actually happens if you select that containerized SeaMonkey entry in the menu, is that it executes "ec-chroot seamonkey", instead of just "seamonkey".

ec-chroot is a script, found in /usr/local/easy_containers/. In a nutshell, it will "start" the container, then chroot into it and run the app.
By "start", I mean that the layered filesystem will be setup. ec-chroot calls another script to do this, named start-container.

When the app terminates, or the container is in other ways exited, ec-chroot calls stop-container, which kills all processes running in the container and unmounts everything.

This technical description of scripts is only mentioned if you are interested. For someone who is just a user, the GUI does it all, and very simply.

A note about the efficiency of Easy Containers. There is virtually no overhead to add a container. No files are duplicated. The same easy.sfs is used as for the main Easy Linux.
Of course, running an app in a container, it will create its own cache files and so on.

The container layered filesystem

What is the point of running an app inside a container? Thinking about the user, who isn't concerned about the technical details, just what practical benefits the container concept brings, or what problems.

Broadly, there are two reasons, one, to provide isolation from the rest of EasyOS, and second, security. A diagram helps here, to show the filesystem you have access to while running in a container:


The example is for a container named seamonkey. easy.sfs is mounted on folder .ro0 and this becomes the bottom read-only layer (also, there can be more ro layers). The folder .session is rw, and the user's view in the running container is folder container. This was already explained, however, think about it...

The app running in the container, or any file manager or terminal emulator, will only be able to see the files in folder container. Which is the content of easy.sfs and any changes made on the rw layer. That's it, the rest of the system is just not there.

Yet, as folder .session is just a folder in the working partition, the entire storage area of the working partition is available. If the working partition has, say, 14.5GB free space, that's how much free space you will have in your container.

After you exit from the container, if you want to access files created in the container, just look at /mnt/sdb2/containers/seamonkey/.session (the the example of working partition being sdb2). Or, while your container is running, /mnt/sdb2/containers/seamonkey/container.

There are security options, that will impose further restrictions on what can be done, with a view to keeping someone with ill-intent from somehow accessing outside the container. This is neat, but there is a downside. Some apps might not work, or not properly, especially as more of the security options are turned on.


Reading the above might tend to cloud the understanding. EasyOS is best "just used", that is, use it and you will find it is easy. It becomes complicated when there is an attempt to explain everything that goes on "under the hood".

Yes, the Easy Container Manager, snapshot above, can turn any app into a containerised app. Great.

There is also an online repository of SFS files, and these can be downloaded and run in containers. These SFS files can be individual apps or complete distributions.

The easy container, described above, is an example of a complete EasyOS running in a container, as a separate window.

There is an icon on the desktop, labeled "sfsget", click on that and you can access the online SFS repository. This link is an example, showing downloading of Xenialpup 7.5, a complete Puppy Linux distro:

So, yeah, read these technical pages, but do go and actually do it, to appreciate the simplicity.

If you would like to learn more about the online SFS repository and even how you can create your own SFS repository that SFSget can access -- with a view to making it available to others -- please read this blog post: would also need to learn how the 'dir2sfs' utility works, see here: 

Improving and customizing Easy

This is early days for Easy. An earlier experimental distribution by the Author was Quirky Linux, now retired. Quirky was designed as a traditional full-installation only, not using a layered filesystem, no initramfs, and special ramdisk for filesystem repair and system rollback.

Easy was a sudden idea in January 2017, a completely different approach, going back to the layered filesystem and a initramfs, and has now borne fruit.

Easy releases are currently being built with binary packages compiled from source by oe-qky-source, a fork of OpenEmbedded. So, totally independent of any other distro. The WoofE build system inherits the capability of the Woof build system in Puppy, to use the binary packages of almost any other distribution..

Anyway, this is early days for Easy, and input is most welcome. the Author has only just got started with containers. He has setup a very efficient infrastructure, but of course the devil is in the details. If you would like to look into improving containers, getting apps to run, improving security, etc., go for it!

One thing to note about Easy is that it inherits the run-as-root-only from Puppy. With Puppy, there is a different approach, to run specific Internet apps as user "spot". So, the user, you, remain always as the root-user, or administrator. You can find some documentation that justifies this locally here:

About root, spot and fido

With containers in EasyOS, the situation changes somewhat. Running as "crippled root" inside a container, which is similar to running as a non-root user.

If you are not a developer or into coding, but a user with an interest in customizing Easy, there are tools that can make this a lot of fun.

As has already been explained on this web page, just by clicking on the downloaded Easy image file, for example file easy-0.1.7-amd64.img.gz, you can open it up and see the files inside (similarly, you click on the file to close it up again).

Inside the image file, a most important file is easy.sfs, which has the entire Easy Linux filesystem, from "/" down. Well, there are GUI tools to create your own easy.sfs, and just replace the old one, then close up the image file, and you have a customized Easy! Sometimes this is referred to as remastering, though that term really applies to optical media.

If you would like to explore remastering, look at a couple of tools in the Setup menu:


The two entries of interest are "Remaster Easy Linux" and "Remove builtin packages". Note, Puppy Linux has these as well, they have been rewritten for Easy.

By removing packages that are already in easy.sfs, and installing your own packages, either compiled yourself or from the Ubuntu repositories, you can then create your own easy.sfs and put it into the deployable image file. Voila, you have your own customized Easy Linux!

It is not just changes in packages, but bug fixes, user-interface improvements, etc., will also go into your new easy.sfs.

There is a web page that is a summary of how and why EasyOS is different from other distributions: 

...a handy page for anyone who wants to get a quick appreciation of what Easy is all about.

Disclaimers, legal, miscellania

Some final notes about EasyOS. Where not explicitly stated or implied, code, text, artwork and concepts are copyrighted to the Author, Barry Kauler, with GPL license version 3.

Regarding responsibility for what the Author has uploaded for distribution on the Internet, although he has acted in good faith, there is a complete disclaimer of all responsibility. This applies to everything, including code and documentation. You download and use Easy Linux with this understanding.

Easy is currently considered to be beta-quality, and in some places alpha. Please bear this in mind when using it.

Have fun! Barry looks forward to interacting with you on the forum.

Tags: tech