Foreword
So, let me just say that this is going to be a very quick and probably a rather terse post. Fact is, I’m giving this talk, next Saturday, within openSUSE + LibreOffice Virtual Conference 2020 and I figured that, in case anyone wanted to try replicating my setup, something that can be read (or from where to cut-&-paste) could maybe be more useful than a YouTube video and slides in PDF.
Here’s the talk, by the way. And here they are the slides (link updated to the most recent version of the slides on Oct 17 2020, 11:30):
Many topics that I’m only touching on here would deserve being discussed at length, in a dedicated post or talk… and maybe it will happen. Just not here. ;-P
What’s MicroOS
See, it did not took much before we got to something about which we could talk for hours, and instead we’re only glossing over it! So, citing from our Wiki:
“[…] openSUSE MicroOS is an operating system you don’t have to worry about. It’s designed for but not limited to container hosts and edge devices. […]. openSUSE MicroOS inherits the openSUSE Tumbleweed and SUSE Linux Enterprise knowledge while redefining the operating system into a small, efficient and reliable distribution.”
And that’s all I’m going to say about it! There are talks that you can watch, though, to get a better idea.
The MicoOS Portal in openSUSE Wiki is in a good shape, IMO, and hence can be used as a fine source of information: Portal:MicroOS.
Of course, the deal is that you help us keep it fresh and accurate, as usual with Wikis! Anyway, perhaps the Features and the Design pages are good starting points.
Oh, and we are on Twitter. 🙂
MicroOS as a Desktop
Talks again!
And this one as well, still from Richard, right at the same conference! 🙂
UPDATE: Recording of Richard’s talk at openSUSE + LibreOffice Conference 2020 is now available:
Maybe you heard, or are familiar with, Fedora Silverblue (as it’s around for a little while now, and is already usable). The end goal of MicroOS as a Desktop would be to have something like that. But green.
Well, of course, the color is not the only difference. E.g., MicroOS uses BTRFS snapshots for “playing the immutable OS” game and for giving you transactional updates that do not touch the running system. And, if something is not good at the next reboot, rolling back automatically. But again… Not this time.
So, long story short, my colleague Richard Brown had this idea of trying to use MicroOS to build an openSUSE immutable desktop system. He put up an HackWeek project [*](HackWeek is that week of the year during which SUSE encourages its employees to do whatever they found cool). I happened to find it really cool and joined. I mostly did testing and started working on toolbox. A few months later, I decided to go all-in. And here we are.
[*] Actually, that’s the HackWeek project from the latest HackWeek, i.e., the one I joined. But he was working on that in previous HackWeeks as well.
Download and Install
This is easy. Get it from here:
- https://microos.opensuse.org/
- https://en.opensuse.org/Portal:MicroOS/Downloads
- https://download.opensuse.org/tumbleweed/iso/openSUSE-MicroOS-DVD-x86_64-Current.iso
And install it! Pick MicroOS Desktop [GNOME] [ALPHA] as a flavor, when you get to this point:
Oh, if you want KDE, that is also fine, of course. I just happen to not really know the status of it, as I’m neither using nor testing it. My SUSE colleague Fabian is, though.
Post Install Configurations
First of all, do this. In fact, flatpak
is already installed, but there is no remote configured. Also, we want GNOME Software to only deal with Flatpaks. We’re working on making the installer doing this, but we’re not there yet. So, just after finished installed, login and do the following:
$ gsettings set org.gnome.software install-bundles-system-wide false $ gsettings set org.gnome.software allow-updates false $ gsettings set org.gnome.software download-updates false $ gsettings set org.gnome.software enable-repos-dialog false $ gsettings set org.gnome.software first-run true
And the following:
$ flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
And the following:
$ sudo rm -Rf /var/cache/app-info $ sudo transactional-update shell # rpm -e --nodeps libzypp-plugin-appdata # zypper al libzypp-plugin-appdata # exit $ sudo reboot
And do actually reboot the system. It’s best if you do it immediately (or as soon as possible).
Basically, we are going to use Flatpak for pretty much all the apps, except than for the packages that are part of the core of the OS and of the desktop environment. We will pick the flatpaks from the Flathub “repository” and we will install them “as user”, i.e., they’ll go you your user’s home directory (inside an hidden directory called ~/.var
).
Do this as well:
# echo "<yourusername>:100000:65536" > /etc/subuid # echo "<yourusername>:100000:65536" > /etc/subgid
It will turn out useful when we start using podman rootless containers as toolbox-es.
DO NOT add any additional repositories. Not even Packman for the multimedia codecs. The point is that, as stated already, we want to install as few packages as possible. Ideally, you’d (have to) install none, but we’re not there yet.
I recommend disabling automatic updating and rebooting as well. It’s a cool feature, and we’re thinking about how to have it better integrated into a desktop distribution. For now, I’ve disabled it and I recommend doing the same, at least until you have learned a little bit about it, are more familiar with the idea and with the basics of how it works, and come come-up with the best automatic updating & rebooting strategy for your workflow and use case. So:
$ sudo systemctl disable --now transactional-update.timer $ sudo systemctl disable --now rebootmgr.service
And then let’s check:
$ sudo rebootmgrctl is-active
RebootMgr is dead
$ sudo rebootmgrctl status
Error: The name org.opensuse.RebootMgr was not provided by any .service files
For more insights about all the super nice and fancy things that rebootmgr and healt-checker can do for you, check these Wiki entry Kubic:Update_and_Reboot.
System Personalization
If (like me on my workstation) have and NVIDIA graphic card and you want the proprietary driver, then yes, the proper repos and packages need to be installed. I did that like this. Don’t bother about that transactional-update
command that may look weird. Just do this, for now… I’ll talk about it a bit later:
$ sudo transactional-update pkg install gnome-remote-desktop $ sudo reboot
I personally want sudo without a password for my user, via the wheel group, so I do this (but it’s of course optional):
# usermod -a -G wheel <myuser> # echo "%wheel ALL = (root) NOPASSWD:ALL" > /etc/sudoers.d/wheel
I have added some packages to the base OS, to make it a little bit friendly to interact with it. But not too many. Basically, these ones:
$ sudo transactional-updaete pkg install bash-completion wget unzip nfs-client autofs gnome-shell-search-provider-nautilus $ sudo reboot
I will pick the Firefox flatpak as a browser, but I also want to use Chrome, from time to time. There’s no flatpak for it (although, something is in the works), so I added it like this:
$ sudo transactional-update shell #> zypper ar http://dl.google.com/linux/chrome/rpm/stable/x86_64 Google-Chrome #> wget https://dl.google.com/linux/linux_signing_key.pub #> rpm --import linux_signing_key.pub #> zypper ref #> zypper in google-chrome-stable #> exit $ sudo reboot
Having a browser installed on the base OS is also useful because then you can use it for installing GNOME Shell extensions. In fact, I tried to install them from within Firefox’s flatpak but I could not make it to work (any ideas if it’s doable, anyone?).
If you want, let’s say, the firewall and some NetworkManager plugins for your VPN, add these, or whatever else you think you’ll need. But only if they are core components or things that are absolutely only available in RPM form. The general rule of thumb is, try as hard as you can not to add too many stuff!
$ sudo transactional-update pkg install firewalld firewall-config NetworkManager-openvpn-gnome $ sudo reboot
As stated earlier, it’s quite likely that some of these may be included within the desktop install pattern in the future. But, for now, just add them manually.
And that is it. As far as installation and post-install configuration, there is nothing more to do. So you’re all set and you can start enjoying your life in an immutable Desktop system!
I will just add a super quick summary on a couple more topics and then we leave all the rest to other blog posts.
transactional-update
zypper
is present on a MicroOS system, but it does not work (feel free to try! :-P). Instead, we use transactional-update
. It’s not correct to call it a wrapper around zypper
because it does a lot more. But, essentially, you use it kind of like that, i.e., for installing/removing packages or for updating the system.
If you want to read more about it, check out these blog/news entries:
This talks / presentations:
And these documentation entries:
And these man entries:
IAC, just very quickly, installing something is done like this:
$ sudo transactional-update pkg install <package> <package> ... $ sudo reboot
Or:
$ sudo transactional-update shell # zypper in <package> <package> ... # exit $ sudo reboot
Removing, as can be easily imagined:
$ sudo transactional-update pkg remove <package> <package> …
Or same as shown already, with transactional-update shell
. Let’s mention 2 things:
- As
transactional-update
warns you about itself, do not use it two or more times, without having rebooted in between. If you do that, you’ll loose all the changes that you did in all the invocations except the latest one. And when you reboot, you’ll only see them being applied. That’s just how immutable OSes works, after all, and there is not really a way around it (and it’s a good thing, IMO! You just need to get used to it) - Try to use it as few as possible, at least for installing and removing packages. That means, basically, try to install or remove packages as few as possible. If at all. See it like this: if you’re about to
transitional-update
install or remove something, think twice about it and consider whether there are alternatives to that. Most likely, they are. Then go for them, and save yourself a reboot.
This may all sound weird and you may think that you’ll end up straight in some kind of “rebooting hell” if ever trying to use a system like this, but do believe me, it’s not necessarily like that. As a sort of proof, I can offer you my current uptime, on this workstation (that runs with MicroOS Desktop, of course!):

