All bare-metal `bootc` installation methods (Kickstart, `bootc install`, `bootc-image-builder`) fail to produce a usable Bazzite system

[aenertia]

Describe the bug

Bug Report: All bare-metal bootc installation methods (Kickstart, bootc install, bootc-image-builder) fail to produce a usable Bazzite system

Hi team,

First off, huge thanks for the work on Bazzite! I've been attempting a bare-metal install using custom partitions (16G EFI / 8G Boot / Btrfs Root) and ran into consistent, fundamental installation failures across four different methods. The system appears functional after install, but a check of the logs reveals silent systemd failures that break core functionality (Flatpaks/Bazzite Portal).

Apologies if this is a duplicate issue! I couldn't find a similar report specific to the incompatibility between Anaconda/BIB and the current images.

Date of Report: November 3, 2025

Affected Images:

• ghcr.io/ublue-os/bazzite-dx:latest
• ghcr.io/ublue-os/bazzite:stable
• ghcr.io/ublue-os/bazzite-deck:latest
  (All images pulled on or around November 3, 2025)

Installation Environment:

• Installer: Fedora 43 Live USB (Workstation/Minimal)
• Builder: quay.io/centos-bootc/bootc-image-builder:latest (pulled Nov 3, 2025)
• Target Machine: Bare-metal (NVMe drive)
• Kernel: 6.17.5-ba07.fc43.x86_64

Summary of Core Failure

In all successful installation attempts (Methods 1 & 3), the installed system fails during boot to initialize core components due to missing system groups (kvm, disk, audio, etc.) and a failure to remount the root filesystem. This manifests in user space as Flatpak (bwrap) crashes and non-functioning portals.

Common journalctl -b -p err Log from First Boot

This log is consistent across Methods 1 and 3, highlighting the common failure points:

What did you expect to happen?

reference bazzite:stable images from a supported bootc install method and them deploy and work.

Session Logs (common for all install methods)

Nov 03 22:12:24 systemd-tmpfiles[489]: /usr/lib/tmpfiles.d/static-nodes-permissions.conf:12: Failed to resolve group 'audio': No such process
Nov 03 22:12:24 systemd-tmpfiles[489]: /usr/lib/tmpfiles.d/static-nodes-permissions.conf:18: Failed to resolve group 'kvm': No such process
Nov 03 22:12:24 systemd-tmpfiles[623]: /usr/lib/tmpfiles.d/systemd.conf:11: Failed to resolve group 'utmp': No such process
Nov 03 22:12:24 systemd-udevd[619]: /usr/lib/udev/rules.d/50-udev-default.rules:40 Unknown group 'tty', ignoring.
Nov 03 22:12:28 systemd[1]: Failed to start systemd-remount-fs.service - Remount Root and Kernel File Systems.
Nov 03 22:12:28 systemd-remount-fs[1016]: /usr/bin/mount for / exited with exit status 32.
Nov 03 22:12:30 systemd-tmpfiles[1329]: "/home" already exists and is not a directory.
Nov 03 22:14:49 systemd-coredump[5815]: [🡕] Process 5811 (bwrap) of user 1000 dumped core.

Hardware

7950X3D, 96GB, 7900XTX, 4TB NVME (blanked for tests).

Extra information or context

Failed Installation Methods

Method	Summary of Issue	Root Cause
1. Anaconda + Network Kickstart	Installation succeeded, but first boot produced the critical systemd-remount-fs and "Unknown group" errors shown above.	Installation process applied incorrect SELinux labels and failed to correctly provision system user files.
2. bootc install to-filesystem (Live USB)	Repeatedly failed mid-install with resource exhaustion (OOM-killed) or storage driver deadlocks (overlay on overlay) even when attempting to utilize an 98GB RAM system for cache.	Implies the image's layer structure combined with vfs driver requires extreme resources, or the default overlay driver deadlocks. Can also be worked around by creating a tempory subvol on target for iimage-pull
3. bootc-image-builder (Minimal TOML)	Installation succeeded, but first boot produced the exact same critical systemd-remount-fs and "Unknown group" errors as Method 1.	Proves the base image itself is incompatible with a standard Anaconda installation flow.
4. bootc-image-builder (Full Kickstart TOML)	Installs produces exact same critical systemd-remount-fs and "Unknown group" errors as Method 1	Several Conflict s between Anaconda's partition setup logic and the ostreecontainer verb.

Suggested Solution

It is strongly recommended that a dedicated, minimal bootc-installer ISO/image be provided.

This approach would entirely bypass the unreliable Anaconda installation layer, use bootc to only partition the drive, and then let the Bazzite image handle the full deployment and post-install setup on first boot. This would ensure the image itself sets up its own user environments and system groups, avoiding the conflicts caused by the Anaconda installer.

[aenertia]

Adding a significant update to this issue concerning a successful, stable deployment achieved via a fifth method: switching from a functional Fedora 43 Silverblue base.

This test case is critical because it validates that the Bazzite image is sound, but the system configuration performed by all reported installation methods is flawed.

✅ Successful Deployment via bootc switch (Method 5)

I successfully created a stable Bazzite system by installing Fedora 43 Silverblue first, then executing a bootc switch to Bazzite.

While the system booted, it immediately hit the exact errors reported in the issue description, plus significant security blocks. This confirms the failure is due to post-install provisioning conflicts, not a true installer failure.

Logged Error/Issue	Status after bootc switch	Post-Deploy Fixup Outcome
Failed to resolve group (audio, kvm, disk)	Persistent	Required custom usermod/groupadd execution to force persistence in the /etc overlay.
systemd-remount-fs.service failed (Exit 32)	Persistent	Masked out entirely (systemctl mask) as it conflicts with the new ComposeFS structure.
Flatpak/bwrap Crashes (Unusable system)	Resolved	Required SELinux policy deployment to allow core execution flows and context restoration.
Login / PAM failures (user@968.service)	Resolved	Required SELinux fix to stabilize system authentication helpers.

🎯 Conclusion on Usability

This success path proves that the Bazzite image can be used reliably bare-metal, but only by bypassing the default provisioning layers and performing extensive, manual post-configuration.

• The issue is not with the Bazzite image's content, but with the interaction between the immutable base and the provisioning tools' inability to correctly set the initial SELinux policy, group synchronization, and systemd mask rules.
• This further supports the initial suggestion: a simplified, dedicated provision --- strongly recommend that resolving these issues is prioritised as all existing docs/suggestions that a rebase from now bootc based silverblue/kiinote images will result in quite broken systems until resolved.