Skip to content

Home

Jump to bottom
butre edited this page Jul 15, 2026 · 3 revisions

Differences from Upstream Bluefin LTS

butrelinux is a KDE Plasma variant of Bluefin LTS, and thus inherits many things from it. It also divulges in many ways. The primary purpose of this doc is to explain differences from upstream docs.

Quick orientation

  Upstream Bluefin LTS butrelinux
Base OS CentOS Stream 10 + EPEL Same - CentOS Stream 10 + EPEL
Desktop GNOME KDE Plasma
Registry ghcr.io/projectbluefin/* ghcr.io/butrejp/*
Signing Moving to keyless OIDC (Fulcio/Rekor) Static cosign key (cosign.pub in repo)
Support Community-supported Self-supported

Choosing a variant

butrelinux ships more images than you probably expect. Pick carefully - rebasing between the wrong ones can break your system.

  • butrelinux-hwe - Intel/AMD, current recommended default (tracks ghcr.io/projectbluefin/bluefin-lts-hwe:stable)
  • butrelinux-nvidia - Nvidia hardware (tracks ghcr.io/projectbluefin/bluefin-lts-hwe-nvidia:stable)
  • butrelinux-lts - non-HWE kernel, plain ghcr.io/projectbluefin/bluefin-lts:stable base
  • butrelinux (no suffix) - deprecated. Based on ghcr.io/ublue-os/bluefin-gdx:lts - the old GNOME "AI Workstation" image, not the hwe/nvidia/lts split. Kept alive for security updates only. New installs should not use this one.

⚠️ Only rebase from bluefin-gdx or bluefin-lts. This image is CentOS Stream-based, not Fedora. Cross-rebasing from any Fedora-based (or Aurora, Bazzite) system is untested/unsupported upstream and can lead to data loss - same warning upstream Bluefin LTS gives for its own base.

Why is the no-suffix image deprecated? Its upstream base (ublue-os/bluefin-gdx:lts) is itself being phased out - as of a July 2026 upstream announcement it's being auto-migrated to projectbluefin/bluefin-lts-nvidia:stable as part of a broader reorg (see Upstream reorganization below). The hwe/nvidia/lts split already tracks the newer projectbluefin org and is the intended long-term path.

(TODO: decision tree / flowchart for "which one do I want")

Installation

  • ISO downloads: GitHub Releases (from the unified ISO build) and SourceForge
  • Rebase path: rpm-ostree rebase --reboot ostree-image-signed:docker://ghcr.io/butrejp/butrelinux-<variant>:latest - not the ublue-os registry path from upstream docs
  • Signature verification uses this project's own cosign key, not the ublue-os org key - download cosign.pub from this repo, not upstream's

(TODO: full step-by-step per variant, screenshots of installer boot menu)

Desktop environment - this is KDE, not GNOME

Nearly every "here's your desktop" doc from upstream needs rewriting, not editing.

  • App launcher / activities: Kickoff (bottom-left of panel), not GNOME Activities
  • File manager: Dolphin, not Nautilus/Files
  • Terminal: Konsole - ptyxis is removed from this image entirely
  • App store: Discover, not GNOME Software or bazaar - see Flatpaks below)
  • Settings: System Settings, not GNOME Settings
  • Tweaks / Extensions: no direct KDE equivalent as shipped; GNOME Tweaks/Extensions docs should be dropped, not translated. Point users to Plasma's Global Themes / widget store if similar customization is needed.

Package management & layering

  • Upstream Bluefin LTS does not support local rpm-ostree layering at all - it's listed as a known difference from regular Bluefin, not just a default setting. This is stronger than a typical "disabled by default, but you can re-enable it" posture.
  • butrelinux disables layering by default too, but bridges the gap by shipping its own tool, givemethekeys, to toggle the lock:
    • givemethekeys status - check current state
    • givemethekeys unlock - enable layering (confirmation prompt unless -y)
    • givemethekeys lock - restore the default locked state
  • This is a butrelinux-specific escape hatch, not an officially-supported upstream Bluefin LTS feature - if something breaks after unlocking, that's on the layered packages, not something upstream will help debug.
  • brew (Homebrew) is the suggested path for CLI package management outside of layering, same as upstream. The intended workflow otherwise is Distrobox + Flatpak, matching upstream's own recommendation.

CentOS Stream / EPEL specifics - mostly shared with upstream, KDE has its own wrinkles

  • KDE-specific EPEL packaging gaps. Upstream's own CentOS/EPEL experience is tuned around GNOME; the README's mention of "a handful of oddities that are mostly upstream issues on EPEL" is almost certainly about KDE packages specifically, which get less EPEL packaging attention than GNOME's. This is the one part of the CentOS/EPEL story that's genuinely butrelinux's own territory and deserves its own living "known quirks" list.
  • AppImage support: attempted, then reverted. Upstream Bluefin LTS lists AppImages as unsupported. butrelinux actually added support for a while, but reverted it post-reorg because fuse2 conflicts with bootc - this isn't a packaging-availability problem (the FUSE packages are in CentOS repos now), it's a bootc compatibility issue. Worth documenting the history so people don't assume "FUSE is packaged" means AppImages are safe to expect back soon.

(TODO: concrete list of specific KDE/EPEL quirks as they're found - link issues here as they're filed)

Flatpaks

  • Uses a Flathub Beta repo (flathub-beta), not stock Flathub
  • Default install differs by variant:
    • hwe/nvidia/lts: org.kde.discover (stable channel)
    • deprecated butrelinux image: org.kde.discover beta
  • Worth explaining why Beta is used here (if there's a reason tied to the KDE packaging situation on EL10) so users aren't surprised by beta-channel Discover

Upstream reorganization (mid-2026)

Upstream Bluefin LTS/GDX is in the middle of a significant reorg as of a July 2, 2026 announcement - worth tracking closely since it directly affects the images this project bases on.

  • Kernel consolidation: upstream says "no one was using vanilla Bluefin LTS" 6.12 kernel, so everything is consolidating onto Fedora's kernels. That potentially collapses the current hwe/non-hwe split upstream - if it does, butrelinux's own hwe.yml/lts.yml distinction may need re-evaluating down the line, since it currently mirrors that same split.
  • Signing is moving from static keys to keyless OIDC (Fulcio/Rekor) upstream. butrelinux still uses a static cosign keypair (cosign.pub in the repo) baked into kickstarts and containers - this is a real, if not urgent, divergence to keep an eye on, since it's the opposite direction of where upstream is headed.

ISO builds

butrelinux uses its own kickstart/ISO tooling - this doesn't map to any upstream Bluefin installer doc.

  • Per-variant ISOs (hwe, nvidia currently) built via lorax/mkksiso, manually triggered
  • A separate unified ISO bakes all four kickstarts (hwe, nvidia, lts, legacy) into one disc with a custom GRUB boot menu (labeled BUTRELINUX), published monthly as a GitHub Release - this is likely the easiest path for most users and should be documented as the primary recommendation
  • Both paths embed this project's own cosign key and sigstore policy directly into the kickstart for post-install signature verification

Support

Upstream Bluefin has structured community support channels. This project does not - the README states plainly that there's no support from the maintainer, and that the Bluefin or BlueBuild communities might help but shouldn't be relied on. This is different enough from the upstream posture that it deserves calling out explicitly rather than assuming Bluefin's support docs transfer over.

There is a small community chat (linked via the MOTD tips) for informal discussion, separate from GitHub Issues.

Open TODOs for this page

  • Screenshots of default desktop layout
  • Variant decision-tree graphic
  • Running list of EPEL/CentOS-specific quirks as they surface
  • Watch the upstream ublue-os → projectbluefin migration and update base-image references here (and in the recipes) as it lands
  • Revisit hwe/non-hwe split if upstream's kernel consolidation collapses it

Clone this wiki locally