Ошибка lsblk: failed to access sysfs directory /sys/dev/block: No such file or directory появляется, когда утилита lsblk не может прочитать каталог /sys/dev/block — виртуальную директорию файловой системы sysfs, через которую ядро Linux публикует информацию о блочных устройствах. Чаще всего это происходит не из-за «сломанного диска», а потому что вы работаете внутри chroot-окружения, контейнера Docker/LXC или минимальной системы восстановления, где каталог /sys просто не смонтирован.
Понимание сути проблемы экономит время: сама утилита исправна, диски на месте, но ей неоткуда получить данные. Ниже разберём, как работает sysfs, в каких сценариях возникает ошибка и как безопасно восстановить доступ к информации о блочных устройствах.
Что такое sysfs и почему lsblk зависит от неё
Sysfs — это виртуальная файловая система ядра Linux, которая обычно монтируется в каталог /sys. Она не хранится на диске: её содержимое ядро генерирует на лету, отражая текущее состояние устройств, драйверов и подсистем. Каталог /sys/dev/block содержит символические ссылки на все обнаруженные блочные устройства — диски, разделы, тома LVM и RAID-массивы.
Утилита lsblk из пакета util-linux строит свой вывод именно на основе sysfs: она читает атрибуты устройств из /sys/block и /sys/dev/block. Если этой структуры нет, утилита завершается с ошибкой доступа, потому что альтернативного источника данных у неё нет.
- 🔧
/sys/dev/block— индекс блочных устройств по номерам major:minor - 📁
/sys/block— каталоги отдельных дисков с атрибутами (размер, модель, очередь) - 🔗 Символические ссылки связывают номера устройств с их описаниями в дереве sysfs
Типичные сценарии появления ошибки
Самый распространённый случай — работа в chroot-окружении. Например, вы загрузились с LiveUSB, смонтировали корневой раздел установленной системы в /mnt и выполнили chroot /mnt для восстановления загрузчика. Внутри chroot каталог /sys пуст, если вы заранее не примонтировали туда sysfs хост-системы.
Второй сценарий — контейнеры. В Docker, LXC и подобных средах файловая система sysfs либо смонтирована в режиме только для чтения с ограниченным набором записей, либо её представление намеренно урезано изоляцией. В обычном непривилегированном контейнере lsblk может показать ошибку или пустой вывод — это ожидаемое поведение, а не сбой.
Третья ситуация — минимальные среды: initramfs при сбое загрузки, аварийные оболочки init=/bin/sh, некоторые embedded-системы. Там монтирование виртуальных ФС — задача самого пользователя или скриптов инициализации, и если она не выполнена, /sys остаётся пустым.
Быстрая диагностика: что проверить в первую очередь
Прежде чем что-либо монтировать, убедитесь, что проблема именно в отсутствии sysfs. Выполните несколько простых проверок — они не изменяют систему и полностью безопасны.
ls /sys
mount | grep sysfs
cat /proc/mounts | grep sysfs
Если каталог /sys пуст, а в выводе mount нет строки про sysfs — диагноз подтверждён. Если же sysfs смонтирован, но ошибка остаётся, проверьте права доступа и не находитесь ли вы в контейнере с урезанным представлением /sys.
- 🔍 Проверьте, существует ли сам каталог
/sysи есть ли в нём подкаталогиblock,dev,devices - 📋 Сравните вывод
cat /proc/partitions— если там диски видны, ядро их обнаружило, и проблема точно в sysfs - 🧪 Команда
findmnt /sysпокажет, смонтирована ли sysfs и с какими опциями
Решение для chroot-окружения
Чтобы lsblk и другие утилиты (например, grub-install, blkid) работали внутри chroot, нужно перед входом в него примонтировать виртуальные файловые системы с хоста. Стандартный приём — bind-монтирование: содержимое /sys хоста станет видимым внутри изолированного окружения.
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /dev /mnt/dev
mount --bind /run /mnt/run
chroot /mnt /bin/bash
После этого внутри chroot команда lsblk должна отработать без ошибок. Порядок важен: сначала монтируются виртуальные ФС, потом выполняется вход в окружение. Если вы уже находитесь внутри chroot и не можете выйти, иногда помогает прямое монтирование: mount -t sysfs sysfs /sys — но это сработает только при наличии нужных привилегий (CAP_SYS_ADMIN).
⚠️ Внимание: после завершения работы в chroot отмонтируйте привязанные каталоги в обратном порядке (umount /mnt/sys и т.д.) до перезагрузки. Иначе возможны ошибки при выключении или повреждение данных на ещё смонтированных разделах.
☑️ Подготовка chroot для восстановления системы
Ошибка внутри контейнера Docker или LXC
В контейнерах ситуация принципиально иная: sysfs там либо смонтирована в режиме read-only с ограниченным набором записей, либо видимость устройств намеренно сокращена ради изоляции. Это не поломка, а архитектурное ограничение. Утилита lsblk внутри обычного контейнера может выдавать ошибку доступа или показывать неполный список — и «чинить» это монтированием полной sysfs обычно не нужно.
Если вам действительно требуется информация о блочных устройствах хоста, правильнее выполнить lsblk на самом хосте, а не внутри контейнера. Запуск контейнера в привилегированном режиме (--privileged) или с пробросом /sys снижает изоляцию и применяется только в осознанных случаях — например, для системных утилит мониторинга.
⚠️ Внимание: не запускайте контейнеры с флагом --privileged только ради работы lsblk. Это даёт процессу внутри контейнера широкий доступ к устройствам хоста и существенно ослабляет изоляцию. Используйте такой режим только при понимании рисков.
Почему в контейнере /sys/dev/block выглядит иначе
Ядро одно на всех — и хост, и контейнеры используют общее ядро Linux. Но пространства имён (namespaces) и cgroup ограничивают, какие устройства видны конкретному контейнеру. Поэтому полное содержимое sysfs хоста внутри контейнера недоступно, и это сделано намеренно для безопасности.
Альтернативные способы получить информацию о дисках
Если sysfs недоступна и смонтировать её нельзя, данные о блочных устройствах всё равно можно получить обходными путями. Часть информации ядро дублирует через procfs, которая монтируется независимо.
| Команда | Что показывает | Требует sysfs |
|---|---|---|
cat /proc/partitions | Список разделов с номерами major:minor и размером в блоках | Нет |
fdisk -l | Таблицы разделов дисков (читает сами устройства) | Нет |
blkid | UUID и типы файловых систем | Частично |
ls /dev/sd* /dev/nvme* | Файлы устройств, созданные в /dev | Нет |
lsblk | Дерево блочных устройств с точками монтирования | Да |
Заметьте: fdisk -l читает таблицы разделов напрямую с устройств, поэтому работает даже в минимальных средах. Однако без sysfs вы не увидите удобного дерева «диск → раздел → точка монтирования», которое даёт lsblk, — придётся сопоставлять устройства вручную.
Ошибка в обычной установленной системе
Редкий, но возможный случай — ошибка появляется в штатно загруженной системе. Это указывает на сбой в процессе инициализации: sysfs должна монтироваться автоматически системой инициализации (systemd делает это на раннем этапе загрузки). Если /sys пуст в нормально загруженной системе, проверьте вывод systemctl status sys-fs... — точнее, журнал: journalctl -b | grep -i sysfs.
Возможные причины — повреждённая конфигурация, ручные правки в юнитах монтирования или загрузка с нестандартными параметрами ядра. Как временная мера можно вручную выполнить mount -t sysfs sysfs /sys от root, но затем стоит разобраться, почему автоматическое монтирование не сработало.
⚠️ Внимание: если /sys не монтируется даже вручную и команда возвращает ошибку, возможно повреждение корневой файловой системы или проблемы с ядром. В таком случае загрузитесь с LiveUSB и проверьте ФС штатными средствами (например, fsck — только на размонтированном разделе).
Профилактика: как не столкнуться с ошибкой снова
Большинство случаев связано с восстановительными работами, поэтому главная профилактика — выработать привычку всегда монтировать /sys, /proc, /dev и /run перед chroot. Многие руководства по восстановлению GRUB упоминают это, но шаг легко пропустить, особенно когда спешишь.
Для частых операций удобно оформить монтирование в виде небольшого скрипта или использовать инструменты, которые делают это автоматически — например, arch-chroot в Arch Linux сам привязывает нужные виртуальные ФС. Аналогичные обёртки существуют и в других дистрибутивах; уточните наличие такой утилиты в документации вашей системы.
Часто задаваемые вопросы
Ошибка lsblk означает, что мой диск сломан?
Нет. Ошибка говорит лишь о том, что утилита не может прочитать каталог /sys/dev/block. В подавляющем большинстве случаев причина — непримонтированная sysfs в chroot, контейнере или аварийной среде. Проверить, видит ли ядро диски, можно командой cat /proc/partitions.
Как исправить ошибку внутри chroot, если я уже вошёл в него?
Попробуйте выполнить mount -t sysfs sysfs /sys и mount -t proc proc /proc внутри chroot. Если недостаточно привилегий — выйдите (exit), примонтируйте каталоги с хоста через mount --bind и войдите снова.
Почему lsblk не работает в Docker-контейнере?
Контейнеры используют общее ядро с хостом, но видимость устройств ограничена механизмами изоляции. Sysfs внутри контейнера либо урезана, либо смонтирована в режиме только для чтения с неполным набором записей. Для получения данных о дисках выполняйте lsblk на хосте.
Чем заменить lsblk, если sysfs недоступна?
Используйте cat /proc/partitions для списка разделов, fdisk -l для таблиц разделов и blkid для UUID файловых систем. Эти утилиты читают данные напрямую с устройств или из procfs и не зависят от sysfs.
Нужно ли отмонтировать /sys после выхода из chroot?
Да. Выполните umount /mnt/sys (и аналогично для /proc, /dev, /run) до перезагрузки или отключения диска. Это гарантирует корректное завершение работы с файловыми системами.