Quarry scans and status

Registry metadata, Trivy history, experimental foundations, and container-host QA notes. None of this is a reason to install; the hub is.

Source-copy hash and release count for desktop-quarry live here rather than on the Quarry hub.

Quarry lets you choose a maintained OS foundation while keeping familiar tools and an image-based upgrade and rollback workflow. Current public candidates include:

• Desktop (desktop/quarry) — KDE Plasma, Discover and Flatpak.
• Gaming (desktop/quarry-gaming) — built on the Quarry desktop, adding Steam, Gamescope, GameMode and gaming drivers. Handheld and NVIDIA profiles remain planned.
• Server (desktop/quarry-server-fedora, desktop/quarry-server-opensuse) — headless administration with optional rootless container hosting.
• Core (desktop/quarry-core-fedora, desktop/quarry-core-opensuse) — the shared bootable foundation for each core's Quarry OS editions. Application container bases remain outside this product.

The published-images table above comes from the public registry. It shows the newest image in each repository, including candidates; publishing a candidate does not advance the gaming stable channel or create a tagged release. Digest pins identify exact content; git tags are not protected against replacement by the current publisher.

Features

• KDE desktop — Plasma, Discover for Flatpak, Konsole as the default terminal and Ghostty as an optional secondary terminal.
• Desktop software — Flatpak first, then AppImage and Distrobox. Other desktop environments may be added where a core has trustworthy packages and tested integration.
• CLI tools — Mise, with no Homebrew on the OS image.
• Containers — Podman, with no Docker Engine installed. Server container hosting is explicitly enabled for an exclusive non-root account.
• Image lifecycle — compose OS packages into an image; deployed hosts use bootc upgrades and rollback. Persistent application data needs its own backup and recovery plan.
• Core choice — Fedora and openSUSE desktop/server candidates are published. Debian remains blocked by upstream package inventory. openSUSE desktop passed native KDE login, matching-core transition and rollback checks.

The gaming stack is inspired by Bazzite's features. Gaming inherits Quarry's Fedora desktop; it has no ublue or Bazzite OCI base.

Install and verify

Use a dedicated QA disk or VM for candidate qualification. Never switch a builder or live desktop for these tests.

Public images are on oci.thepeoples.io. Verify with the OCI signing key. Choose a concrete tag or digest from the image table; this example selects the qualified Fedora server candidate:

IMAGE=oci.thepeoples.io/desktop/quarry-server-fedora:git-6637b7f
cosign verify --key https://thepeoples.io/keys/oci.thepeoples.io.pub \
  --insecure-ignore-tlog "$IMAGE"

sudo ./scripts/iso/install-quarry.sh --mode switch --yes --image "$IMAGE"

The current installer verifies the signature again and compares the downloaded image with the signed digest before queuing it for reboot. It preserves the selected update channel. Reboot the QA guest after the installer succeeds, then inspect quarry status.

The five-edition installer ISO is published. It covers Fedora desktop, gaming and server, plus openSUSE desktop and server. Use the download listing and each ISO's test results for its exact edition set. Physical hardware, cross-core switching and version-changing upgrades remain separate gates. Candidate publication and the tested server workload do not establish full Docker API compatibility or ARM64 qualification.

Server container hosting

Create an exclusive non-root account with an owned home and non-overlapping subordinate UID/GID ranges, then use:

quarry feature check container-host --user quarry-containers
quarry feature enable container-host --user quarry-containers
quarry feature status container-host --user quarry-containers --json
quarry feature disable container-host --user quarry-containers

Enablement supplies a rootless Podman socket and boot restart policy. Disablement stops its containers and API, preserves their data, and restores prior lingering policy. Compose uses the socket endpoint returned by status. Restart policy and application dependency recovery still need workload-specific tests.

The Fedora server candidate passed boot and feature lifecycle tests on an isolated QA VM with a rootless Git service and PostgreSQL, including container recreation, database process crash recovery, cold boot, disable/re-enable and wrong-signing-key rejection. Its data survived; container hosting was left disabled after QA. The installer-pinned desktop and gaming candidates passed fresh graphical VM login and signed same-core profile transitions with rollback. Physical GPU, Steam/Proton and controller qualification remains open.

The openSUSE server candidate passed native OSTree installation, unattended OVMF boot, managed EFI adapter update and OS update/rollback on a separate QA VM. Its rootless Git service/PostgreSQL stack passed recreation, crash recovery, disabled reboot and re-enablement, preserving data and account mappings. Native host AppArmor profiles stayed enforcing; rootless Podman reports named AppArmor container profiles unavailable, and a curl-based Unix-socket consumer needs separate policy qualification. The tested socket consumer uses Python's HTTP client.

For the older git-02bda17 openSUSE candidate, use the source installer and reboot manually; its automatic CLI reboot path has a known issue. The corrected path has passed VM qualification.

Experimental foundations and planned editions

Security and releases

Signed registry candidates are separate from tagged releases. The historical release scan below applies to its recorded release, not these new candidate digests. Its zero-package inventory does not establish vulnerability coverage for the current images. Complete per-digest package inventories, vulnerability triage and promotion of the exact tested artifacts remain release gates.

OS rollback does not undo database schema migrations or other persistent /var changes. Back up and qualify application data independently of the OS image.

Links

• Published image metadata (JSON)
• Tagged releases
• Source
• OCI cosign public key
• Consume docs
• Installer strategy

Release scan 2026-09-11 · none