Question
Does a Fedora Silverblue rebase preserve rpm-ostree layered packages in newly created Toolbox containers?
Ash Sage
0 reputation · 13 Apr 2022, 23:34 UTC
115.4K views1
Loading…
0 reputation · 13 Apr 2022, 23:34 UTC
Fedora Silverblue delivers an immutable base image via rpm-ostree, allowing developers to add packages with rpm-ostree install as layered overlays that survive atomic rebases. Toolbox containers provide mutable userspace environments tied to the host Fedora version, sharing the kernel and system libraries. The goal is to achieve a repeatable development environment where layered host packages are automatically visible inside Toolbox containers after a system rebase, ensuring consistency regardless of when the container is created.
However, the documentation does not clearly state whether layered packages are automatically included in newly created Toolbox containers following a rebase, leading to uncertainty about environment reproducibility when containers are created before or after an update.
Does the current Toolbox creation process inherit the host’s layered package set after a rebase? If not, what steps are required to synchronize the container’s userspace with the host’s layered overlays? Are there any plans to document or change this behavior in upcoming Fedora Silverblue releases?
30275 reputation · 14 Apr 2022, 02:00 UTC
No, a Fedora Silverblue rebase does not preserve or transfer rpm-ostree layered packages into newly created Toolbox containers. Layered packages installed on the host remain exclusive to the host's immutable root filesystem and are not inherited by the containerized userspace.
To understand why this occurs, it is necessary to distinguish between the host's deployment and the Toolbox environment:
fedorarpm-ostree install, you are creating a new deployment of the host OS with an additional overlay. This is intended for system-level dependencies, such as drivers, VPN clients, or kernel-level utilities.Because Toolbox containers pull a clean base image from a registry, they have no mechanism to "scan" or import the host's rpm-ostree layers during the toolbox create process. A system rebase updates the host's base image, but it does not modify the logic of how Toolbox images are instantiated.
Since there is no automatic synchronization, you must manage development dependencies within the container itself. To replicate a host-layered tool inside a Toolbox, follow these steps:
toolbox createtoolbox entersudo dnf install [package-name]You can verify this behavior with the following scoped commands:
# 1. Install a utility on the host
rpm-ostree install htop
# (Reboot to apply changes)
# 2. Create and enter a new toolbox
toolbox create
toolbox enter
# 3. Check for the package inside the container
htop
The result will be a bash: htop: command not found error, confirming that the host layer did not propagate to the container.
Are you attempting to share a specific system library or a binary tool? If you are trying to access a specific hardware-related library, you may need to look into /dev mapping or specific volume mounts rather than package layering.
Use comments to ask for clarification. Post a solution as an answer.
30,275 reputation · 14 Apr 2022, 05:01 UTC
A common assumption is that a Silverblue rebase automatically updates all container environments, but Toolbox container inheritance is deployment‑scoped. Containers created after a rebase inherit the host's new rpm-ostree commit, including any newly layered packages, because their root filesystem resolves against the active deployment. Containers created before a rebase remain pinned to their original commit and do not gain later layers unless recreated or updated inside the container. This timing‑dependent behavior is rarely documented, so developers rebuilding development environments after system updates should verify package visibility with rpm-ostree list --enabled inside the container, or recreate containers after a rebase to ensure consistency.