openSUSE MicroOS Desktop

openSUSE MicroOS Desktop is MicroOS where the ”one job” is running as a Desktop.

MicroOS Desktop provides only a minimal base system with a Desktop Environment and Basic Configuration Tools ONLY.

All Applications, Browsers, Codecs, etc are provided by FlatPaks from FlatHub.

Warning!

openSUSE MicroOS for Desktop usage is still in a RC (GNOME) or Alpha (KDE Plasma) stage, please keep that in mind!

Who is the MicroOS Desktop for?

It is NOT for everyone. Your highly customisable Tumbleweed & Leap Desktops are Safe and will remain the best choice for those who want to tinker with their Desktop.

It should be perfect for lazy developers, who no longer want to mess around with their desktop and just ”get stuff done”, especially if they develop around containers.

It should also appeal to the same audience now more used to an iOS, Chromebook or Android-like experience where the OS is static, automated & reliable and the Apps are the main thing the user cares about.

Design Goals

MicroOS Desktop should be reliable, predictable & immutable, just like regular MicroOS.

MicroOS Desktop should be less customisable than regular openSUSE Tumbleweed/Leap.

MicroOS Desktop should be small, but not at the expense of functionality. Printing, Gaming, Media Production and much more should all work.

MicroOS Desktop should just work “out of the box” without the need for additional configuration to get key functionality like software installation and web browsing working. All features offered by default should work - features that don't work shouldn't be offered/visible/available to users.

How to use it

Download the openSUSE Tumbleweed base ISO image from https://en.opensuse.org/Portal:MicroOS/Downloads
Write the ISO on a USB drive and start the installation process.
Select GNOME or KDE Plasma as desktop environment.

Ways to install applications in order of preference

You can install applications in several ways.

flatpaks from flathub -- the preferred solution (has added advantage that codecs are already included and don’t need to be added to the host)
RPM's in a user distrobox distrobox-enter
RPM's in a root distrobox distrobox-enter -r
RPM's via transactional-update -- for drivers, kernel modules, strictly what you need for your host operating system to work, everything else to be installed in a Distrobox if package is not available as a flatpak.

Note: If you want to learn more about how to launch GUI applications via Distrobox, scroll down to [Distrobox section] below.

transactional-update - Introduction

openSUSE MicroOS does not use zypper like openSUSE Tumbleweed or openSUSE Leap to install RPM packages and use them directly. openSUSE MicroOS uses transactional-update with zypper under the hood.

Most of the time, you should not need to use any of these commands interactively, as MicroOS has automatic system updates via a the transactional-update.service systemd service.

transactional-update - Example commands

commands for transactional-update are listed below. NOTE: Remember to reboot after the command is finished to see the changes!

sudo transactional-update pkg install package_name install a rpm package
sudo transactional-update pkg remove package_name remove an rpm package
sudo transactional-update dup perform a system upgrade to the next release
sudo transactional-update shell open a shell of the next snapshot (you can use zypper commands there). This should only be used for debugging purposes. Any bug report that can only be reproduced by using transactional-update shell is almost certain to be closed as WONTFIX.

transactional-update - automatic update

By default transactional-update.timer handles automated system updates. This is set to daily which means that the task will be executed each day at 00:00:00 which in case of a desktop might be at a time when the computer is off, as the timer is set to persistance=true, the update will then take place the first chance it got if it couldn't be executed - for instance if the computer was off, or the internet connection was disturbed - at time it is scheduled to.

To avoid automated reboots you can disable rebootmgr:

 $ sudo systemctl disable --now rebootmgr.service

This should not cause issues due to the way transactional-update works since the new packages are installed on a new snapshot for which to take effect you must reboot.

To track if transactional-update is able to upgrade, and run correctly you can use journalctl:

 $ sudo journalctl -u transactional-update.service

You can also use journalctl with the -f flag to tail the logs in real time.

transactional-update - --continue

