최근 회사 컴퓨터에서 시작하는 동안 충돌이 발생합니다

최근 업데이트 후 컴퓨터가 더 이상 부팅되지 않습니다! 내가 결정할 수있는 것은 다음과 같습니다.

• 이것은 회사 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서비스를 시작하는 것을 볼 수 있습니다. 나열된 종속성을 하나씩 수동으로 시작했으며 모든 것이 잘 시작되었습니다.

따라서 이것은 일부 소프트웨어에 의해 트리거되는 하드웨어 버그 (하나의 컴퓨터에서는 발생하지만 다른 컴퓨터에서는 발생하지 않기 때문에)처럼 보입니다. 그러나 어떤 소프트웨어? 컴퓨터가 너무 세게 잠기므로 로그를 얻을 수 없습니다. 유용한 콘솔 출력도 얻을 수 없습니다.

유용한 디버깅 기술 :

• Alt+ SysRq: magic SysRq key . 비상 재부팅과 같은 작업을 수행 할 수 있습니다. 커널은 매우 낮은 수준으로 커널에 액세스하므로 최악의 충돌을 제외하고는 모두 작동합니다. 제 경우에는 Alt+ SysRq가 응답하지 않아 충돌이 얼마나 깊이 진행되는지 보여줍니다.
• 부팅 매개 변수를 수정하려면 Shift전원을 켠 후 몇 초 동안 길게 누릅니다 . BIOS가 키보드를 초기화 한 후, 운영 체제를 부팅하기 전에이 키를 눌러야합니다. 이것은 만드는 삼류의 메뉴가 나타납니다.
• Grub 메뉴에서을 눌러 e메뉴 항목의 명령 줄을 편집합니다. Linux 부팅 매개 변수를 변경하려면로 시작하는 행으로 이동하십시오 linux. 현대 우분투에서는“우분투 고급 옵션”에 오래된 커널이 있습니다. 명령 행을 원하는대로 변경했으면 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.targetGUI가없는 서버)를 실행하십시오.
  • systemd.debug-shelltty9에서 루트 쉘을 시작합니다. systemctl enable debug-shell루트 프롬프트에서 실행 하여 모든 부팅에 대해이를 활성화 할 수 있습니다 . 의 문제를 해결 한 후에는이 기능을 비활성화하십시오 systemctl disable debug-shell. Alt+ F9를 눌러 tty9로 전환하십시오.
  • Fedora 시스템 팁 , Arch Linux 부팅 문제 팁을 참조하십시오 .

문제

내 문제는 최신 Intel microcode on (일부?) Skylake CPU와 최신 Linux 커널 사이의 알려진 문제이며 주로 sssd 에 의해 발생합니다 . 참조 우분투 버그 # 1759920 "의 (/ 리눅스 이미지 4.13.0-37 제네릭 W) 로그인 화면에 고정을 야기 3.20180312.0 인텔 - 마이크로" 같은 문제에 대한 것으로, 또한 판명 다른 버그의 번호를 Ubuntu 버그 # 1746806 과 같은 "sssd는 AWS c5 및 m5 인스턴스와 충돌하여 100 % CPU를 발생시키는 것으로 보입니다" 및 Ubuntu 버그 # 1746418 "linux-image-4.13.0-32-generic을 설치 한 후 Xorg를 시작할 때 시스템이 정지됨"과 같은 문제가 있습니다. 다음과 같은 경우이 버그가 발생할 수 있습니다.

• 최신 Intel CPU가 있습니다. 내가 알 수있는 한,이 버그는 Skylake CPU 에서만 발생 합니다.
• 당신은이 인텔 - 마이크로 패키지가 설치되어 있어야합니다. 이전의 마이크로 코드로만 커널을 실행했기 때문에 테스트 된 커널로 되돌아 가면 효과가 없었습니다.
• 컴퓨터가 사용자 인증을 위해 회사 네트워크 (일반적으로 LDAP 또는 Active Directory)에 연결되어 있습니다. 버그를 발생시키는 다른 방법이 있지만 sssd를 실행 하는 것이 가장 일반적인 원인 인 것 같습니다. Xorg 충돌에 대한 보고서도 있습니다 .

이 버그는 2018 년 1 월에 발표 된 스펙터 보안 문제에 대한 완화로 인한 것 입니다. 특정 상황에서 잠금을 발생시키는 일부 커널 코드와 일부 프로세서 마이크로 코드가 호환되지 않습니다 .

수리하는 방법

1. 정상적으로 부팅 할 수 없다면 Grub 프롬프트에서 커널 명령 줄을 편집해야합니다. 루트 쉘을 얻는 방법과 가능한 방법은 질문을 참조하십시오.
2. 이 특정 버그의 해결 방법 은 noibpb매개 변수를 커널 명령 줄 ( 1746418/14 , 1759920/56 )에 추가하는 것입니다. 이렇게하면 정상적으로 부팅하고 복구를 수행 할 수 있습니다.
   이렇게하면 문제를 일으키는 취약점 완화가 비활성화되어 컴퓨터가 일부 공격에 취약 해집니다. 로컬 공격입니다. 즉 공격자가 컴퓨터에서 코드를 실행해야하지만 이러한 공격은 웹 브라우저의 JavaScript를 통해 수행 될 수 있습니다.
   다른 방법이 noibpb없다면 고정 커널을 얻을 수있을 때까지 커널 명령 행 에 추가 하여 이를 영구적으로 만들 수 있습니다.
3. 우분투에서는 2018 년 4 월 23 일 주에 커널 4.4.0-117 및 4.13.0-39로 수정 될 예정입니다. 그 동안 Tyler Hicks는 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 kernel hang”에 대한 웹 검색으로 인해 https://bugs.launchpad.net/cloud-images/+bug/1746806 및 진단 및 솔루션으로 연결되었습니다.