Сбой во время запуска на недавнем корпоративном компьютере

После некоторых последних обновлений мой компьютер больше не загружается! Вот что я мог определить:

• Это очень недавний компьютер, предоставленный мне корпоративными ИТ. Он имеет новейший процессор Intel (поколение Skylake).
• На компьютере работает Ubuntu 16.04.
• Последний раз компьютер загружался правильно в марте. Вероятно, проблема связана с обновлением программного обеспечения или аппаратной ошибкой.
• У меня есть другой компьютер под управлением 16.04 с почти таким же установленным программным обеспечением (я использовал apt-clone), и он работает просто отлично. У него другое оборудование (также amd64, но другой процессор, другой графический процессор и т. Д.).
• Ядро запускается, initrd работает правильно. Когда я загружаюсь с заставкой в ​​графическом режиме, меня просят ввести пароль для моего тома dm-crypt, и последнее, что я вижу, это то, что он успешно смонтирован.
• Зависание происходит до того, как я получаю приглашение для входа в систему. Когда компьютер зависает, это трудно повесить. Даже Alt+ SysRqне отвечает. Процессор явно привязан на 100%, так как вентиляторы включаются на полную мощность.
• У меня все еще есть ядро, которое я запускал до перезагрузки. Когда я выбираю это ядро ​​в меню Grub, я получаю такую ​​же блокировку. Похоже, что это уже существующая ошибка в ядре, которая вызывается чем-то другим - но что?
• Если я отключаю заставку (удаляю splashиз linuxкомандной строки в Grub), я вижу, что запускается несколько служб, затем он блокируется.

• Я могу получить корневую оболочку, добавив init=/bin/shв linuxкомандную строку в Grub. Я могу даже пойти дальше, добавив

  systemd.unit=basic.target systemd.shell
  

  Это запускает ряд служб и запускает корневую оболочку на tty9.

• Если я запускаю systemctl start multi-user.targetиз этой корневой оболочки, компьютер зависает. Вероятно, проблема вызвана одной из этих служб.
• Я побежал, systemctl list-dependencies multi-user.targetчтобы посмотреть, какие услуги начинаются. Я вручную запустил перечисленные зависимости по очереди, и все началось просто отлично.

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

Полезные методы отладки:

• Alt+ SysRq: магический ключ SysRq , позволяющий выполнять такие действия, как экстренная перезагрузка. Он обращается к ядру на очень низком уровне, поэтому он работает во всех случаях, кроме худших сбоев. В моем случае Alt+ SysRqне отвечает, что показывает, насколько глубоко происходит сбой.
• Чтобы изменить параметры загрузки, нажмите и удерживайте Shiftнесколько секунд после включения питания. Вам нужно нажать ее после того, как BIOS инициализирует клавиатуру, но до загрузки операционной системы. Это заставляет меню Grub появляться.
• В меню Grub нажмите, eчтобы отредактировать командную строку для пункта меню. Чтобы изменить параметры загрузки Linux, перейдите к строке, начинающейся с linux. В современной Ubuntu вы найдете старые ядра в разделе «Дополнительные параметры для Ubuntu». После внесения необходимых изменений в командную строку нажмите Ctrl+ xдля загрузки. Любые изменения, которые вы делаете здесь, предназначены только для этой загрузки, они не сохраняются на диск.
• Некоторые полезные опции в linuxкомандной строке:
  • quiet nosplashскрывает почти все загрузочные сообщения. Удалите их, чтобы получать сообщения на консоли во время загрузки, что необходимо для возможности диагностики проблем.
  • recoveryдает вам корневую оболочку практически без служб. Вам нужно будет знать пароль пользователя root. Пункт меню «режим восстановления» использует это.
  • init=/bin/shдает вам корневую оболочку без каких-либо служб. Чтобы возобновить нормальную загрузку, запустите exec init. На этом этапе вы можете передать параметры systemd, например, exec init --unit=basic.targetзапустить init и несколько служб (обратите внимание, что это не запускает какой-либо способ входа в систему, поэтому лучше запустить оболочку на другой консоли). Обратите внимание, что корневая файловая система монтируется только для чтения; бежать, mount -o remount,rw /чтобы иметь возможность писать в него.
  • systemd.unit=basic.targetзапускает очень простой набор услуг. Обратите внимание, что это не включает в себя любой способ войти! Вы можете сделать это по умолчанию, запустив systemctl set-default basic.targetв корневом запросе. Чтобы восстановить исходную цель по умолчанию, запустите systemctl set-default graphical.target(или systemctl set-default multi-user.targetдля сервера без графического интерфейса).
  • systemd.debug-shellзапускает корневую оболочку на tty9. Вы можете включить это для каждой загрузки, запустив systemctl enable debug-shellв приглашении root. Не забудьте отключить это после того, как вы решили проблему с systemctl disable debug-shell. Нажмите Alt+, F9чтобы переключиться на tty9.
  • Смотрите также Fedora Systemd советы , Arch Linux проблемы загрузки советы .

