Portal:Aeon/SoftwareInstall

Installing Software
Order of preference
Software installation is recommended in the following order:
- Flatpak
- User Distrobox
- Root Distrobox
- 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:
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 our 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.
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 packagesudo transactional-update pkg remove package_name
remove an RPM packagesudo transactional-update dup
perform a system update to the next release. In most cases, this is unneeded, as Aeon automatically updates with thetransactional-update.service
systemd service.sudo transactional-update shell
open a shell of the next snapshot (you can usezypper
commands inside the shell). This should only be used for debugging purposes. Bug reports that are only reproducible by usingtransactional-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
:
sudo journalctl -u transactional-update.service
You can use journalctl
command with the -f
flag to tail the logs in real time.
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:
user $ sudo transactional-update pkg install package_1
user $ sudo transactional-update pkg install package_2
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:
sudo transactional-update --continue
Example:
sudo transactional-update pkg install package_1
Followed by:
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.