Toolbox: 设置 /media 和 /mnt 以匹配主机

升级 Silverblue 后我遇到了同样的问题。 这些是升级中包含的软件包。 回滚后就解决了。

       Upgraded: crun 0.10.2-1.fc31 -> 0.10.5-2.fc31
                 kernel 5.3.8-300.fc31 -> 5.3.9-300.fc31
                 kernel-core 5.3.8-300.fc31 -> 5.3.9-300.fc31
                 kernel-devel 5.3.8-300.fc31 -> 5.3.9-300.fc31
                 kernel-modules 5.3.8-300.fc31 -> 5.3.9-300.fc31
                 kernel-modules-extra 5.3.8-300.fc31 -> 5.3.9-300.fc31

可能是crun的新版本导致了这种情况。

我有一台旧的备用笔记本电脑用于测试； 它正在运行 Silverblue Rawhide。 Toolbox 正在那里进行最新更新 (Rawhide.20191107.n.1)，但它介于 F31 版本之间： crun-0.10.4-1.fc32.x86_64 。

因此，似乎在 0.10.4 和 0.10.5 之间的 crun 中出了点问题。 希望这有助于隔离问题并在 crun 或 podman 中修复它......或者在工具箱中解决或适应它。

但是，我应该注意到 rawhide 中的 podman 版本1.6.3-0.34.dev.git1e750f7.fc32.x86_64 ，而不是podman-1.6.2-2.fc31.x86_64 。

同时，工具箱在所有地方都使用相同的版本， toolbox-0.0.16-1.fc31.noarch （或生皮中的toolbox-0.0.16-1.fc32.noarch ）。

你能分享一下来自主机的stat /media的输出吗？

我已经在 crun 中打开了一个 PR 来修复它。 同时，您可以通过以下方式解决它：

diff --git a/toolbox b/toolbox
index a7433e1..6b443c7 100755
--- a/toolbox
+++ b/toolbox
@@ -987,7 +987,7 @@ create()
     fi

     if [ -d /run/media ] 2>&3; then
-        run_media_path_bind="--volume /run/media:/run/media:rslave"
+        run_media_path_bind="--volume $(readlink -f /run/media):/run/media:rslave"
     fi

     echo "$base_toolbox_command: checking if /usr is mounted read-only or read-write" >&3

感谢您的快速修复，@giuseppe！！

我遇到了类似的问题 /mnt

Error: unable to start container "fedora-toolbox-31": creating file '/var/home/pluto/.local/share/containers/storage/overlay/e56a2816dbb492d3446030ba65d10d659ee6dd621dbaf76e20290f59ad4f35af/merged/mnt': Is a directory: OCI runtime error

我刚刚删除了工具箱中对 /mnt 和 /run/media 的所有引用，这暂时为我解决了这个问题。

@p1u3o只是为了确保我的修复解决了您的问题，您能告诉我stat /mnt的输出吗？

@giuseppe我遇到了同样的问题。 stat /mnt的输出是：
File: /mnt -> var/mnt
Size: 7 Blocks: 0 IO Block: 4096 symbolic link
Device: fd01h/64769d Inode: 2621481 Links: 5
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:mnt_t:s0
Access: 2019-11-13 08:18:38.666995206 -0500
Modify: 2019-11-12 13:51:35.169000757 -0500
Change: 2019-11-13 06:09:45.432966095 -0500
Birth: 2019-11-12 13:51:35.169000757 -0500

如果有任何帮助，我将使用 XFS 并将 SELinux 设置为宽松。

File: /mnt -> var/mnt
  Size: 7           Blocks: 0          IO Block: 4096   symbolic link
Device: 822h/2082d  Inode: 134217875   Links: 4
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:mnt_t:s0
Access: 2019-11-13 09:13:30.879734789 +0000
Modify: 2019-11-11 09:36:01.148936755 +0000
Change: 2019-11-13 09:12:15.780417160 +0000
 Birth: 2019-11-11 09:36:01.148936755 +0000

同样的问题在这里。
重新创建一个容器后仍然无法进入。
File: /mnt -> var/mnt Size: 7 Blocks: 0 IO Block: 4096 symbolic link Device: fd00h/64768d Inode: 655408 Links: 4 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:mnt_t:s0 Access: 2019-11-13 20:58:21.899394135 +0200 Modify: 2019-10-19 12:03:46.378316430 +0300 Change: 2019-11-13 19:37:41.427229814 +0200 Birth: 2019-10-19 12:03:46.378316430 +0300

我可以确认使用最新更新在 SB31 上降级 crun 将导致工具箱容器正常工作。 运行“31.20191115.0 (2019-11-15T01:59:08Z)”并执行以下步骤：

1. 下载 crun-0.10.4-1.fc31 (https://kojipkgs.fedoraproject.org//packages/crun/0.10.4/1.fc31/x86_64/crun-0.10.4-1.fc31.x86_64.rpm)
2. rpm-ostree 覆盖替换 ~/Downloads/crun-0.10.4-1.fc31.x86_64.rpm
3. systemctl 重启

也许这对在没有工具箱容器的情况下将 SB 作为主桌面无法完成工作的人有所帮助。

我很高兴我找到了@garrett 的这篇文章，它为我指明了这个方向https://discussion.fedoraproject.org/t/toolbox-broken-again-crun-update-in-31-20191112-0/11369/8

@stephanmol谢谢，工具箱又开始工作了。

几天后，工具箱又坏了。
根据此信息https://github.com/containers/libpod/issues/4024 ，似乎问题已在 crun-0.10.6-1.fc3 中解决
要解决此问题，请执行与上面提到的@stephanmol类似的步骤：

• 下载 crun-0.10.6-1.fc3 (https://kojipkgs.fedoraproject.org//packages/crun/0.10.6/1.fc31/x86_64/crun-0.10.6-1.fc31.x86_64.rpm)

• rpm-ostree 覆盖替换 ~/Downloads/crun-0.10.6-1.fc31.x86_64.rpm

• systemctl 重启

@aaronuurman crun-0.10.6-1.fc31.x86_64截至昨天仍在Silverblue 中。 您不应该再需要覆盖了。

多亏了工具箱（以及 podman 和 crun），我现在很高兴在 Silverblue 的容器中完成工作。 希望它在rpm-ostree update （并重新启动）后对您再次起作用？

如果在运行rpm-ostree upgrade后覆盖保持原位，我必须手动执行rpm-ostree override reset crun这使得它使用最新版本的 crun 解决了这个问题（是的！）

感谢您解决这个问题， @giuseppe ！

似乎覆盖在rpm-ostree upgrade之后保持
感谢您指出：+1：

FWIW，我做了一个rpm-ostree override reset -a并重新启动只是为了确保我没有 _any_ 覆盖。 （仅指定 crun 或 crun-0.10.6 不起作用。但重置所有。）

crun 覆盖没有显示，但我想确保它不是透明的，因为它与现在在 Silverblue 中发布的版本相同。 （我不想在未来有一些惊喜。:wink:)

让我重新调整这个问题的目的，以改进我们对/mnt和/media ，使事情在短期内更加稳健。 我们已经对/home做了同样的事情。