Bazzite is an image-based Linux operating system for gaming desktops and handheld systems. Installation writes a selected hardware and desktop image to a target drive. The running system keeps operating-system deployments separate from ordinary applications. A Flatpak app or a Homebrew command does not become part of the host image merely because it appears in the desktop session.
Bazzite-Deck images start in Steam Gaming Mode and keep Desktop Mode available through the power menu. Other images open a conventional desktop first. Choosing the wrong image changes the default session and hardware assumptions, so the selection precedes any application setup.
The live session is an installer check, not a benchmark
The bootable media can confirm that the installer starts and that basic hardware appears. Bazzite documentation warns against using that live session to judge gaming performance because it uses a different kernel and lacks some installed-system hardware support.
The installer erases the selected target drive. The documented installation can write the selected image without an Internet connection.
Software belongs to several installation layers
Flatpak is the primary path for graphical applications. Homebrew handles command-line tools in its own package area. A Distrobox container can install packages from another distribution and export a launcher to the Bazzite desktop.
An AppImage follows a standalone-file path. Quadlet defines containerized services through another path. Host package layering through rpm-ostree changes the system deployment itself, and Bazzite documents that method as a last resort. A package inside Distrobox is therefore not an rpm-ostree layer even when both launch from the same desktop.
Windows compatibility and Android application paths remain selective. Bazzite does not promise that every program built for either platform will run. The original platform requirements and the selected compatibility component still set the boundary.
A backup deployment is not automatically permanent
The bootloader keeps a backup system deployment. Choosing it for one boot starts that older system state temporarily; it does not make the backup primary for later restarts. The documented rollback action changes which deployment becomes the default after reboot.
Deployment indexes can shift after another system transaction. A command copied from an earlier screen may therefore point at a different entry later. Pinning a deployment protects it from automatic cleanup when that exact state must remain available.
System rollback does not roll back personal files. A document changed under the newer deployment remains changed after the older operating-system state starts.
Shared-drive Windows setup has extra conditions
The documented shared-drive dual-boot path uses automatic partitioning after space is prepared. Windows BitLocker and Fast Startup must be disabled for that arrangement. The procedure also regenerates GRUB after installation so the Windows entry appears.
Secure Boot uses a Universal Blue enrollment key. Password input during enrollment stays hidden and assumes a QWERTY layout. A user typing on another layout can enter different characters without seeing the mismatch, which makes a correct-looking passphrase fail silently.
Disk encryption adds another credential at boot. These passwords serve different components: the Secure Boot key enrollment is not the LUKS disk passphrase. Recording one does not recover the other.