By default, each transactional-update command produces a seperate, self-contained, snapshot that includes the changes requested by the transactional-update command.

This snapshot is BASED ON THE LAST KNOWN GOOD/BOOTED SNAPSHOT. The last of the snapshots produced by multiple transactional-update commands then takes effect when rebooting.

In other words sudo transactional-update pkg install $pkg1 followed by sudo transactional-update pkg install $pkg2 and then rebooting results in a system that has $pkg2 installed, but NOT $pkg1.

This is the expected, and sensible default behaviour - MicroOS always wants to move from the last known good/booted snapshot to it's new state in the smallest, least distruptive way possible.

This is especially sensible when you think the default/expected behaviour is that MicroOS updates itself automatically and most users should not be using transactional-update interactively at all. With transactional-update dup happening regularly in the background automatically, MicroOS wants to make sure it's updating only to the latest clean system update state, not some weird hybrid of previous unbooted, unchecked, intermediate transactional-update dup that never got booted.

However, when ignoring this best practice and using transactional-update interactively, there may be times where you wish to run transactional-update against an existing unbooted, unknown-if-good snapshot.

For this use transactional-update --continue

Example:

sudo transactional-update pkg install $pkg1 followed by sudo transactional-update --continue pkg install $pkg2 will install $pkg1, then $pkg2 in the same snapshot that included $pkg1, marking that combined snapshot as the next boot target.

If problems occur however, there is no additional complexity figuring out whether it was $pkg1 or $pkg2 that broke anything, as users will need to rollback to the snapshot before $pkg1 was installed to return to the last known good state.

Installation: GNOME Software

Gnome is currently in a RC stage.

At first boot flatpaks are enabled and some flatpaks are installed by default (Mozilla Firefox, Text Editor, Gnome Calculator and Extension Manager).

After the first boot script finishes you can open Gnome Software to install more software from flathub.

Installation: KDE Discover

KDE is currently in an ALPHA stage.

In Discover, the flathub repository is enabled upon first login, and some flatpaks are installed by default (Mozilla Firefox and kCalc), kate (text-editor) is still provided via RPM in the base image (it is not fully operable via flatpak as of yet).

For theming, normal global theme installations don’t work in KDE Plasma, you can however install components directly via discover.

DistroBox

Distrobox can be used like toolbox (which is included on the server version of MicroOS by default), but has some other advantages for desktop usage. Please refer to https://github.com/89luca89/distrobox for all options.

Create a new Distrobox container with (default in openSUSE is an openSUSE Tumbleweed container):

  $ distrobox-create

Open the container with:

  $ distrobox-enter tumbleweed

With distrobox-export you can create a shortcut in your host system to open an application from a distrobox container.

Troubleshooting

This section describes known issues on openSUSE MicroOS Desktop and their solutions.

Enable network time synchronization after offline install

If you do not connect to the internet during the MicroOS installation process, network time synchronization might be disabled, which among other things can cause certificates to be rejected and authorization processes to fail. To check whether network time synchronization via NTP is enabled, use:

 # timedatectl status

If the resulting output tells you that the NTP service is inactive, you can enable it with:

 # timedatectl set-ntp true

Unexpected reboot

MicroOS comes with an auto update and reboot policy by default. transactional-update will perform this procedure everyday. If you wan't to disable this feature, do this:

 # systemctl disable --now rebootmgr.service

set hostname

Set your hostname with the following command, as currently it doesn't work from Gnome Settings yet:

  # sudo hostnamectl set-hostname <new name>

Place for questions

As openSUSE MicroOS desktop is a seperate part of the openSUSE MicroOS distro it also has seperate places to discuss the desktop.

Telegram: https://t.me/openSUSE_MicroOS_Desktop
Matrix: https://matrix.to/#/#microos-desktop:opensuse.org
Discord: https://discord.gg/opensuse #MicroOS-Desktop channel

All these channels are bridged together via Matrix, so sending your comments in one, will be seen in the other two.

Portal:MicroOS/Desktop

Contents