Toolbox: Configurer /media et /mnt pour correspondre à l'hôte

J'ai eu le même problème après la mise à niveau de Silverblue. Ce sont les packages inclus dans la mise à niveau. Il a été corrigé après le retour en arrière.

       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

Probablement une nouvelle version de crun causé cela.

J'ai un vieil ordinateur portable de rechange que j'utilise pour les tests ; il exécute Silverblue Rawhide. Toolbox y travaille sur sa mise à jour la plus récente (Rawhide.20191107.n.1), mais c'est entre les versions F31 : crun-0.10.4-1.fc32.x86_64 .

Il semble donc que quelque chose s'est cassé entre 0,10.4 et 0,10,5 . Espérons que cela aide à isoler le problème et à le résoudre dans crun ou podman... ou à le contourner ou à s'y adapter dans la boîte à outils.

Cependant, je dois noter que podman en cuir brut est à la version 1.6.3-0.34.dev.git1e750f7.fc32.x86_64 , pas podman-1.6.2-2.fc31.x86_64 .

Pendant ce temps, toolbox est sur la même version dans tous les endroits, toolbox-0.0.16-1.fc31.noarch (ou toolbox-0.0.16-1.fc32.noarch en cuir brut).

pourriez-vous s'il vous plaît partager la sortie de stat /media de l'hôte ?

J'ai ouvert un PR pour le réparer en crun. En attendant, vous pouvez le contourner avec :

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

Merci pour la solution rapide, @giuseppe !!

J'ai un problème similaire avec /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

Je viens de supprimer toutes les références à /mnt et /run/media dans la boîte à outils et cela a temporairement résolu le problème pour moi.

@p1u3o juste pour être sûr que mon correctif résout votre problème, pourriez-vous me montrer la sortie pour stat /mnt ?

@giuseppe J'ai le même problème. La sortie de stat /mnt est :
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

Si cela peut vous aider, j'utilise XFS avec SELinux défini comme permissif.

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

Même problème ici.
Après la récréation d'un conteneur ne peut toujours pas entrer.
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

Je peux confirmer que la rétrogradation de crun sur SB31 à l'aide des dernières mises à jour entraînera des conteneurs de boîte à outils fonctionnels. Exécutez "31.20191115.0 (2019-11-15T01:59:08Z)" et exécutez ces étapes :

1. Télécharger 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 override remplacer ~/Downloads/crun-0.10.4-1.fc31.x86_64.rpm
3. redémarrage systemctl

Peut-être que cela est utile pour quelqu'un qui ne travaille pas sur SB en tant que bureau principal sans avoir des conteneurs de boîte à outils fonctionnels.

Je suis content d'avoir trouvé ce post de @garrett qui m'a https://discussion.fedoraproject.org/t/toolbox-broken-again-crun-update-in-31-20191112-0/11369/8

@stephanmol Merci, la boîte à outils fonctionne à nouveau.

Quelques jours plus tard, la boîte à outils est à nouveau cassée.
Il semble que le problème soit résolu dans crun-0.10.6-1.fc3, selon cette information https://github.com/containers/libpod/issues/4024.
Pour résoudre le problème, effectuez des étapes similaires à celles de @stephanmol mentionnées ci-dessus :

• Télécharger 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 override remplacer ~/Downloads/crun-0.10.6-1.fc31.x86_64.rpm

• redémarrage systemctl

@aaronuurman crun-0.10.6-1.fc31.x86_64 est en Silverblue depuis hier. Vous ne devriez plus avoir besoin de passer outre.

Je travaille avec plaisir dans des conteneurs sur Silverblue en ce moment même grâce à toolbox (et podman et crun). Espérons que tout fonctionne à nouveau pour vous après un rpm-ostree update (et un redémarrage) ?

Si l'override restait en place après avoir exécuté rpm-ostree upgrade je devais effectuer manuellement rpm-ostree override reset crun ce qui l'obligeait à utiliser la dernière version de crun qui résout le problème (yay !)

Merci d'avoir réglé ça ,

Il semble que le remplacement reste en place après la mise à niveau de rpm-ostree , c'est probablement pourquoi j'ai fait un nouveau remplacement.
Merci de l'avoir signalé :+1:

FWIW, j'ai fait un rpm-ostree override reset -a et j'ai redémarré juste pour être sûr que je n'avais pas _aucun_ remplacement. (Spécifier simplement crun ou crun-0.10.6 n'a pas fonctionné. Mais la réinitialisation de tout a fonctionné.)

Le remplacement de crun ne s'affichait pas, mais je voulais m'assurer qu'il n'était pas là de manière transparente car c'était la même version que ce qui est maintenant livré dans Silverblue. (Je ne veux pas avoir de surprise à l'avenir. :wink:)

Permettez-moi de réutiliser ce problème pour améliorer notre gestion de /mnt et /media afin de rendre les choses un peu plus robustes à court terme. Nous faisons déjà la même chose pour /home .