Как разобрать отказ systemd-binfmt в WSL с Read-only file system, отделив состояние сервиса, включение systemd и свойства монтирования без принудительной перемонтировки.
Не лечите сообщение принудительной записью
Read-only file system описывает результат операции записи, но строка одного сервиса не показывает, почему файловая точка оказалась недоступной. Не применяйте принудительное перемонтирование, не удаляйте файлы binfmt и не запускайте сервис от другого пользователя. Сначала сохраните полное имя unit, его состояние, время события и несколько строк журнала до и после ошибки. Удалите из фрагмента имена пользователей, нестандартные пути и команды. Затем проверьте, загружается ли дистрибутив, работает ли оболочка и есть ли аналогичные ошибки у других units. Если среда в целом доступна, формулируйте проблему узко как отказ systemd-binfmt, а не как повреждение всей файловой системы.
Уровень первый: включение systemd в дистрибутиве
Microsoft документирует включение systemd в конфигурации конкретного дистрибутива и необходимость завершить WSL, чтобы изменение вступило в силу. Для диагностики достаточно прочитать текущее значение и подтвердить, что процесс systemd действительно является менеджером системы. Не редактируйте файл только ради проверки и не переносите настройки из другого дистрибутива. Если systemd не включён, сообщение нужно сопоставить с фактическим способом запуска, а не предполагать штатную unit-последовательность. Если включён, переходите к статусу именно systemd-binfmt. Глобальный .wslconfig и конфигурация внутри дистрибутива имеют разную область действия; не смешивайте их в одном выводе.
Уровни два и три: unit и точка записи
Сохраните статус unit, код завершения и журнал текущей загрузки, затем определите, к какому пути относится операция из сообщения. Просмотр свойств монтирования должен оставаться только чтением; не пытайтесь сделать путь доступным для записи в рамках первичного теста. Сравните с одним соседним сервисом, который использует системные каталоги, но не создавайте файлы в защищённых местах. Если ошибка ограничена systemd-binfmt, это одна граница эскалации. Если многие службы одновременно сообщают о read-only, зафиксируйте более широкий симптом и остановитесь. Ни один из этих результатов сам по себе не доказывает повреждение диска или неверную глобальную настройку Windows.
Безопасный отчёт и критерий остановки
Пакет для поддержки должен содержать версии Windows и WSL, имя и версию дистрибутива, текущее состояние systemd, статус systemd-binfmt, обезличенный путь из ошибки и свойства соответствующего монтирования. Добавьте, затронут ли один unit или несколько. Не прикладывайте весь журнал загрузки, содержимое домашнего каталога или виртуальный диск. Остановитесь до шагов, которые меняют права, опции монтирования, системные файлы или глобальную конфигурацию: сначала владельцам WSL и дистрибутива нужен наблюдаемый контекст. После сбора можно один раз штатно завершить и запустить WSL, но результат следует записать как смену состояния, а не как доказанное устранение причины.
Материал подготовлен редакцией VOne с применением ИИ для трёхуровневой диагностики; границы systemd и конфигурации вручную сверены по Microsoft Learn, issue использован только как сигнал.
Источники и проверка
- Microsoft Learn — Use systemd to manage Linux services with WSL проверено 2026-08-07
- Microsoft Learn — Advanced settings configuration in WSL проверено 2026-08-07
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.