最近の企業コンピューターでの起動中のクラッシュ

最近の更新の後、コンピューターが起動しなくなりました！ここに私が決定できるものがあります：

• これは、企業ITから提供されたごく最近のコンピューターです。最新のIntel CPU（Skylake世代）が搭載されています。
• コンピューターはUbuntu 16.04を実行します。
• コンピューターは3月に最後に正しく起動しました。この問題は、おそらくソフトウェアの更新またはハードウェアのバグが原因です。
• 16.04を実行している別のコンピューターで、ほとんど同じソフトウェアがインストールされています（使用しましたapt-clone）が、正常に動作します。異なるハードウェア（amd64ですが、異なるCPU、異なるGPUなど）があります。
• カーネルは起動し、initrdは正しく動作します。グラフィックモードでスプラッシュスクリーンで起動すると、dm-cryptボリュームのパスワードの入力を求められますが、最後に表示されるのは、正常にマウントされたことです。
• ログインプロンプトが表示される前にハングします。コンピューターがハングすると、ハードハングになります。Alt+ でもSysRq応答しません。ファンが完全にオンになるので、CPUは明らかに100％に固定されています。
• 再起動する前に実行していたカーネルがまだあります。Grubメニューでこのカーネルを選択すると、同じロックアップが得られます。したがって、これは既存のカーネルバグであり、他の何かによってトリガーされるように見えますが、それは何ですか？
• スプラッシュスクリーンをオフにすると（Grub splashのlinuxコマンドラインから削除）、多数のサービスが開始され、ロックされます。

• Grubのコマンドラインに追加init=/bin/shすることで、ルートシェルを取得できますlinux。さらに追加することでさらに取得できます

  systemd.unit=basic.target systemd.shell
  

  これにより、多数のサービスが開始され、tty9でルートシェルが実行されます。

• systemctl start multi-user.targetそのルートシェルから実行すると、コンピューターがロックします。したがって、これらのサービスのいずれかによって問題が引き起こされていると考えられます。
• systemctl list-dependencies multi-user.targetどのサービスが開始されるかを確認するために走りました。リストされた依存関係を1つずつ手動で開始し、すべてが正常に開始されました。

そのため、これはハードウェアのバグのように見えます（1台のコンピューターでは発生しますが、他のコンピューターでは発生しないため）。一部のソフトウェアによってトリガーされます。しかし、どのソフトウェアですか？コンピューターが非常に激しくロックするため、ログを取得できません。有用なコンソール出力も取得できません。

便利なデバッグ手法：

• 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ます。この時点で、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.targetGUIのない​​サーバーの場合）。
  • systemd.debug-shelltty9でルートシェルを開始します。systemctl enable debug-shellルートプロンプトで実行することにより、ブートごとにこれを有効にできます。で問題を解決した後、これを無効にすることを忘れないでくださいsystemctl disable debug-shell。Alt+ F9を押してtty9に切り替えます。
  • Fedora systemdのヒント、Arch Linuxブート問題のヒントも参照してください。

問題

私の問題は、主にsssdによってトリガーされる（いくつかの？）Skylake CPU上の最新のIntelマイクロコードと最近のLinuxカーネル間の既知の問題であることがわかりました。参照してくださいUbuntuのバグ＃1759920「ログイン画面でロックアップの原因となる3.20180312.0インテルのマイクロコード（のlinux-画像4.13.0-37汎用/ W）」を、また、同じ問題についてであることが判明し、他のバグの数、Ubuntuバグ＃1746806「sssdはAWS c5およびm5インスタンスをクラッシュさせるため、CPUが100％になります」およびUbuntuバグ＃1746418「linux-image-4.13.0-32-genericをインストールした後にXorgを起動するとシステムがフリーズします」次の場合、このバグが発生する可能性があります。

• 最新のIntel CPUを使用しています。私が知る限り、このバグはSkylake CPUでのみ発生します。
• あなたは持っているインテルのマイクロコードのパッケージがインストールされています。以前のマイクロコードでカーネルを実行するだけだったので、以前のテスト済みカーネルに戻すことは、私にとってはうまくいきませんでした。
• コンピューターは、ユーザー認証のために企業ネットワーク（通常はLDAPまたはActive Directory）に接続されています。バグを引き起こす他の方法がありますが、sssdの実行が最も一般的な犯人のようです。Xorgがクラッシュするという報告もあります。

このバグは、2018年1月に公開されたSpecterセキュリティ問題の緩和によるものです。特定の状況でロックアップを引き起こす一部のカーネルコードと一部のプロセッサマイクロコード間に非互換性があります。

修理方法

1. 正常に起動できない場合は、Grubプロンプトでカーネルコマンドラインを編集する必要があります。説明およびルートシェルを取得する方法については、質問を参照してください。
2. この特定のバグの回避策は、noibpbパラメータをカーネルコマンドライン（1746418 / 14、1759920/56）に追加することです。これにより、正常に起動し、いくつかの修復を実行できます。
   これにより、問題の原因となる脆弱性の軽減が無効になり、コンピューターが一部の攻撃に対して脆弱になります。これらはローカル攻撃です。つまり、攻撃者はマシンでコードを実行する必要がありますが、これらの攻撃はWebブラウザのJavaScriptなどを介して実行される可能性があります。
   他に方法がない場合はnoibpb、固定カーネルを取得できるまでカーネルコマンドラインに追加することで、これを永続的にすることができます。
3. Ubuntuでは、2018年4月23日の週に、おそらくカーネル4.4.0-117および4.13.0-39に修正される予定です。それまでの間、Tyler Hicksは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リストされた依存関係を1つずつ実行し、手動で開始しました。これはクラッシュを引き起こしませんでした。

すべてのサービスがsystemdによって直接管理されるわけではありません。一部はUpstartサービスとして管理され、一部はSysVinitスクリプトとして管理されます。以下のシェルスクリプトは、それらすべてを実行します。注：テストは1回のみで、設計によりクラッシュしました。

#!/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 kernel hang」に関するWeb検索により、https： //bugs.launchpad.net/cloud-images/+bug/1746806 と診断および解決策に導かれました。