This guide helps you migrate to tunaOS from Windows or other Linux distributions.
Images with RFC 012 enable one anonymous report per UTC week by default. The payload contains the image variant, flavor, architecture and age bucket. It has no device identifier. See the public notice for privacy limits and counts.
To opt out before the first boot of an updated image, set this persistent file on your installed system:
sudo install -d -m 0755 /etc/tunaos/countme
sudo touch /etc/tunaos/countme/disabledAfter the update, sudo tunaos-countme disable also masks the timer and service. Use sudo tunaos-countme status to check the choice. Image updates and switches preserve the file, masks and weekly state. These controls affect reports from TunaOS. Metrics for upstream distributions have separate controls.
tunaOS is a collection of bootc-based Atomic desktop operating system images. It uses bootc for image-based updates and rpm-ostree for package layering (Yellowfin/Albacore variants) or native bootc tooling (Bonito/Skipjack).
Fedora Atomic desktops use rpm-ostree natively. Migration to a tunaOS variant is a rebase operation. Yellowfin and Albacore are AlmaLinux-based; Skipjack is CentOS Stream 10; Bonito is Fedora 44 (see ROADMAP.md for variant details).
| Current | Target tunaOS Variant | Base |
|---|---|---|
| Fedora Silverblue (GNOME) | Yellowfin GNOME | AlmaLinux Kitten 10 |
| Fedora Kinoite (KDE) | Yellowfin KDE | AlmaLinux Kitten 10 |
| Fedora Sericea (Sway) | Albacore COSMIC or Niri | AlmaLinux 10 |
# Check current deployment
rpm-ostree status
# Rebase to tunaOS (example: Yellowfin GNOME)
sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/tuna-os/yellowfin:gnome
# Reboot into tunaOS
sudo systemctl reboot# Confirm the new deployment
rpm-ostree status
# Check bootc status (if bootc-enabled variant)
bootc statusIf something goes wrong:
# Rollback to previous deployment
sudo rpm-ostree rollback
sudo systemctl rebootUniversal Blue images are Fedora-based. Migration to an EL-based tunaOS variant (Yellowfin/Albacore/Skipjack) is a rebase, but note:
- Package layering differences: Some layered packages may not be available in AlmaLinux repositories or may have different names.
- Container tooling: tunaOS uses
podmananddockervia the same container tools.distroboxis compatible.
# 1. List layered packages (save for reference)
rpm-ostree status | grep LayeredPackages
# 2. Rebase to tunaOS
sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/tuna-os/yellowfin:gnome
# 3. Reboot
sudo systemctl reboot
# 4. Re-apply layered packages as needed
# Note: package names may differ between Fedora and AlmaLinux
sudo rpm-ostree install <pkg1> <pkg2> ...Bluefin users should target Yellowfin GNOME — the closest equivalent.
sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/tuna-os/yellowfin:gnomeAurora users should target Yellowfin KDE.
sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/tuna-os/yellowfin:kdeBazzite users: note that tunaOS does not ship gaming-specific kernel tweaks or Steam pre-installed. You can layer these post-migration:
sudo rpm-ostree install steam-devices mangohud gamemodeFedora Workstation is a traditional (non-Atomic) distribution. Direct migration is not supported. Options:
- Fresh install: Use a tunaOS ISO to install directly
- Container-based transition: Export data, install tunaOS, restore from backup
Direct rebase from traditional Fedora to an Atomic image is not supported by rpm-ostree.
Traditional Enterprise Linux installations cannot be directly rebased to an Atomic image.
Use a tunaOS ISO to perform a fresh installation.
If your system supports it, you can convert a traditional EL system to bootc. This is advanced and not recommended for production without testing.
# This is theoretical — verify with tunaOS documentation for current procedure
bootc switch ghcr.io/tuna-os/yellowfin:gnomeMicroOS uses transactional-update, not rpm-ostree. Direct migration is not supported. Use a fresh install.
Vanilla OS 2 (Orchid) uses ABRoot, not rpm-ostree. Direct migration is not supported.
Endless OS uses OSTree but with a different deployment model. Migration is not tested or supported.
If you are now running Windows (Windows 10 or 11), you can migrate to TunaOS directly using wootc without needing to burn a USB flash drive or repartition your drive in advance.
wootc is a Windows installer application for TunaOS:
- No USB stick required: Runs directly within Windows and prepares a bootable environment.
- Safe alongside Windows: Installs to a loop root disk (
root.disk) on your existing drive while keeping Windows intact in the UEFI boot menu. A BitLocker-encrypted disk is not yet a supported path — that work is tracked as wootc#223 and is Q4 scope in ROADMAP.md — so suspend BitLocker or back up your recovery key before you start. - Migration assistance: Can import Wi-Fi networks, wallpaper, browser profiles, keyboard layouts, WSL configurations, and user documents.
- Full TunaOS catalog: Choose from GNOME, KDE Plasma, COSMIC, Niri, or XFCE editions across supported TunaOS bases.
- Honest rollback / uninstall: Uninstall cleanly from Windows Settings / Add or Remove Programs, leaving no residual partition state.
- Download the latest installer from the wootc releases page (e.g.
tunaos-installer.exe). - Run the installer in Windows with administrator privileges.
- Select your desired TunaOS desktop environment and variant, configure username and password, and allocate disk space.
- Reboot your system and select TunaOS from the boot menu to complete setup.
For detailed instructions, refer to the wootc Getting Started Guide.
After migrating to tunaOS, verify:
- Desktop environment starts correctly
- Network connectivity works
- Display / GPU drivers functional
- Audio working
- Flatpak applications run (Flathub is pre-configured)
-
bootc statusshows correct image - Container workloads work (
podman run hello-world)
tunaOS ships with Flathub pre-configured. If you need to re-add it:
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepoThe GNOME images used to carry these extensions in /usr/share: AppIndicator,
Blur my Shell, Caffeine, Dash to Dock, Gradia, GSConnect, Logo Menu and Search
Light. They also carried the GNOME Classic session. None of these are in the
image now.
After bootc upgrade:
- The extensions you had turned on go away, and GNOME stops loading them. Your settings for them stay in dconf.
- You cannot log in to GNOME Classic. Log in to the standard GNOME session.
- To get an extension back, install it from Extension Manager
(
com.mattjakeman.ExtensionManager). New installs get it as a Flatpak. On an existing install, runflatpak install flathub com.mattjakeman.ExtensionManager.
The stock rootfs of Arch Linux ARM ships an alarm account at UID 1000, and
marlin's arm64 images carried it. These images no longer hold that account, so
a live ISO can place its own user at UID 1000.
After bootc upgrade:
- If you never edited
/etc/passwd, the account goes away with the upgrade. Nothing else changes. - If you added or edited a user, your
/etc/passwdcounts as local configuration andalarmstays. Runuserdel alarmby hand to free the UID. - Files under
/var/home/alarmsurvive either way. Once the account goes, they show a bare UID and no name.
Nobody should log in as alarm on a tunaOS system. It is an artifact of the
base image, and build-archlinuxarm-base.yml keeps it for the base alone.
Every marlin linux-arm64 image published before this change holds no kernel.
Arch Linux ARM ships the kernel as /boot/Image alone, and the bootc layout
step cleared /boot without a copy in /usr/lib/modules/<kver>/vmlinuz, which
is where bootc reads it.
A bootc upgrade onto one of those images stages a deployment that cannot
boot. Only arm64 marlin is affected; x86_64 marlin and every other variant
always carried the kernel.
- On a system that still boots: upgrade to an image built after this change. No other action is needed.
- On a system that stopped booting after an upgrade: pick the previous
entry in the boot menu, then run
sudo bootc rollbackto make it the default. Upgrade again once a newer image is available.
To confirm an image before you deploy it, check that the path exists:
sudo bootc image copy-to-storage
podman run --rm ghcr.io/tuna-os/marlin:gnome ls /usr/lib/modules/*/vmlinuz- NVIDIA drivers: nvidia variant recommended for NVIDIA hardware. See ROADMAP.md for available variants and flavors.
- Secure Boot: NVIDIA flavors need manual enrollment of the MOK key on first boot after migration; community bases don't support Secure Boot at all — see docs/SECURE-BOOT.md.
- Dual boot: Not recommended or tested with tunaOS Atomic images.
- Fingerprint readers: May need additional driver configuration.
- Issues: github.com/tuna-os/tunaOS/issues
- Discussions: github.com/tuna-os/tunaOS/discussions
- See CONTRIBUTING.md for development contributions.
For variant-specific details, see ROADMAP.md and the build/installation guides at tunaos.org.