Awaria podczas uruchamiania na najnowszym komputerze korporacyjnym

Po kilku ostatnich aktualizacjach mój komputer nie uruchamia się! Oto, co mogłem ustalić:

• To jest najnowszy komputer, który dostałem od korporacyjnej informatyki. Ma najnowszy procesor Intel (generacja Skylake).
• Na komputerze działa Ubuntu 16.04.
• Komputer ostatnio uruchomił się poprawnie w marcu. Problem jest prawdopodobnie spowodowany aktualizacją oprogramowania lub błędem sprzętowym.
• Mam inny komputer z 16.04 z zainstalowanym prawie tym samym oprogramowaniem (używałem apt-clone) i działa dobrze. Ma inny sprzęt (także amd64, ale inny procesor, inny procesor graficzny itp.).
• Jądro się uruchamia, initrd działa poprawnie. Kiedy uruchamiam się z ekranem powitalnym w trybie graficznym, pojawia się monit o podanie hasła do mojego woluminu dm-crypt, a ostatnią rzeczą, jaką widzę, jest to, że został pomyślnie zainstalowany.
• Zawieszenie następuje przed wyświetleniem monitu o zalogowanie się. Gdy komputer się zawiesza, trudno się zawiesić. Nawet Alt+ SysRqnie odpowiada. Procesor jest najwyraźniej ustalony na 100%, ponieważ wentylatory włączają się przy pełnym wybuchu.
• Nadal mam jądro, które uruchomiłem przed ponownym uruchomieniem. Kiedy wybieram to jądro w menu Grub, otrzymuję to samo zawieszenie. Wygląda na to, że jest to wcześniejszy błąd jądra, który jest wywoływany przez coś innego - ale co?
• Jeśli wyłączę ekran powitalny (usuń splashz linuxwiersza poleceń w Grub), zobaczę kilka uruchomionych usług, a następnie się zablokuje.

• Mogę uzyskać powłokę root, dodając init=/bin/shdo linuxwiersza poleceń w Grub. Mogę nawet przejść dalej, dodając

  systemd.unit=basic.target systemd.shell
  

  Uruchamia to szereg usług i uruchamia powłokę root na tty9.

• Jeśli uruchomię systemctl start multi-user.targetz tej powłoki root, komputer się zablokuje. Prawdopodobnie problem jest wywoływany przez jedną z tych usług.
• Pobiegłem, systemctl list-dependencies multi-user.targetaby dowiedzieć się, jakie usługi się zaczną. Ręcznie uruchomiłem wymienione zależności jeden po drugim i wszystko zaczęło się dobrze.

Wygląda to na błąd sprzętowy (ponieważ występuje na jednym komputerze, ale nie na drugim), który jest wywoływany przez niektóre oprogramowanie. Ale jakie oprogramowanie? Ponieważ komputer blokuje się tak mocno, nie mogę uzyskać żadnych dzienników. Nie mogę nawet uzyskać żadnego przydatnego wyjścia konsoli.

Przydatne techniki debugowania:

• Alt+ SysRq: magiczny klucz SysRq , który pozwala wykonywać takie czynności, jak restart awaryjny. Uzyskuje dostęp do jądra na bardzo niskim poziomie, więc działa we wszystkich wypadkach oprócz najgorszych. W moim przypadku Alt+ SysRqnie odpowiada, co pokazuje, jak głęboko się pogarsza.
• Aby zmodyfikować parametry rozruchu, naciśnij i przytrzymaj Shiftkilka sekund po włączeniu zasilania. Musisz go nacisnąć po zainicjowaniu systemu BIOS przez klawiaturę, ale przed uruchomieniem systemu operacyjnego. To sprawia, że pojawia się menu Grub .
• W menu Grub naciśnij, eaby edytować wiersz polecenia dla pozycji menu. Aby zmienić parametry rozruchowe systemu Linux, przejdź do wiersza rozpoczynającego się od linux. W nowoczesnym Ubuntu znajdziesz stare jądra w „Zaawansowane opcje Ubuntu”. Po wprowadzeniu żądanych zmian w wierszu poleceń naciśnij Ctrl+, xaby uruchomić. Wszelkie wprowadzone tutaj zmiany dotyczą tylko rozruchu, nie są zapisywane na dysku.
• Kilka przydatnych opcji w linuxwierszu poleceń:
  • quiet nosplashukrywa prawie wszystkie komunikaty rozruchowe. Usuń je, aby otrzymywać komunikaty na konsoli podczas rozruchu, co jest konieczne, aby mieć szansę zdiagnozowania problemów.
  • recoverydaje powłokę root bez prawie żadnych usług. Musisz znać hasło roota. Wykorzystuje to pozycja menu „tryb odzyskiwania”.
  • init=/bin/shdaje powłokę główną bez żadnych usług. Aby wznowić normalny rozruch, uruchom exec init. W tym momencie możesz przekazać opcje systemowe, np. exec init --unit=basic.targetAby uruchomić init i kilka usług (pamiętaj, że to nie uruchamia się w żaden sposób, aby się zalogować, więc lepiej, aby powłoka działała na innej konsoli). Zauważ, że główny system plików jest zamontowany tylko do odczytu; biegnij, mount -o remount,rw /aby móc do niego napisać.
  • systemd.unit=basic.targeturuchamia bardzo podstawowy zestaw usług. Pamiętaj, że nie obejmuje to żadnego sposobu logowania! Możesz ustawić to jako domyślne, uruchamiając systemctl set-default basic.targetw oknie głównym. Aby przywrócić pierwotny domyślny cel, uruchom systemctl set-default graphical.target(lub systemctl set-default multi-user.targetdla serwera bez GUI).
  • systemd.debug-shelluruchamia powłokę root na tty9. Możesz włączyć to dla każdego rozruchu, uruchamiając systemctl enable debug-shellw wierszu głównym. Nie zapomnij wyłączyć tej opcji po rozwiązaniu problemu systemctl disable debug-shell. Naciśnij Alt+, F9aby przełączyć na tty9.
  • Zobacz także Fedory Systemd wskazówek , Arch Linux wskazówek problemu z rozruchem .

