Software Installation

Order of preference

Software installation is recommended in the following order:

• Flatpak
• User Distrobox
• Root Distrobox
• Local Binaries
• Transactional Update

---

Flatpak & Flathub

Flatpaks are the preferred app installation method on Aeon. Flatpak and the Flathub store are enabled by default and can be installed from GNOME Software or the command line.

---

Distrobox

Aeon uses Distrobox, with Podman as the container engine, this allows users to run containerized runtimes of different Linux distributions.

User Distrobox

You can enter a Tumbleweed Distrobox by running:

Aeon@localhost:~> distrobox enter

For those who want GUI apps from Distrobox containers to integrate with the desktop, you can use the distrobox-export command.

Learn more about Distrobox from their website and openSUSE's Distrobox documentation.

Root Distrobox

In most situations, user Distrobox is recommended, but if needed, Distrobox features a "real root" mode for specialized use cases. Learn more about the "real root" Distrobox feature in the its documentation.

---

Local Binaries

If you want to use a binary that you've downloaded or compiled, you may move it to one of two places, then you can execute it from the terminal.

Prior to moving the binary make sure that it's permissions are set to executable.

Aeon@localhost:~> chmod +x /path/to/binary

Or you can right click the binary file inside the file manager and enable "Executable as Program" inside "Properties".

Your options on where to place the binary are as follows.

/home/$USER/.local/bin

This will allow the binary to be executed but only in that specific user account.

If you want the ability to execute the binary system wide outside of the user account.

/usr/local/bin

Unless you know exactly what you are doing installing system wide is not recommended especially if you only use one user account.

---

Transactional Update

NOTE: Aeon's underlying OS is deliberately minimal and not intended to be modified. Modifying it is unsupported, and if you choose to do so, you will not receive any support.

If necessary, you can modify the underlying OS to install drivers, kernel modules, or certain VPN services.

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

Example Commands:

NOTE: Remember to reboot after the command is finished to see the changes!

Most of the time, you should not use these commands interactively.

Commands for transactional-update are listed below.

• sudo transactional-update pkg install package_name install an RPM package
• sudo transactional-update pkg remove package_name remove an RPM package
• sudo transactional-update dup perform a system update to the next release. In most cases, this is unneeded, as Aeon automatically updates with the transactional-update.service systemd service.
• sudo transactional-update shell open a shell of the next snapshot (you can use zypper commands inside the shell). This should only be used for debugging purposes. Bug reports that are only reproducible by using transactional-update shell are likely to be closed as WONTFIX.

Automatic Updates

Aeon will attempt to automatically update using the transactional-update.service. This service is triggered by the transactional-update.timer, which is set to run daily between 12:00 AM and 2:00 AM.

Updates are installed into a new snapshot and take effect when the device is rebooted.

Some of the reasons why an update may be missed include:

• the device was powered off
• the internet connection was unavailable
• the laptop was disconnected from AC
• the new snapshot was automatically deleted by the inbuilt health checker

You can track the service using journalctl:

Aeon@localhost:~> sudo journalctl -u transactional-update.service

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

Aeon@localhost:~> sudo journalctl -u transactional-update.service -f

About Snapshots and Boot Behavior

Each transactional-update command creates a separate, self-contained snapshot that includes the changes requested from the previously ran transactional-update command.

New snapshots are based on last known good/booted snapshot.

If you run multiple commands before rebooting, only the snapshot from the final command will take effect.

Example:

Aeon@localhost:~> sudo transactional-update pkg install package_1
transactional-update x.x.x started
...
Aeon@localhost:~> sudo transactional-update pkg install package_2
transactional-update x.x.x started
...

Once you reboot your device, only package_2 will be installed. The changes from the first command (package_1) won't take effect.

This is the expected behavior. Aeon always wants to move from the last known good/booted snapshot to its new state in the smallest, least disruptive way possible.

The reasoning behind this is that, with transactional-update dup running automatically in the background, and most users not using transactional-update interactively, Aeon ensures it updates to the latest clean state, rather than to a hybrid, unbooted, unchecked, or intermediate snapshot.

You may wish to ignore this while using transactional-update interactively, and run transactional-update against an existing unbooted, unknown-if-good snapshot.

For this, use:

Aeon@localhost:~> sudo transactional-update --continue

Example:

Aeon@localhost:~> sudo transactional-update pkg install package_1

Followed by:

Aeon@localhost:~> sudo transactional-update --continue pkg install package_2

However if problems occur, there is no additional complexity for figuring out whether it was package_1 or package_2 that broke anything, as users will need to rollback to the snapshot before package_1 was installed to return to the last known good state.