We tried the openSUSE MicroOS in a virtual machine. Here’s how it looks.
A while back, I wrote about the Adaptable Linux Platform (ALP) from openSUSE, which may replace the current long-term-support version of openSUSE Leap.
During that time, little information was available on what exactly ALP is? How does it look?
That said, we now have a test ISO to try additional detail about openSUSE MicroOS. And I did a quick spin and listed down the findings.
What is an Adaptable Linux Platform?
By definition, openSUSE Micro OS via ALP introduces an atomic and transactional-based Linux operating system with a read-only root partition (via the btrfs file system). Targeted to host container workloads, it gives several advantages over traditional Linux Operating systems.
Your root file system remains intact in every boot over your installation’s life cycle. The OS updates happen via HTTPS, and it’s atomic in nature. Via btrfs, the MicroOS creates multiple subvolumes – read-only and writable. This is one of the great advantages of btrfs, which Fedora Linux adopted as a default file system last year.
You might be wondering, what about the software or apps you install. Well, when you install applications in MicroOS, it gets installed in a container completely separate from the root file system. It gives you advantages of early rollback, safe for harmful scripts and easy recovery for a failed system.
What is the future of openSUSE Leap?
Although it is not clear about the future of openSUSE Leap but looks like the final release of openSUSE Leap would be 15.5, which is due on 2023. And after that, MicroOS gets the “Leap” version of openSUSE.
“SUSE Linux Enterprise 15 is using the tick-tock model, where 15 SP4 would be the feature release while 15 SP5 would be more of a bug fix or perhaps it better to say maintenance release” says Lubos Kocman in an earlier email.
openSUSE MicroOS – Test Drive
Download and Installation
Almost all the necessary types of MicroOS images are available, classified by CPU architecture and platforms. So, you have the traditional 64-bit ISO image with Desktop Environments for desktops, laptops, and then the other container, cloud and VM images.
For Laptops and desktops, the available options at the moment are GNOME & KDE Plasma. And it supports only KVM for virtual machines (such as virt-manager).
I downloaded the KDE Plasma edition with a full DVD image of around 3+ GB in size. You can find the download links here.
The installer is the same as the openSUSE installer. However, there are specific settings for the type of MicroOS installation you want to perform. For example, before installation, you need to choose whether the installation is for desktops, containers, remote attestations and others.
Thus, a default installation, for example, KDE Plasma, takes approx 2 GB of disk space.
The installation went fine, with no problem whatsoever.
Inner Workings of openSUSE MicroOS
From an average user standpoint, you may not find any difference between a normal openSUSE install and a MicroOS installation. The same Login screens, desktops and apps.
But there are differences in how it is configured.
Firstly, the installation partition has several subvolumes. As you can see in the below image, it has several volumes, including a .snapshot directory. This directory stores snapshots of your system, as mentioned above. It’s a complete file system copy.
The .snapshot directory is further expanded with the snapshot#, which increments by 1 starting with 1. As you can see in the image below, the first snapshot 1 has a complete filesystem copy.
Since the system is read-only, you can’t do much. That’s the idea of an atomic system. But it is difficult for an average user to try it out if they don’t have a concept of a container or usage of the Toolbox. For example, there are no browser or Yast packages to install. Since I have used KDE Plasma, Discover won’t let me install any apps.
And Zypper is also not allowing it to.
But the Toolbox worked as it was supposed to. Initially, I thought it was not installed by default.
The default installation of the Toolbox worked perfectly; it created a container by default with the username.
I managed to install a sample package to test the container in MicroOS.
I hope this helps you to understand and get an idea about the openSUSE MicroOS and its inner workings. Since it is still under development, many changes may arrive in the future.
If you are an openSUSE Leap user, you must try it and see how it’s falling into your current workflow. Because at a certain point in future, Leap shall not be available anymore. So, you may want to adopt MicroOS or Tumbleweed.
Hence, the team is also looking for your feedback, comments or suggestions while you try this dev build and help to steer its development and decisions. You can create a post on the official mailing list with your feedback and questions.
Finally, what do you think about MicroOS and Leap’s future? Does it beneficial for the sysadmins and average users? Let me know in the comment box below.
Via openSUSE Blog