See? I’ve not rebooted since 3 days and 16 hours (and counting)! 😛
On the other hand, using transactional-update
for updating the base OS is fine. I won’t say <<don’t do it too frequently>> because you just should do it how frequently you want. 🙂
So, basically, from time to time, or in general whenever you like, do a:
$ sudo transactional-update dup
$ sudo reboot
Or:
$ sudo transactional-update shell # zypper ref # zypper dup # exit $ suro reboot
It’s not that different than being on Tumbleweed, from this point of view. At least not for me. In fact, even when I was using Tumbleweed I was running zypper dup
whenever I found it convenient and when I was sure that I was able to reboot the system, in case some critical package is actually updated and zypper
would recommend to do so.
Here on MicroOS, rebooting or not is less of a choice. Meaning that, after having updated as shown above, you better do reboot. But you can do these updates whenever you want, no problem with that.
Flatpaks
Don’t want to say much here. Just, Flatpak / Flathub is from where we take all the apps. Everything that is not part of the very core of either the OS or the desktop environment (let’s say, anything above GNOME Shell) should come from Flatpak and not from the distribution RPMs.
Exceptions are allowed, of course, if there’s something you really need which is available as RPM but not as Flatpak (e.g., for me, it’s GThumb). But the least exceptions you allow, the more true you are to the “immutable OS philosophy”.
So, you can search for a flatpak like this:
$ flatpak search Steam
Install like this:
$ flatpak install Steam
And update like this:
$ flatpak update
And perhaps from time to time do this:
$ flatpak remove --unused
There’s room for improvement (isn’t there always!), like integrating this better in GNOME Software, etc. We will work on enable that.
Ah… when you install or remove or re-install a flatpak, there’s no need to reboot!! 😀
In the talk I have a list of apps that I am using. So, if you’re curious, check that out there.
Toolbox
Toolbox is just great! It’s basically a script that build and launches for you a privileged podman (or rootless podman) container inside of which you are free again to do zypper in
and zypper rm
to your heart’s content.
For starter, perhaps you can have a look at the toolbox post on Kubic’s blog.
There’s so much to say about it and about how I am using it that I won’t even start, as I currently don’t have the time. For instance, I extensively use it for development. Or, I should say that I spend pretty much my entire working day inside one or more toolbox-es. But yeah, again, there are some examples in the slides and in the talk. Check them if interested, until the next post.
Let’s just say this. If you need to scan the port of an host in your LAN, but nmap
is not installed in your base OS (and it should not be!), toolbox saves you from installing it with transactiona-update
and rebooting before being able to use it. In fact, you do like this:
$ toolbox -r #> zypper ref #> zypper in nmap #> nmap -sS 192.168.0.18
Conclusions
Conclusion is that I want to talk and write more about how great I’m finding to use a system like this, and show more details of how I got here and how I’m doing things.
The talk has some of these details, so you can check that out over there. But I’ll also try to get to write more about this soon!
Come and Try… and Help!
And after all this, what’s probably most important to say than everything, is that if you think you may like the idea, not only you should try using MicroOS as your desktop system for real (as I’m doing!), but you are free and welcome to come and help us working on it.
For me, this is not part of my daily job, but I’m very passionate about it, so I’m happy to try to help anyone, and answer any question. Fire an email to me or to the opensuse-kubic mailing list (opensuse-kubic@opensuse.org).
And I’m sure that Richard and Fabian (who also work on this as a side project, AFAIK) will be equally happy to help and welcome any contribution!