Yeni bir şirket bilgisayarında başlangıç ​​sırasında kilitlenme

Son güncellemelerden sonra bilgisayarım artık önyükleme yapmıyor! İşte belirleyebileceğim şey:

• Bu bana kurumsal BT tarafından sağlanan çok yeni bir bilgisayar. Yeni bir Intel CPU'ya (Skylake nesil) sahiptir.
• Bilgisayar Ubuntu 16.04'ü çalıştırıyor.
• Bilgisayar en son Mart ayında bir süre doğru açıldı. Sorun muhtemelen bir yazılım güncellemesi veya bir donanım hatası nedeniyledir.
• Neredeyse aynı yazılımı yüklü 16.04 çalışan başka bir bilgisayarım var (kullandım apt-clone) ve gayet iyi çalışıyor. Farklı donanımlara sahiptir (ayrıca amd64, ancak farklı CPU, farklı GPU, vb.).
• Çekirdek başlıyor, initrd düzgün çalışıyor. Grafik modunda açılış ekranını açtığımda, dm-crypt birimimin parolasını girmem isteniyor ve en son gördüğüm şey başarılı bir şekilde monte edilmiş olmasıdır.
• Bir oturum açma istemi gelmeden önce kilitlenme gerçekleşir. Bilgisayar kilitlendiğinde, zor bir askıda kalıyor. Alt+ Bile SysRqcevap vermiyor. Fanlar tam patlamada açıldığı için CPU% 100 oranında belirgin bir şekilde sabitlenmiş durumda.
• Hala yeniden başlatmadan önce çalıştırdığım çekirdeğim var. Grub menüsünde bu çekirdeği seçtiğimde aynı kilitlenmeye sahibim. Öyleyse bu, başka bir şeyin tetiklediği önceden var olan bir çekirdek böceği gibi görünüyor - ama ne?
• Açılış ekranını kapatırsam ( Grub'taki komut satırından kaldır) splash, başladığım linuxbir takım hizmetler görüyorum, sonra kilitleniyor.

• Ben ekleyerek bir kök kabuğu alabilirsiniz init=/bin/shetmek linuxGrub komut satırı. Ekleyerek daha da ilerleyebilirim

  systemd.unit=basic.target systemd.shell
  

  Bu, birkaç servis başlatır ve tty9'da bir kök kabuğu çalıştırır.

• Bu systemctl start multi-user.targetkök kabuğundan kaçarsam, bilgisayar kilitlenir. Bu yüzden muhtemelen sorun bu hizmetlerden biri tarafından tetiklenir.
• systemctl list-dependencies multi-user.targetHangi servislerin başladığını görmek için koştum . Listelenen bağımlılıkları tek tek el ile başlattım ve her şey yolunda gitti.

Bu, bazı yazılımlar tarafından tetiklenen (bir bilgisayarda, diğerinde değil, bir bilgisayarda meydana geldiği için) bu bir donanım hatası gibi görünüyor. Ama hangi yazılım? Bilgisayar çok sıkı kilitlendiğinden, herhangi bir günlük alamıyorum. Kullanışlı bir konsol çıktısı bile alamıyorum.

Yararlı hata ayıklama teknikleri:

• Alt+ SysRq: Acil durum yeniden başlatması gibi şeyleri yapmanızı sağlayan sihirli SysRq tuşu . Çekirdeğe çok düşük bir seviyede erişir, bu yüzden en kötü kazalar dışında çalışır. Benim durumumda Alt+ SysRqcevap vermiyor, bu da kazanın ne kadar derin gittiğini gösteriyor.
• Önyükleme parametrelerini değiştirmek için Shift, gücü açtıktan sonra birkaç saniye basılı tutun . BIOS klavyeyi başlattıktan sonra, ancak işletim sistemi önyüklemeden önce basmanız gerekir. Bu, Grub menüsünün görünmesini sağlar.
• Grub menüsünde, ebir menü girişi için komut satırını düzenlemek için basın . Linux önyükleme parametrelerini değiştirmek için ile başlayan satıra gidin linux. Modern bir Ubuntu'da, “Ubuntu için gelişmiş seçenekler” altında eski çekirdekleri bulacaksınız. İstediğiniz değişiklikleri komut satırında yaptıktan sonra önyüklemek için Ctrl+ tuşuna basın x. Burada yaptığınız herhangi bir değişiklik yalnızca bu önyükleme içindir, diske kaydedilmez.
• linuxKomut satırında bazı yararlı seçenekler :
  • quiet nosplashhemen hemen tüm önyükleme iletilerini gizler. Başlatma sırasında herhangi bir sorun teşhis etme şansına sahip olmak için gerekli olan mesajları konsolda almak için bunları kaldırın.
  • recoverysize hemen hemen hiçbir hizmeti olmayan bir kök kabuğu verir. Kök şifresini bilmeniz gerekir. “Kurtarma modu” menü girişi bunu kullanır.
  • init=/bin/shsize hiçbir hizmeti olmayan bir kök kabuğu verir. Normal önyüklemeye devam etmek için çalıştırın exec init. Bu noktada sistemd seçeneklerini geçebilirsiniz, örneğin exec init --unit=basic.targetinit ve birkaç servis başlatmak için (bunun giriş yapmak için herhangi bir yolla başlayamadığını unutmayın, bu nedenle başka bir konsolda çalışan bir kabuğun daha iyi olması gerekir). Kök dosya sisteminin salt okunur monte edildiğini unutmayın; mount -o remount,rw /ona yazabilmek için koş .
  • systemd.unit=basic.targetçok temel bir hizmet kümesi başlatır. Bunun giriş yapmanın bir yolunu içermediğine dikkat edin! Bunu systemctl set-default basic.targetbir kök komut isteminde çalıştırarak varsayılan yapabilirsiniz . Orijinal varsayılan hedefi geri yüklemek için, çalıştırın systemctl set-default graphical.target(veya systemctl set-default multi-user.targetGUI'siz bir sunucu için).
  • systemd.debug-shelltty9'da bir kök kabuğu başlatır. systemctl enable debug-shellKök isteminde çalıştırarak bunu her önyükleme için etkinleştirebilirsiniz . Sorunu çözdükten sonra bunu devre dışı bırakmayı unutmayın systemctl disable debug-shell. Tty9'a geçmek için Alt+ tuşuna basın F9.
  • Ayrıca bkz. Fedora sistem ipuçları , Arch Linux açılış problemi ipuçları .

Sorun

Sorunumun , en son Intel mikrokodu (bazıları?) Skylake CPU'ları ve en son sssd tarafından tetiklenen son Linux çekirdekleri arasında bilinen bir sorun olduğu ortaya çıktı . Bkz Ubuntu hata # 1759920 “(/ linux-image-4.13.0-37-jenerik w) giriş ekranında tutkuevi neden 3.20180312.0 intel-mikrokodları” aynı konuda olması, hem de söndürmeden diğer hataların sayısını örneğin, Ubuntu # 1746806 hatası gibi “sssd, AWS c5 ve m5 örneklerini çökertiyor,% 100 CPU'ya neden oluyor” ve Ubuntu # # 1746418 “linorg-image-4.13.0-32-generic uygulamasını yükledikten sonra Xorg'u başlatırken sistem donuyor” gibi . Aşağıdaki durumlarda bu hatayla karşılaşmanız olasıdır:

• Çok yeni bir Intel işlemciniz var. Söyleyebileceğim kadarıyla, bu hata sadece Skylake işlemcilerinde ortaya çıkıyor .
• Sen sahip istihbarat-Mikrokod paketi yüklü. Daha önce döndüğümde, test edilmiş çekirdek benim için işe yaramadı, çünkü ben bu çekirdeği daha önceki bir mikro kodla çalıştırdım.
• Bilgisayarınız, kullanıcı kimlik doğrulaması için bir şirket ağına (genellikle LDAP veya Active Directory) bağlı. Hatayı tetiklemenin başka yolları da olsa, sssd'yi çalıştırmak en yaygın suçlu gibi görünüyor. Ayrıca Xorg çökmesini de içeren haberler var .

Hata, Ocak 2018'de yayınlanan Spectre güvenlik sorununun azaltılmasından kaynaklanıyor. Bazı çekirdek kodları ile bazı durumlarda kilitlenmeye neden olan bazı işlemci mikro kodları arasında bir uyumsuzluk var .

Tamir nasıl

1. Normal önyükleme yapamıyorsanız, Grub isteminde çekirdek komut satırını düzenlemeniz gerekir. Açıklamalar ve bir kök kabuğu elde etmenin olası yolları için soruya bakın.
2. Bu özel hata için bir geçici çözüm olduğunu eklemek noibpbçekirdek komut satırına parametreyi ( 1746418/14 , 1759920/56 ). Bu normal önyüklemenizi ve bazı onarımlar yapmanızı sağlar.
   Bu, soruna neden olan güvenlik açığı azaltma işlevini devre dışı bırakır; bu, bilgisayarınızın artık bazı saldırılara karşı savunmasız olduğu anlamına gelir. Bunlar yerel saldırılar, yani saldırganın makinenizde kod çalıştırması gerekiyor, ancak bu saldırılar potansiyel olarak örneğin bir web tarayıcısındaki JavaScript aracılığıyla gerçekleştirilebilir.
   Başka bir noibpbyolunuz yoksa, sabit bir çekirdek elde edene kadar çekirdek komut satırına ekleyerek bunu kalıcı yapabilirsiniz.
3. Ubuntu’da, düzeltmenin 23.04.1988 tarihinde, muhtemelen 4.4.0-117 ve 4.13.0-39 çekirdeği olacağı tahmin edilen hafta bekleniyor . Bu arada, Tyler Hicks 4.4 ve 4.13 için test taneleri yayımladı .

Sorunu nasıl teşhis ettim

Birkaç şey denedim (soruya bakın) ve hatanın ulaşma basic.targetile ulaşma arasında bir yerde tetiklendiğini belirledim multi-user.target. Bu yüzden varsayılan systemd hedefini basic.target( systemctl set-default basic.target) olarak ayarlarım ve debug-shellservisi ( systemctl enable debug-shell) kök kabuğuna getirdim .

systemctl list-dependencies multi-user.targetListelenen bağımlılıkları tek tek koştum ve elle başlattım. Bu kazayı tetiklemedi.

Tüm hizmetler doğrudan yönetilen systemd . Bazıları Upstart hizmetleri olarak, bazıları SysVinit betiği olarak yönetilir . Aşağıdaki kabuk betiği hepsini çalıştırır. Not: Sadece bir kez test ettim ve tasarımdan düştü.

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

Bilgisayarım başlattıktan sonra çöktü sssd. Oradan, “sssd linux çekirdek asmak” üzerine yapılan bir web araştırması beni https://bugs.launchpad.net/cloud-images/+bug/1746806 ve tanı ve çözüme götürdü .