Сегодня я внезапно не смог войти в свой набор инструментов, поэтому я попытался воссоздать его снова, используя toolbox reset
и toolbox enter
но безуспешно. Вот результат toolbox -v enter
:
toolbox: running as real user ID 1000
toolbox: resolved absolute path for /usr/bin/toolbox to /usr/bin/toolbox
toolbox: checking if /etc/subgid and /etc/subuid have entries for user zlopez
toolbox: TOOLBOX_PATH is /usr/bin/toolbox
toolbox: running on a cgroups v2 host
toolbox: current Podman version is 1.6.2
toolbox: migration not needed: Podman version 1.6.2 is unchanged
toolbox: Fedora generational core is f31
toolbox: base image is fedora-toolbox:31
toolbox: container is fedora-toolbox-31
toolbox: checking if container fedora-toolbox-31 exists
toolbox: calling org.freedesktop.Flatpak.SessionHelper.RequestSession
toolbox: starting container fedora-toolbox-31
toolbox: /etc/profile.d/toolbox.sh already mounted in container fedora-toolbox-31
Error: unable to start container "fedora-toolbox-31": creating file '/var/home/zlopez/.local/share/containers/storage/overlay/bcd97a238cf639f8d3dfeef7b5c44b7ad9f4ba99410864856358b26ade201f1e/merged/media': Is a directory: OCI runtime error
toolbox: failed to start container fedora-toolbox-31
У меня была такая же проблема после обновления 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
.
Так что, похоже, что-то сломалось в crun между 0.10.4 и 0.10.5 . Надеюсь, это поможет изолировать проблему и либо исправить ее с помощью crun, либо podman ... либо обойти ее или приспособиться к ней в наборе инструментов.
Тем не менее, я должен отметить, что podman в rawhide находится в версии 1.6.3-0.34.dev.git1e750f7.fc32.x86_64
, а не podman-1.6.2-2.fc31.x86_64
.
Между тем, toolbox везде находится на одной и той же версии, toolbox-0.0.16-1.fc31.noarch
(или toolbox-0.0.16-1.fc32.noarch
в сыромятной коже).
не могли бы вы поделиться выводом stat /media
от хоста?
Я открыл PR, чтобы исправить это в crun. А пока вы можете обойти это с помощью:
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 с использованием последних обновлений приведет к рабочим контейнерам набора инструментов. Запустил «31.20191115.0 (2019-11-15T01: 59: 08Z)» и выполнил следующие действия:
Может быть, это полезно для кого-то, кто не работает над SB в качестве основного рабочего стола, не имея рабочих контейнеров с инструментами.
Я рад, что нашел этот пост @garrett, который указал мне в этом направлении https://discussion.fedoraproject.org/t/toolbox-broken-again-crun-update-in-31-20191112-0/11369/8
@stephanmol Спасибо, набор инструментов снова заработал.
Через несколько дней ящик для инструментов снова сломан.
Похоже, проблема исправлена в crun-0.10.6-1.fc3, согласно этой информации https://github.com/containers/libpod/issues/4024.
Чтобы решить эту проблему, выполните те же действия, что и @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. Вам больше не нужно переопределять.
Я с радостью выполняю работу в контейнерах на Silverblue прямо сейчас, благодаря инструментарию (а также podman и crun). Надеюсь, у вас тоже все rpm-ostree update
после
Если переопределение останется на месте после запуска rpm-ostree upgrade
мне пришлось выполнить вручную rpm-ostree override reset crun
что заставило его использовать последнюю версию crun, которая устраняет проблему (ура!)
Спасибо, что разобрались, @giuseppe !
Кажется, что переопределение остается на месте после обновления rpm-ostree , вероятно, поэтому я сделал новое переопределение.
Спасибо, что указали на это: +1:
FWIW, я сделал rpm-ostree override reset -a
и перезагрузился, чтобы убедиться, что у меня нет _any_ переопределений. (Указание только crun или crun-0.10.6 не сработало. Но все сбросили.)
Переопределение crun не отображалось, но я хотел убедиться, что он не был прозрачным, потому что это была та же версия, что и в Silverblue. (Не хочу в будущем сюрпризов.: Wink :)
Позвольте мне изменить решение этой проблемы, чтобы улучшить нашу обработку /mnt
и /media
чтобы сделать вещи немного более надежными в ближайшей краткосрочной перспективе. Мы уже делаем то же самое для /home
.
Самый полезный комментарий
Я открыл PR, чтобы исправить это в crun. А пока вы можете обойти это с помощью: