openSUSE MicroOS as your Desktop. Take 2.

WARNING!

This post is outdated. The information it contains are not valid any longer, if you try MicroOS Desktop as of today (i.e., 14 Feb 2023). The post is left up for reference/historic reasons, but don’t rely and don’t try anything you read without double checking whether or not it is still valid and whether or not it still applies to the latest version of MicroSO Desktop (which improved a lot, BTW! ;-P)

I hope to be able to release a new piece about MicroOS Desktop soon.

Foreword

Wow, it’s openSUSE Conference time again already! Well, let’s do as last year, let’s use the fact that I have a talk there to create another blog entry about the progress we are making toward the goal of making openSUSE MicroOS the fanciest desktop platform ever, more or less like my previous one.

To be honest, I wanted to write again about the development of MicroOS Desktop much earlier than today. A few people even wrote me, asking right for that, as some of the things that that post says are not valid any longer. Well, I am truly sorry, but I never got the time to do that… Not until now! 😦

About the Talk

Note that this year’s talk was actually a workshop. Therefore, after I went through what new development has happened in MicroOS Desktop during this year, quite a few people asked a lot of interesting questions, and we ended up talking about a bunch of topics that are not going to be part of this post.

I will put here the link to the video, once available, and what was discussed during the “workshop part” will be the subject of future posts (if I find the time, this time! :-O).

Slides

osc-2021-microos-darioDownload

Video

As soon as I’ll have a link. 🙂

MicroOS What / When / Who / Why ?

These days, there is a lot of material on what MicroOS is and on the reasons why we think it is relevant also as a (potential… but we’re getting there!) desktop platform. So bear with me if I cut this section short and add links to a selection of such material.

“Official” Links

• Our new “get” page: get.opensuse.org/microos/
• The MicoOS Portal, in openSUSE Wiki: Portal:MicroOS
• More Wiki links: Features , Design
• MicroOS discussion channel on Matrix: #microos-desktop:opensuse.org
• Twitter

More on MicroOS

More on MicroOS as a Desktop

Installing

So, the GNOME flavor of MicroOS Desktop is now in “beta”. Installing it is still just as simple as selecting “MicroOS Dekstop (GNOME)[BETA]” and clicking ‘Next’ a few times.

SELinux

Note that we are using SELinux now, which is great in my opinion. However, I have to admit that I have recently run into a couple of issues with it.

One is that the boot is a tad slower when SELinux is enabled. The other, which only showed up a couple of times, caused the snapshot that was being created when trying to update the system to always be reverted during next boot (so, yeah, this one is indeed quite annoying!).

There are bugs open for these issues already, and I am sure they will be solved soon:

• boo#1186563
• boo#1187462

If you want, however, you can install with SELinux disabled for now as it should be possible to enable it at a later point, without re-installing.

First Login

As we know, in MicroOS RPMs should not be used for apps. Flatpaks should. Well, quite conveniently, as soon as you log in to the system for the first time you will see this dialog box, informing you that some initial configuration is happening.

And as soon as that is done, the Flathub repository for Flatpaks will have been configured and enabled automatically, so you can already start installing apps, either from the CLI or from GNOME Software.

Basically, this means that all the post installation fixup that we had to do and that I described in my previous post is gone. Disappeared. Not necessary anymore! 🙂

Actually, not only that! In fact, you will notice that some commonly used applications and utilities, such as Firefox, but also others, have been installed as Flatpaks already, during that first login configuration phase.

Transactional Updates without
`transactional-update`

In previous talks and readings on MicroOS (desktop or not), you may have heard about transactional-update.

In fact, transactional-update was the tool used for both installing/updating/removing RPM packages and for modifying the parts of the filesystem that are read-only (and of course the effect would be visible only after reboot).

Well, we have moved away from that. In fact, transactional-update is not even installed by default any longer.

Instead:

• For dealing with anything related to packages, we use PackageKit, namely via pkcon (and hopefully in future via GNOME Software)
• For modifying the read-only part of the system (in the next snapshot, of course), we use tukit

(Just note that transactional-update is still in use in non-Desktop variants of MicroOS and in SUSE SLE-Micro.)

`tukit`

This is how you do with tukit the things that were typically done with transactional-update.

• transactional-update pkg install <foo>
tukit execute zypper in <foo>
• transactional-update --continue pkg remove <bar>
tukit --continue execute zypper rm <bar>
• transactional-update --continue shell
tukit --continue execute /bin/sh

However, what I would recommend (well… sort of!) is:

• If possible, try not to use tukit at all.
  Like never!
• If you really need it, just use:
  tukit --continue execute /bin/sh
  Which gives you a shell inside which you can change whatever you need to change, and then exit and reboot sooner rather than later.

PackageKit

How many times did we say that fiddling with RPMs is discouraged? Well, whatever, I know that it can happen that you will need to do that. Not to mention that we definitely want to be able to update the RPMs that we have installed in the system. At least that!

The big idea, would be that you will do that using PackageKit. And this is fantastic as it allows one to interact with the system packages both from a terminal, with pkcon, and from graphical front-ends, like GNOME Software and KDE Discover.

