Збій під час запуску на недавньому корпоративному комп'ютері

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

• Це зовсім недавній комп’ютер, який мені надали корпоративні ІТ. Він має недавній процесор 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надає кореневу оболонку майже без послуг. Вам потрібно буде знати корінний пароль. Для цього використовується запис меню «Режим відновлення».
  • init=/bin/shдає вам кореневу оболонку, яка взагалі не має служб. Щоб відновити нормальне завантаження, запустіть exec init. У цей момент ви можете передавати системні параметри, наприклад, 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в кореневій запиті. Не забудьте вимкнути це після вирішення проблеми 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. Тому я встановив цільову системну ціль на 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. Звідти веб-пошук на "sssd linux ядро ​​висіло" привів мене до https://bugs.launchpad.net/cloud-images/+bug/1746806 та до діагностики та рішення.