Toolbox: Configure / media y / mnt para que coincidan con el host

Tuve el mismo problema después de actualizar Silverblue. Estos fueron los paquetes incluidos en la actualización. Se solucionó después de retroceder.

       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

Probablemente una nueva versión de crun causó esto.

Tengo una vieja computadora portátil de repuesto que utilizo para realizar pruebas; está ejecutando Silverblue Rawhide. Toolbox está trabajando allí en su actualización más reciente (Rawhide.20191107.n.1), pero está entre las versiones F31: crun-0.10.4-1.fc32.x86_64 .

Entonces parece que algo se rompió en crun entre 0.10.4 y 0.10.5 . Con suerte, esto ayuda a aislar el problema y solucionarlo en crun o podman ... o solucionarlo o adaptarse a él en la caja de herramientas.

Sin embargo, debo tener en cuenta que podman en cuero crudo está en la versión 1.6.3-0.34.dev.git1e750f7.fc32.x86_64 , no podman-1.6.2-2.fc31.x86_64 .

Mientras tanto, la caja de herramientas está en la misma versión en todos los lugares, toolbox-0.0.16-1.fc31.noarch (o toolbox-0.0.16-1.fc32.noarch en cuero crudo).

¿Podría compartir la salida de stat /media del host?

Abrí un PR para arreglarlo en crun. Mientras tanto, puede solucionarlo con:

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

¡¡Gracias por la solución rápida, @giuseppe !!

Tengo un problema similar con / 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

Acabo de eliminar todas las referencias a / mnt y / run / media en la caja de herramientas y eso me resolvió temporalmente el problema.

@ p1u3o solo para asegurarme de que mi solución solucione su problema, ¿podría mostrarme el resultado de stat /mnt ?

@giuseppe Tengo el mismo problema. La salida de stat /mnt es:
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 es de alguna ayuda, estoy usando XFS con SELinux configurado como permisivo.

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

El mismo problema aqui.
Después de la recreación de un contenedor todavía no se puede ingresar.
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

Puedo confirmar que la degradación de crun en SB31 usando las últimas actualizaciones dará como resultado contenedores de caja de herramientas que funcionen. Ejecutando "31.20191115.0 (2019-11-15T01: 59: 08Z)" y realizó estos pasos:

1. Descargar 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 anular reemplazar ~ / Downloads / crun-0.10.4-1.fc31.x86_64.rpm
3. reiniciar systemctl

Tal vez esto sea útil para alguien que no trabaje en SB como escritorio principal sin tener contenedores de caja de herramientas que funcionen.

Me alegro de haber encontrado esta publicación de @garrett que me señaló en esta dirección https://discussion.fedoraproject.org/t/toolbox-broken-again-crun-update-in-31-20191112-0/11369/8

@stephanmol Gracias, la caja de herramientas volvió a funcionar.

Unos días después, la caja de herramientas vuelve a estar rota.
Parece que el problema se solucionó en crun-0.10.6-1.fc3, según esta información https://github.com/containers/libpod/issues/4024.
Para solucionar el problema, realice pasos similares a los de @stephanmol mencionados anteriormente:

• Descarga 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 anular reemplazar ~ / Downloads / crun-0.10.6-1.fc31.x86_64.rpm

• reiniciar systemctl

@aaronuurman crun-0.10.6-1.fc31.x86_64 está en Silverblue desde ayer. Ya no debería necesitar anular.

Estoy felizmente trabajando en contenedores en Silverblue en este mismo momento gracias a toolbox (y podman y crun). Esperemos que todo vuelva a funcionar para ti también después de un rpm-ostree update (y reiniciar).

En caso de que la anulación permanezca en su lugar después de ejecutar rpm-ostree upgrade , tuve que realizar manualmente rpm-ostree override reset crun que hizo que se usara la última versión de crun que soluciona el problema (¡yay!)

¡Gracias por solucionar esto, @giuseppe !

Parece que la anulación permanece en su lugar después de la actualización de rpm-ostree , probablemente por eso hice una nueva anulación.
Gracias por señalarlo: +1:

FWIW, hice un rpm-ostree override reset -a y reinicié solo para asegurarme de que no tenía _ ninguna_ anulación. (Especificar solo crun o crun-0.10.6 no funcionó. Pero restablecer todo lo hizo).

La anulación de crun no se mostraba, pero quería asegurarme de que no fuera transparente porque era la misma versión que la que ahora se envía en Silverblue. (No quiero tener ninguna sorpresa en el futuro.: Guiño :)

Permítanme modificar este tema para mejorar nuestro manejo de /mnt y /media para hacer las cosas un poco más sólidas en el corto plazo inmediato. Ya hacemos lo mismo por /home .