Проблема

Оказывается, моя проблема - известная проблема между последним микрокодом Intel на (некоторых?) Процессорах Skylake и последними ядрами Linux, который в основном вызывается sssd . См. Ошибку Ubuntu № 1759920 «intel-microcode 3.20180312.0 вызывает блокировку на экране входа в систему (w / linux-image-4.13.0-37-generic)» , а также ряд других ошибок, которые, как оказалось, связаны с той же проблемой. , например, ошибка Ubuntu № 1746806 «Похоже, что sssd вызывает сбой экземпляров AWS c5 и m5, вызывает 100% ЦП» и ошибка Ubuntu № 1746418 «Система зависает при запуске Xorg после установки linux-image-4.13.0-32-generic» . Вы, вероятно, столкнетесь с этой ошибкой, если:

• У вас совсем новый процессор Intel. Насколько я могу судить, эта ошибка возникает только на процессорах Skylake .
• У вас установлен пакет intel-microcode . Возвращение к более раннему, протестированному ядру не сработало для меня, потому что я запускал это ядро ​​только с более ранним микрокодом.
• Ваш компьютер подключен к корпоративной сети (обычно LDAP или Active Directory) для аутентификации пользователя. Хотя есть и другие способы вызвать ошибку, запуск sssd, похоже, является наиболее распространенной причиной. Есть также сообщения о сбое Xorg .

Эта ошибка связана с мерами по устранению проблемы безопасности Spectre, которая была опубликована в январе 2018 года. Существует некоторая несовместимость между некоторым кодом ядра и некоторым микрокодом процессора, который в определенных обстоятельствах вызывает блокировку.

Как починить

1. Если вы не можете нормально загрузиться, вам нужно отредактировать командную строку ядра в приглашении Grub. Смотрите вопрос с объяснениями и возможными способами получить корневую оболочку.
2. Обходной путь для этой конкретной ошибки - добавить noibpbпараметр в командную строку ядра ( 1746418/14 , 1759920/56 ). Это должно позволить вам нормально загрузиться и выполнить некоторые ремонтные работы.
   Это отключает устранение уязвимости, которая вызывает проблему, а это означает, что ваш компьютер теперь уязвим для некоторых атак. Это локальные атаки, то есть злоумышленнику необходимо выполнить код на вашем компьютере, но эти атаки потенциально могут быть выполнены, например, с помощью JavaScript в веб-браузере.
   Если у вас нет другого пути, вы можете сделать это постоянным, добавляя noibpbв командную строку ядра, пока не получите фиксированное ядро.
3. В Ubuntu исправление ожидается на неделе 23 апреля 2018 года , предположительно с ядром 4.4.0-117 и 4.13.0-39. Тем временем Тайлер Хикс опубликовал тестовые ядра для 4.4 и 4.13 .

Как я диагностировал проблему

Я попробовал несколько вещей (см. Вопрос) и решил, что ошибка была вызвана где-то между достижением basic.targetи достижением multi-user.target. Поэтому я установил целевой systemd по умолчанию basic.target( systemctl set-default basic.target) и включил debug-shellсервис ( systemctl enable debug-shell), чтобы получить корневую оболочку.

Я запустил systemctl list-dependencies multi-user.targetи вручную запустил перечисленные зависимости один за другим. Это не вызвало сбой.

Не все сервисы управляются напрямую с помощью systemd . Некоторые из них управляются как сервисы Upstart, а некоторые - как сценарии SysVinit . Скрипт оболочки ниже запускает их все. Примечание: я протестировал его только один раз, и он разбился по проекту.

#!/bin/sh
wants=$(systemctl show -p Wants multi-user.target | sed 's/^Wants=//' | tr ' ' '\n' | sort)
log=/var/tmp/multi-user-steps-$(date +%Y%m%d-%H%M%S)

log () {
  echo "$* ..." | tee -a "$log"
  sync
  "$@"
  ret=$?
  echo "$* -> $ret" | tee -a "$log"
  sync
  return $ret
}

# systemd services
for service in $wants; do
  log systemctl start $service
  sleep 2
done

# upstart services
for conf in /etc/init/*.conf; do
  service=${conf##*/}; service=${service%.conf}
  log service ${service} start
  sleep 2
done

# sysvinit services
for service in /etc/rc3.d/S*; do
  log ${service} start
  sleep 2
done

Мой компьютер упал после запуска sssd. Оттуда, веб-поиск по «зависанию ядра Linux Linux» привел меня к https://bugs.launchpad.net/cloud-images/+bug/1746806 и к диагностике и решению.