Problem

Okazuje się, że mój problem jest znanym problemem między najnowszym mikrokodem Intela na (niektórych?) Procesorach Skylake a najnowszymi jądrami Linuksa, który jest wywoływany głównie przez sssd . Zobacz błąd Ubuntu # 1759920 „intel-microcode 3.20180312.0 powoduje blokadę ekranu logowania (w / linux-image-4.13.0-37-generic)” , a także szereg innych błędów, które okazują się dotyczyć tego samego problemu , na przykład błąd Ubuntu # 1746806 „sssd wydaje się powodować awarie instancji AWS c5 i m5, powoduje 100% procesora” i błąd Ubuntu # 1746418 „System zawiesza się podczas uruchamiania Xorg po zainstalowaniu linux-image-4.13.0-32-generic” . Prawdopodobnie napotkasz ten błąd, jeśli:

• Masz najnowszy procesor Intel. O ile wiem, ten błąd pojawia się tylko na procesorach Skylake .
• Masz zainstalowany pakiet intel-microcode . Powrót do wcześniejszego przetestowanego jądra nie działał dla mnie, ponieważ uruchamiałbym to jądro tylko z wcześniejszym mikrokodem.
• Komputer jest podłączony do sieci firmowej (zazwyczaj LDAP lub Active Directory) w celu uwierzytelnienia użytkownika. Chociaż istnieją inne sposoby wywołania błędu, najczęstszym winowajcą wydaje się uruchomienie sssd . Istnieją również doniesienia o awarii Xorg .

Przyczyną błędu są luki w zabezpieczeniach Spectre, które zostały opublikowane w styczniu 2018 r. Istnieje pewna niezgodność między niektórymi kodami jądra a niektórymi mikrokodami procesorów, które w pewnych okolicznościach powodują blokowanie.

Jak naprawić

1. Jeśli nie możesz uruchomić się normalnie, musisz edytować wiersz poleceń jądra w wierszu polecenia Grub. Zobacz pytanie, aby uzyskać wyjaśnienia i możliwe sposoby uzyskania powłoki roota.
2. Obejściem tego konkretnego błędu jest dodanie noibpbparametru do wiersza poleceń jądra ( 1746418/14 , 1759920/56 ). Powinno to pozwolić na normalne uruchomienie komputera i wykonanie niektórych napraw.
   Wyłącza to ograniczenie podatności, które powoduje problem, co oznacza, że ​​komputer jest teraz podatny na niektóre ataki. Są to ataki lokalne, tzn. Osoba atakująca musi uruchomić kod na komputerze, ale te ataki mogą potencjalnie zostać przeprowadzone np. Przez JavaScript w przeglądarce internetowej.
   Jeśli nie masz innego sposobu, możesz uczynić to stałym, dodając noibpbdo wiersza poleceń jądra, aż uzyskasz stałe jądro.
3. W Ubuntu poprawka jest spodziewana w tygodniu 23 kwietnia 2018 r. , Prawdopodobnie w jądrze 4.4.0-117 i 4.13.0-39. W międzyczasie Tyler Hicks opublikował jądra testowe dla wersji 4.4 i 4.13 .

Jak zdiagnozowałem problem

Próbowałem kilku rzeczy (patrz pytanie) i ustaliłem, że błąd został wywołany gdzieś pomiędzy osiągnięciem basic.targeta osiągnięciem multi-user.target. Ustawiłem więc domyślny systemowy cel na basic.target( systemctl set-default basic.target) i włączyłem debug-shellservice ( systemctl enable debug-shell), aby uzyskać powłokę root.

Uruchomiłem systemctl list-dependencies multi-user.targeti ręcznie uruchomiłem wymienione zależności jeden po drugim. Nie spowodowało to awarii.

Nie wszystkie usługi są zarządzane bezpośrednio przez systemd . Niektóre są zarządzane jako usługi Upstart , a niektóre jako skrypty SysVinit . Poniższy skrypt powłoki uruchamia je wszystkie. Uwaga: przetestowałem go tylko raz i rozbił się pod względem projektu.

#!/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

Mój komputer zawiesił się po uruchomieniu sssd. Stamtąd wyszukiwanie w sieci „zawieszenie jądra systemu Linux sssd” doprowadziło mnie do https://bugs.launchpad.net/cloud-images/+bug/1746806 oraz do diagnozy i rozwiązania.