Toolbox: Richten Sie /media und /mnt entsprechend dem Host ein

Ich hatte das gleiche Problem nach dem Upgrade von Silverblue. Dies waren die Pakete, die im Upgrade enthalten waren. Nach dem Zurückrollen wurde es behoben.

       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

Vermutlich hat das eine neue Version von crun verursacht.

Ich habe einen alten Ersatz-Laptop, den ich zum Testen verwende; es läuft Silverblue Rawhide. Toolbox arbeitet dort an seinem neuesten Update (Rawhide.20191107.n.1), aber es liegt zwischen den F31-Versionen: crun-0.10.4-1.fc32.x86_64 .

Es scheint also etwas zwischen 0.10.4 und 0.10.5 gebrochen zu sein . Hoffentlich hilft dies, das Problem zu isolieren und es entweder in crun oder podman zu beheben ... oder umzugehen oder es in der Toolbox anzupassen.

Ich sollte jedoch beachten, dass podman in rawhide die Version 1.6.3-0.34.dev.git1e750f7.fc32.x86_64 , nicht podman-1.6.2-2.fc31.x86_64 .

Inzwischen ist die Toolbox an allen Stellen auf der gleichen Version, toolbox-0.0.16-1.fc31.noarch (oder toolbox-0.0.16-1.fc32.noarch in Rohhaut).

Würden Sie bitte die Ausgabe von stat /media vom Host teilen?

Ich habe eine PR geöffnet, um es in Crun zu beheben. In der Zwischenzeit können Sie es umgehen mit:

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

Danke für die schnelle Lösung, @giuseppe!!

Ich habe ein ähnliches Problem mit /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

Ich habe gerade alle Verweise auf /mnt und /run/media in der Toolbox entfernt, und das hat das Problem vorübergehend für mich behoben.

@p1u3o nur um sicher zu gehen, dass mein Fix Ihr Problem behebt, könnten Sie mir die Ausgabe für stat /mnt ?

@giuseppe Ich habe das gleiche Problem. Die Ausgabe von stat /mnt ist:
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

Wenn es hilfreich ist, verwende ich XFS mit SELinux als freigebend.

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

Selbes Problem hier.
Nach Wiederherstellung eines Containers kann immer noch nicht eintreten.
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

Ich kann bestätigen, dass das Downgrade von Crun auf SB31 mit den neuesten Updates zu funktionierenden Toolbox-Containern führt. "31.20191115.0 (2019-11-15T01:59:08Z)" ausführen und die folgenden Schritte ausführen:

1. crun-0.10.4-1.fc31 herunterladen (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 ersetzen ~/Downloads/crun-0.10.4-1.fc31.x86_64.rpm
3. Systemctl-Neustart

Vielleicht ist dies hilfreich für jemanden, der keine Arbeit an SB als Hauptdesktop erledigt, ohne über funktionierende Toolbox-Container zu verfügen.

Ich bin froh, dass ich diesen Beitrag von @garrett gefunden habe, der mich in diese Richtung https://discussion.fedoraproject.org/t/toolbox-broken-again-crun-update-in-31-20191112-0/11369/8

@stephanmol Danke, Toolbox funktioniert wieder.

Ein paar Tage später ist der Werkzeugkasten wieder kaputt.
Scheint das Problem in crun-0.10.6-1.fc3 behoben zu sein, laut dieser Info https://github.com/containers/libpod/issues/4024.
Um das Problem zu beheben, führen Sie ähnliche Schritte wie oben bei @stephanmol aus :

• crun-0.10.6-1.fc3 herunterladen (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 ersetzen ~/Downloads/crun-0.10.6-1.fc31.x86_64.rpm

• Systemctl-Neustart

@aaronuurman crun-0.10.6-1.fc31.x86_64 ist seit gestern in Silverblue. Sie sollten nicht mehr überschreiben müssen.

Dank der Toolbox (und Podman und Crun) erledige ich in diesem Moment gerne die Arbeit in Containern auf Silverblue. Hoffentlich funktioniert nach einem rpm-ostree update (und Neustart) auch bei dir alles wieder?

Sollte die Überschreibung nach dem Ausführen von rpm-ostree upgrade bleiben, musste ich rpm-ostree override reset crun manuell ausführen, wodurch die neueste Version von Crun verwendet wurde, die das Problem behebt (yay!)

Danke für die Klärung ,

Es scheint, dass die Überschreibung nach dem rpm-ostree-Upgrade an Ort und Stelle
Danke für den Hinweis :+1:

FWIW, ich habe rpm-ostree override reset -a und neu gestartet, nur um sicherzugehen, dass ich keine Überschreibungen hatte. (Die Angabe von nur crun oder crun-0.10.6 hat nicht funktioniert. Aber das Zurücksetzen aller hat geholfen.)

Die Crun-Überschreibung wurde nicht angezeigt, aber ich wollte sicherstellen, dass sie nicht transparent war, da es sich um dieselbe Version handelte, die jetzt in Silverblue ausgeliefert wird. (Ich möchte in Zukunft keine Überraschung erleben. :wink:)

Lassen Sie mich dieses Thema neu aufgreifen, um unseren Umgang mit /mnt und /media zu verbessern, um die Dinge kurzfristig etwas robuster zu machen. Dasselbe machen wir bereits für /home .