Выполняется начальное задание для eth0

lshw показывает ваш адаптер IDE -на -USB, а не ваш диск. Дисковые USB-устройства отображаются как SCSI-диски, обычно в разделе «Запоминающее устройство» — в основном, это USB-устройство в дереве lshwи SCSI-устройство, эмулируемое USB-адаптером (, что можно увидеть на длинная версия вашего вопроса :«возможности :usb -2.10 scsi эмулированный хост scsi -» ).

USB-адаптеры для хранения данных используют команды SCSI, поэтому устройства за USB-адаптерами гораздо проще обрабатывать как диски SCSI, а не то, чем они на самом деле являются.

Адаптер скрывает характер вашего диска. Поскольку вы подключили его к порту IDE (, предположительно 40 -контакт ), это IDE-диск, и его номер модели (ST9100822A )отображается в поставщике диска и идентификаторе продукта (. ST910082» и «2А» ).

2
05.03.2019, 08:30
3 ответа

Я бы сказал, что проблема, которую вы видите, связана с dhcpcd@eth0.service, настроенным в вашей системе. Поэтому я бы рекомендовал отключить его, надеюсь, этого достаточно, чтобы тайм-аут во время загрузки исчез:

$ sudo systemctl disable dhcpcd@eth0

Я рассмотрю доказательства, подтверждающие это утверждение. Здесь можно выполнить дополнительные действия по устранению неполадок, я предложу еще несколько шагов (на случай, если вы захотите продолжить поиск или устранить аналогичные проблемы в будущем.)

Основным свидетельством проблемы является сообщение на выходе systemctl status dhcpcd@eth0, в котором говорится:

Mar 05 09:42:42 brightprogrammer systemd[1]: dhcpcd@eth0.service: Job dhcpcd@eth0.service/start failed with result 'dependency'.

Сбой с результатом "зависимость" означает, что в данном случае он ожидал чего-то еще, что не удалось. Эта служба будет зависеть от eth0.device, и это устройство не появится, так что это вероятный источник тайм-аута. Вы можете взглянуть на systemctl status eth0.device, чтобы увидеть, появится ли что-нибудь еще, возможно, будет (, но возможно, что и не появится.)

Как вы упомянули в своем вопросе, вероятно, существует путаница между eth0и фактическим именем устройства enp1s0f1в вашей системе.systemd (более конкретно udevd )переименовывает сетевые интерфейсы, чтобы дать им согласованное имя, и это обычно происходит очень рано при загрузке (, иногда даже до запуска systemd ), поэтому systemd на самом деле не увидит eth0имя больше.

Если вы хотите включить DHCP на этом интерфейсе в будущем, вместо этого включите dhcpcd@enp1s0f1.

Выходные данные systemd-analyze critical-chainподтверждают гипотезу тайм-аута для этой службы dhcpcd@eth0, которую вы можете увидеть из этих двух шагов:

└─network.target @1min 33.501s    
  └─wpa_supplicant.service @15.761s +638ms 

Время после @— это время сразу после загрузки. Служба wpa_supplicantпоявилась через 13 с после запуска systemd, но network.targetбыла достигнута только через 1 мин 33 с (примерно за 90 с, о которых вы говорите.)

Вы, вероятно, увидели бы dhcpcd@eth0здесь более подробно, но устройство фактически перешло в состояние «загружено»/«неактивно», а не в состояние «сбой», поэтому, вероятно, оно не указано здесь (. ] и в systemd-analyze blame), что помогло бы указать на него как на виновника.

Наконец, один шаг, который обычно является отличным началом при устранении неполадок с загрузкой systemd, — это начать с просмотра пустых выходных данных systemctl status, которые сообщат вам, находится ли система в «деградированном» состоянии, что указывает на то, что что-то не удалось во время ботинок. Вы хотите убедиться, что состояние системы будет «работает», поэтому расследование этих сбоев обычно выявляет такие проблемы, как тайм-ауты и т. д.

Вы можете продолжить расследование с этой точки, просмотрев выходные данные systemctl, в которых будут перечислены все активные устройства и их статус. Если вы обнаружите там проблемы, посмотрите дальше, исследуя конкретные устройства (с помощью systemctl status <unit>или journalctl -u <unit>. )Команда systemctl --state=failedтакже полезна для отображения только неисправных устройств.

Наконец, проверка журнала действительно полезна для корреляции. Команда journalctl -bпоказывает журнал с момента загрузки системы, поэтому очень удобно отслеживать проблемы во время загрузки. Как упоминалось ранее,journalctl -u <unit>полезен для исследования журналов для одного устройства.

Надеемся, что эти советы помогут вам копнуть глубже и понять, что происходит в вашей системе. Также надеюсь, что отключения этого dhcpcd@eth0достаточно, чтобы решить задержку загрузки, с которой вы столкнулись.

3
27.01.2020, 22:02

Я наконец решил эту проблему, повторно -включив модуль systemd для указанного профиля (eth0 ).

netctl reenable eth0

Теперь 90-секундная загрузка сбрасывается после перезагрузки.

0
27.01.2020, 22:02

Проблема заключается в том, что вы еще не настроили сеть (, что типично после новой установки ), но система пытается запустить всю сеть. Пока сетевая конфигурация не будет правильно установлена, просто отключите зависимость пользовательских сессий systemd и сетевых демонов.

Из :/usr/lib/systemd/system/systemd -пользователь -session.service

Секция :[Блок]

Строка :После=....

удалить network.target , затем запустить демон systemctl -перезагрузить

0
27.01.2020, 22:02

Теги

Похожие вопросы