Посмотрите на эту ссылку: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1493888/comments/183
Это официальное обходное решение, пока не будет выпущено исправление.
Ошибка #1493888 гласит
Драйвер fglrx не совместим с gcc 5.x. Это приводит к сбою модуля ядра при инициализации. В результате пользователи будут загружаться с черным экраном, так как X не будет работать (кроме гибридных систем Intel+AMD, где используется intel).
Как описано в журнале фиксации ядра , на который ссылается jiliagre выше, файловая система nsfs
— это виртуальная файловая система, делающая доступными пространства имен -ядра Linux . Он отделен от файловой системы /proc
"proc", где некоторые записи каталога процесса ссылаются на inodes в файловой системе nsfs
, чтобы показать, какие пространства имен использует в настоящее время определенный процесс (или поток ).
nsfs
не входит в список /proc/filesystems
(, а proc
— в ), поэтому его нельзя смонтировать явно. mount -t nsfs./namespaces
ошибка с "неизвестным типом файловой системы". Это так же nsfs
, как и тесно переплетено с файловой системой proc
.
Тип файловой системы nsfs
становится видимым только через /proc/$PID/mountinfo
, когда связывает -монтирует существующий (! )Ссылка файловой системы пространства имен на другую цель. Как правильно заметил выше Стивен Китт, это нужно для сохранения существующих пространств имен, даже если ни один процесс их больше не использует.
Например, создайте новое пользовательское пространство имен с новым сетевым пространством имен, затем привяжите -смонтируйте его, затем выйдите :пространство имен все еще существует, но lsns
не найдет его, так как его нет в списке /proc/$PID/ns
больше, но существует как точка монтирования (bind ).
# bind mount only needs an inode, not necessarily a directory ;)
touch mynetns
# create new network namespace, show its id and then bind-mount it, so it
# is kept existing after the unshare'd bash has terminated.
# output: net:[##########]
NS=$(sudo unshare -n bash -c "readlink /proc/self/ns/net && mount --bind /proc/self/ns/net mynetns") && echo $NS
# notice how lsns cannot see this namespace anymore: no match!
lsns -t net | grep ${NS:5:-1} || echo "lsns: no match for net:[${NS:5:-1}]"
# however, findmnt does locate it on the nsfs...
findmnt -t nsfs | grep ${NS:5:-1} || echo "no match for net:[${NS:5:-1}]"
# output: /home/.../mynetns nsfs[net:[##########]] nsfs rw
# let the namespace go...
echo "unbinding + releasing network namespace"
sudo umount mynetns
findmnt -t nsfs | grep ${NS:5:-1} || echo "findmnt: no match for net:[${NS:5:-1}]"
# clean up
rm mynetns
Вывод должен быть похож на этот:
net:[4026532992]
lsns: no match for net:[4026532992]
/home/.../mynetns nsfs[net:[4026532992]] nsfs rw
unbinding + releasing network namespace
findmnt: no match for net:[4026532992]
Обратите внимание, что невозможно создавать пространства имен через файловую систему nsfs, только через системные вызовы clone()(CLONE_NEW...
)и unshare . nsfs
отражает только текущий статус ядра относительно. пространства имен, но не может создавать или уничтожать их.
Пространства имен автоматически уничтожаются всякий раз, когда на них не осталось ссылок, нет процессов (, поэтому/proc/$PID/ns/...
)И no bind -также не монтируются, как мы рассмотрели в приведенном выше примере.
Это «Файловая система пространства имен», используемая системным вызовомsetns
и, как показывает ее исходный код, ioctl, связанные с пространством имен (, например. NS_GET_USERNS
, NS_GET_OWNER_UID
...)
NSFS
Записи псевдофайлов -раньше предоставлялись файловой системой /proc
до Linux 3.19. Вот коммит этого изменения .
См. комментарий Стивена Китта о возможном объяснении присутствия этих файлов.