If you are curious about the internals, know that we use PackageKit’s DNF backend, thanks to the transactional update libdnf plugin provided (in openSUSE) by the libdnf-plugin-txnupd package.

`pkcon`

Managing RPMs with pkcon has been made a lot simpler than how it is to have to deal with transactional-update or tukit. For instance, let’s say that you want to add the gvfs-backend-samba package to your freshly installed MicroOS Desktop system. Well, what you do is typing:

pkcon install gvfs-backend-samba.

Then, after a while but before rebooting, you realize that you also want the command-not-found package. At which point you just:

pkcon install scout-command-not-found.

Of course, if you check right away, like with rpm -qa, whether these two packages are now available, you will get a <<No, neither of them>> as an answer:

Ok, go on using your system as much as you want and/or can and then reboot it. And after reboot, if you check again:

😀

Of course, it was possible to achieve this behavior with transactional-update and it is indeed possible to do the same with tukit. But, for instance, with those twos you always needed to remember whether you need to use the --continue option, and so on and so forth…

Similarly, updating with pkcon is as easy as running:

pkcon update

And again, if you do multiple pkcon operations before a reboot, like an update and a few package installs and removals, they will just stack nicely one on top of the others, in the way you would expect them to. And at the next reboot you will see the combined effect of all of them.

Even better, since MicroOS is rolling, just like Tumbleweed, and on Tumbleweed you always “upgrade” (i.e., with zypper dup) rather than just “update”, run:

pkcon upgrade-system

So, I would very much like to say that I recommend forgetting zypper and using only pkcon for dealing with packages. In reality, this is not yet 100% possible… But we’re working to get there!

What’s Missing Then ?!?!

(The?) One thing that is not yet easily doable if using only pkcon –i.e., something that still needs zypper wrapped in tukit— is handling additional repositories.

Which is not a huge issue after all, as you shouldn’t really need any additional or external repository on MicroOS Desktop. For instance, you do not need to add Packman, considering that the flatpaks from flathub come with codecs already.

However, what if you are among the unlucky ones that need the NVIDIA proprietary drivers? Well, adding the Tumbleweed repo for those is something that, at least for now, I have only been able to do with tukit and zypper. 😦

sudo tukit --continue execute bash
zypper addrepo --refresh https://download.nvidia.com/opensuse/tumbleweed NVIDIA
zypper ref && \
localhost:/ # zypper in nvidia-gfxG05-kmp-default nvidia-glG05 x11-video-nvidiaG05 nvidia-computeG05

GNOME Software

Anyway, we were saying that another great benefit of using PackageKit, is that we can now see the updates in GNOME Software as well.

Can we also update the system just by clicking on that fancy ‘Update All’ (and then reboot, of course) then?

Well, not yet. And that is because, due to how GNOME Software PackageKit plugin is implemented, this cannot work on MicroOS (if you are curious, it has to do with offline OS updates).

But fear not: we are looking into this!

In fact, I have been working on a prototype patch to GNOME Software that would make updating MicroOS desktop from there just work. It’s early stage and hackish, but it shows that it is possible, and we are in touch with the upstream GNOME Software community about how to proceed with it:

• GNOME Software, Discourse: disable offline updates for immutable OSes
• gitlab.gnome.org, dfaggioli/gnome-software/DRAFT: “fake-online updates” for openSUSE MicroOS
• gitlab.gnome.org, gnome-sofware/issues/1275

PipeWire

Another thing that I think we should do ASAP in MicroOS Desktop (and probably in Tumbleweed, but that is another story) is switch to PipeWire by default.

Well it is already easy enough to switch to it manually, by just doing:

pkcon install pipewire pipewire-pulseaudio

But there currently are conflicts with the MicroOS desktop patterns, and they would need to be removed, which is not ideal.

Of course, we are at work on this as well (and here’s the OBS Request 899544).

Toolbox

In conclusion, a few words about Toolbox.

Of course, toolbox is still there and is still super-useful, both as a mechanism for debugging/troubleshooting the host and as the place where to put your development environment together, or where to install apps (for whatever reasons).

More info on toolbox can be found at:

• By The Power of toolbox! (FOSDEM’21)
• GUI inside a toolbox: Lutris edition
• Debugging on MicroOS made easier with toolbox
• toolbox – bring your own (debugging) utilities with you

Anything New?

Improvements and bugfixes, of course! 🙂

Well, it is still necessary to manually tweak the subids of your user, but now toolbox itself can tell you how exactly you have to do that.

And there is also a little but nice thing I would like to mention, which is that that thanks to the fact that we now have a package called flatpak-spawn in Tumbleweed, it is possible to run commands on the host while you are inside a toolbox.

And this is true for random and simple shell commands, like just checking the content of /etc/os-release of both the toolbox container and the host (without leaving the toolbox, of course):

But it also works fine for more complex things, like listing the flatpaks that you have installed on the host. Or even starting a flatpak application from the host!

This means that you can now really “live” inside a toolbox and never have to exit to the host, and then enter the toolbox again, which used to happen from time to time (at least to me) before.

Final Verdict

So, all things considered, what is the conclusion? I mean, is MicroOS Desktop ready for prime time?

Well, here’s my answer: if you come and help us, it will be soon enough! 😀