Вопрос или проблема
Моя текущая проблема
После клонирования корневой файловой системы моей системы Debian на SSD (cp -ax) я больше не вижу вывод своих скриптов rc во время загрузки с SSD. Я вижу их во время завершения работы или когда запускаю скрипты rc вручную. Я также вижу их, когда загружаюсь в уровень выполнения 1, вхожу как root, а затем выхожу. Ядро — 3.8.2, скомпилированное мной.
Когда система загружается, я вижу сообщения ядра (которые похожи на то, что показывает dmesg), затем еще некоторое время нет сообщений, пока я не увижу приглашение для входа или экранный менеджер входа. Некоторые из сообщений ядра действительно исходят от скриптов rc, но я вижу только сообщения ядра, а не вывод скриптов rc, таких как [ ok ] starting foo сами по себе. Кроме этого, система работает нормально.
Я попытался загрузить стандартное ядро Debian (3.2.0-4-486), которое находится на другом разделе (/dev/sda3), и передать ему мой корень (/dev/sda1), чтобы он брал мои скрипты rc. В этом случае я вижу сообщения.
В интернете я нашел несколько сообщений о точно такой же проблеме. Но либо не было предложено решения, либо решение заключалось в “переустановке”.
Возможно, связанная проблема заключается в том, что я больше не могу загрузиться в однопользовательском режиме (уровень выполнения 1 работает). Он загружается сразу в initdefault (=3). Я подозреваю, что консоли не хватает, sulogin терпит неудачу, и процесс загрузки продолжается так, как будто я вышел из sulogin. Я также не могу загрузиться в оболочку (sash). Я вижу приветственное сообщение от sash, но он не общается со мной (нет приглашения).
Мои текущие теории блуждают вокруг
- Пропустил ли
cp -axчто-то (например, /dev)? - Вызывает ли быстрый диск проблему синхронизации?
- Или это что-то совершенно тривиальное, и я просто не вижу этого?
Редактировать 4 мая
Я наконец понял, что /dev/console должен присутствовать с самого начала. Так что я создал его, используя mknod, и теперь я снова вижу сообщения от скриптов rc. В то время как /dev/console создается заранее с помощью udev, это, похоже, не исправляет ситуацию во время загрузки. Так что моя первоначальная проблема решена. Тем не менее, мне хотелось бы знать
-
почему загрузка другого ядра исправляет проблему. /dev/console присутствует на /dev/sda3 (расположение другого ядра) до того, как запустится udev. Это наблюдение заставило меня создать /dev/console в первую очередь. Но я не понимаю, почему ядро принимает этот /dev, даже несмотря на то, что я передал ему другой корень.
-
откуда берется /dev во время загрузки
-
почему /dev/console, созданный udev, недостаточно хорош
-
какие другие узлы /dev нужны
-
почему загрузка в init=/bin/sash все еще не работает
У меня была похожая проблема с моим FreeBSD livecd – на некоторых ПК не было вывода скриптов rc.
Проблема была связана с опцией ядра “dcons_crom”, которая была присутствовала в конфигурации ядра. Когда эта опция включена, вывод с консоли перенаправляется на порт FireWire, если он присутствует. Когда я убрал эту опцию из конфигурации ядра, проблема исчезла.
Возможно, ваша проблема имеет тот же источник.
Ответ или решение
Ответ на вопрос: Почему я больше не вижу вывод rc-скриптов при загрузке?
Проблема
Вы описали удивительную ситуацию: после клонирования корневой файловой системы вашего Debian на SSD и загрузки с него, вы перестали видеть вывод ваших rc-скриптов во время загрузки. Этот вывод обычно включает сообщения об успешном старте сервисов, такие как [ ok ] starting foo. Вместо этого у вас отображаются только сообщения ядра, а затем появляется приглашение для входа. Вы также отметили, что при загрузке с другого ядра этот вывод появляется, а также, что не можете войти в однопользовательский режим.
Возможные причины проблемы
На основе вашего описания можно выделить несколько возможных причин:
-
Отсутствие /dev/console: Как вы сами заметили, ключевым элементом является присутствие узла устройства
/dev/console. Этот файл необходим для корректного отображения сообщений на консоли. При клонировании файловой системы с использованиемcp -axвозможно, что узел/dev/consoleне был создан, так как/devуправляется системойudev, которая не создала необходимое устройство на ранних этапах загрузки. -
Скорость загрузки с SSD: Не исключено, что более высокая скорость чтения с SSD могла вызвать проблемы с таймингом в процессе инициализации. Некоторые скрипты могут ожидать наличия определенных устройств в
/dev, прежде чем продолжить свою работу. -
Отличия в конфигурации ядра: Вы упомянули, что при загрузке с другого ядра вывод сообщений появляется. Это может свидетельствовать о различиях в конфигурации ядра, которые могут влиять на то, как обрабатываются устройства в
/dev. Возможно, в конфигурации вашего собственного ядра есть параметры, которые запрещают вывод на консоль или перенаправляют его.
Ответы на ваши вопросы
-
Почему загрузка другого ядра исправляет проблему?
При загрузке с другого ядра,/dev/consoleможет быть доступен до того, какudevуспевает его создать. Ядро обрабатывает все исходные устройства и инициализирует необходимые устройства, включая/dev/console, что может объяснять наличие вывода. -
Откуда берется /dev во время загрузки?
Обычно/devсоздается и управляетсяudev, который динамически создает устройства при инициализации системы. На ранней стадии загрузки могут быть использованы статические файлы, если они присутствуют, однако, как вы заметили, если эти файлы отсутствуют, например, из-за клонирования, могут возникнуть проблемы. -
Почему /dev/console от udev не подходит?
Если/dev/consoleсоздается позже в процессе загрузки, то когда скрипты запускаются в самом начале, он может еще не быть доступен, что и приводит к отсутствию вывода сообщений. Настройка времени инициализации устройств может оказать влияние на это, в особенности при использовании различных конфигураций ядра. -
Какие другие устройства в /dev могут понадобиться?
Важно удостовериться, что также присутствуют другие стандартные устройства:/dev/null,/dev/zero, и/dev/tty. Эти устройства могут быть необходимы для работы различных частей системы во время загрузки. -
Почему загрузка в init=/bin/sash не работает?
Это может быть связано с тем, чтоsashсам требует наличия консольного устройства для взаимодействия с пользователем. Если/dev/consoleне было создано или доступно в момент загрузки,sashне сможет правильно инициализироваться и отобразить приглашение.
Заключение
Ваша проблема, безусловно, связана с управлением устройствами в процессе загрузки и отсутствием необходимых файлов в /dev. Создание узла /dev/console вручную решило вашу проблему, но важно обеспечить, чтобы при клонировании файловой системы не возникало подобных ситуаций. Убедитесь, что система корректно инициализирует все необходимые устройства, а также рассмотреть возможность использования других методов резервного копирования, таких как rsync, чтобы избежать потери критических узлов.