Distrobox: Difference between revisions

(One intermediate revision by one other user not shown)

Line 79:

[[Category:Applications]]

[[Category:Container]]

== Known Issues ==

=== Distrobox Fails With Arch Linux and init ===

This is a cross-distro (not NixOS-specific) issue resulting from a [https://github.com/util-linux/util-linux/ util-linux] runuser regression.<ref name="debian-report">https://github.com/89luca89/distrobox/issues/2069</ref><ref name="nixos-report">https://github.com/89luca89/distrobox/issues/2065</ref> A fix has recently been merged, and the issue should be resolved in the next release (v2.43).<ref name="util-linux-pull">https://github.com/util-linux/util-linux/pull/4185</ref>.

=== Distrobox is not location independent ===

The symptom is that a distrobox container created in the past can not run, because it references a non-existing "distrobox-init" script as a necessary bind mount.

Historically, this was a known issue<ref>https://github.com/89luca89/distrobox/issues/315</ref> affecting users who have created a container with a different version of distrobox than the one that is currently running. It can surface after running GC. The root cause is that the container is created with bind mounts for essential scripts, one of which is the entrypoint itself, the source of which is often an absolute path, such as: <code>/nix/store/XXXXX-distrobox/bin/distrobox-init</code>. The problem is that once a container was created with a bind mount, its source has to be available every time the container is re-executed.

This issue was solved 2 times upstream, both in 2022:

The first solution<ref>https://github.com/89luca89/distrobox/commit/52a34fbd52e1f0f035657b167ebe997d41db0993</ref> replaces the bind-mount with copying the scripts into the container during distrobox-enter.

The second solution<ref>https://github.com/89luca89/distrobox/commit/1ad3204ee78dfb8ee772cdd81788f3cbb3f4bd1b</ref> reverts the first solution, due to problems the former had introduced with btrfs. In order to avoid regressions for Nix users, it introduces a weaker solution for mounting the scripts: instead of <code>realpath</code>, it makes use of: <code>cd "$(dirname "${0}")" && pwd</code>. That works, but only as long as:

# The "$0" argument is preserved. There was an [https://github.com/NixOS/nixpkgs/issues/478154 issue in nixpkgs], fixed in 2026<ref>https://github.com/NixOS/nixpkgs/commit/2f87ef8fdbabc6df0fbaf59ad14598864711ed4c</ref>, with non-preservation of "$0" in the "distrobox" command wrapper. Direct calls to <code>distrobox-create</code> were unaffected.

# In every future execution of the container, the distrobox utilities will remain in the same path. This is workable when the installation is fixed on a path like <code>/run/current-system/sw/bin/distrobox-init</code>.

Notably, if you were affected by the first issue, then your container will not work even after the fixes that have since come out. The second issue is not resolved due to decisions upstream.

== References ==

@@ Line 79: / Line 79: @@
 [[Category:Applications]]
 [[Category:Container]]
+== Known Issues ==
+=== Distrobox Fails With Arch Linux and init ===
+This is a cross-distro (not NixOS-specific) issue resulting from a [https://github.com/util-linux/util-linux/ util-linux] runuser regression.<ref name="debian-report">https://github.com/89luca89/distrobox/issues/2069</ref><ref name="nixos-report">https://github.com/89luca89/distrobox/issues/2065</ref> A fix has recently been merged, and the issue should be resolved in the next release (v2.43).<ref name="util-linux-pull">https://github.com/util-linux/util-linux/pull/4185</ref>.
+=== Distrobox is not location independent ===
+The symptom is that a distrobox container created in the past can not run, because it references a non-existing "distrobox-init" script as a necessary bind mount.
+Historically, this was a known issue<ref>https://github.com/89luca89/distrobox/issues/315</ref> affecting users who have created a container with a different version of distrobox than the one that is currently running. It can surface after running GC. The root cause is that the container is created with bind mounts for essential scripts, one of which is the entrypoint itself, the source of which is often an absolute path, such as: <code>/nix/store/XXXXX-distrobox/bin/distrobox-init</code>. The problem is that once a container was created with a bind mount, its source has to be available every time the container is re-executed.
+This issue was solved 2 times upstream, both in 2022:
+The first solution<ref>https://github.com/89luca89/distrobox/commit/52a34fbd52e1f0f035657b167ebe997d41db0993</ref> replaces the bind-mount with copying the scripts into the container during distrobox-enter.
+The second solution<ref>https://github.com/89luca89/distrobox/commit/1ad3204ee78dfb8ee772cdd81788f3cbb3f4bd1b</ref> reverts the first solution, due to problems the former had introduced with btrfs. In order to avoid regressions for Nix users, it introduces a weaker solution for mounting the scripts: instead of <code>realpath</code>, it makes use of: <code>cd "$(dirname "${0}")" && pwd</code>. That works, but only as long as:
+# The "$0" argument is preserved. There was an [https://github.com/NixOS/nixpkgs/issues/478154 issue in nixpkgs], fixed in 2026<ref>https://github.com/NixOS/nixpkgs/commit/2f87ef8fdbabc6df0fbaf59ad14598864711ed4c</ref>, with non-preservation of "$0" in the "distrobox" command wrapper. Direct calls to <code>distrobox-create</code> were unaffected.
+# In every future execution of the container, the distrobox utilities will remain in the same path. This is workable when the installation is fixed on a path like <code>/run/current-system/sw/bin/distrobox-init</code>.
+Notably, if you were affected by the first issue, then your container will not work even after the fixes that have since come out. The second issue is not resolved due to decisions upstream.
+== References ==
+<references/>