Sự cố trong khi khởi động trên máy tính của công ty gần đây

Sau một số cập nhật gần đây, máy tính của tôi không còn khởi động! Đây là những gì tôi có thể xác định:

• Đây là một máy tính gần đây được cung cấp cho tôi bởi IT công ty. Nó có CPU Intel gần đây (thế hệ Skylake).
• Máy tính chạy Ubuntu 16.04.
• Máy tính khởi động lần cuối một cách chính xác một thời gian trong tháng ba. Vấn đề có lẽ là do cập nhật phần mềm hoặc lỗi phần cứng.
• Tôi có một máy tính khác chạy 16.04 với khá nhiều phần mềm được cài đặt (tôi đã sử dụng apt-clone) và nó hoạt động rất tốt. Nó có phần cứng khác nhau (cũng là amd64, nhưng CPU khác nhau, GPU khác nhau, v.v.).
• Nhân không bắt đầu, initrd hoạt động chính xác. Khi tôi khởi động với màn hình giật gân ở chế độ đồ họa, tôi được nhắc nhập mật khẩu cho khối lượng dm-crypt của mình và điều cuối cùng tôi thấy là nó được gắn kết thành công.
• Việc treo xảy ra trước khi tôi nhận được lời nhắc đăng nhập. Khi máy tính bị treo, đó là một lỗi khó khăn. Thậm chí Alt+ SysRqkhông trả lời. CPU rõ ràng được chốt ở mức 100% kể từ khi quạt bật hoàn toàn.
• Tôi vẫn còn kernel tôi đang chạy trước khi khởi động lại. Khi tôi chọn kernel này trong menu Grub, tôi sẽ bị khóa tương tự. Vì vậy, có vẻ như đây là một lỗi kernel đã có sẵn được kích hoạt bởi một thứ khác - nhưng cái gì?
• Nếu tôi tắt màn hình giật gân (xóa splashkhỏi linuxdòng lệnh trong Grub), tôi thấy một số dịch vụ bắt đầu, sau đó nó bị khóa.

• Tôi có thể lấy shell root bằng cách thêm init=/bin/shvào linuxdòng lệnh trong Grub. Tôi thậm chí có thể nhận được nhiều hơn bằng cách thêm

  systemd.unit=basic.target systemd.shell
  

  Điều này bắt đầu một số dịch vụ và chạy shell root trên tty9.

• Nếu tôi chạy systemctl start multi-user.targettừ vỏ gốc đó, máy tính sẽ khóa. Vì vậy, có lẽ vấn đề được kích hoạt bởi một trong những dịch vụ này.
• Tôi chạy systemctl list-dependencies multi-user.targetđể xem những dịch vụ bắt đầu. Tôi tự khởi động các phụ thuộc được liệt kê từng cái một và mọi thứ bắt đầu tốt.

Vì vậy, điều này trông giống như một lỗi phần cứng (vì nó xảy ra trên một máy tính nhưng không phải trên một máy tính khác) được kích hoạt bởi một số phần mềm. Nhưng phần mềm nào? Vì máy tính khóa quá mạnh, tôi không thể nhận được bất kỳ nhật ký nào. Tôi thậm chí không thể nhận được bất kỳ đầu ra giao diện điều khiển hữu ích.

Các kỹ thuật sửa lỗi hữu ích:

• Alt+ SysRq: phím SysRq ma thuật , cho phép bạn thực hiện những việc như khởi động lại khẩn cấp. Nó truy cập kernel ở mức rất thấp, vì vậy nó hoạt động trong tất cả các sự cố tồi tệ nhất. Trong trường hợp của tôi, Alt+ SysRqkhông phản hồi, điều này cho thấy sự cố sâu đến mức nào.
• Để sửa đổi các tham số khởi động, nhấn và giữ Shiftmột vài giây sau khi bật nguồn. Bạn cần nhấn nó sau khi BIOS đã khởi tạo bàn phím, nhưng trước khi hệ điều hành khởi động. Điều này làm cho menu Grub xuất hiện.
• Trong menu Grub, nhấn eđể chỉnh sửa dòng lệnh cho mục nhập menu. Để thay đổi các tham số khởi động Linux, hãy điều hướng đến dòng bắt đầu bằng linux. Trên một Ubuntu hiện đại, bạn sẽ tìm thấy các hạt nhân cũ dưới các tùy chọn Nâng cao cho Ubuntu Ubuntu. Khi bạn đã thực hiện các thay đổi mong muốn cho dòng lệnh, hãy nhấn Ctrl+ xđể khởi động. Mọi thay đổi bạn thực hiện ở đây chỉ dành cho khởi động này, chúng không được lưu vào đĩa.
• Một số tùy chọn hữu ích trên linuxdòng lệnh:
  • quiet nosplashẩn gần như tất cả các thông điệp khởi động. Loại bỏ chúng để nhận tin nhắn trên bàn điều khiển trong khi khởi động, điều này là cần thiết để có bất kỳ cơ hội chẩn đoán vấn đề.
  • recoverycung cấp cho bạn một vỏ gốc với hầu như không có dịch vụ. Bạn sẽ cần phải biết mật khẩu root. Chế độ phục hồi của mục nhập vào mục menu sử dụng này.
  • init=/bin/shcung cấp cho bạn một vỏ gốc không có dịch vụ nào cả. Để tiếp tục khởi động bình thường, hãy chạy exec init. Bạn có thể vượt qua các tùy chọn systemd tại thời điểm này, ví dụ: exec init --unit=basic.targetđể bắt đầu init và một vài dịch vụ (lưu ý rằng điều này không bắt đầu bất kỳ cách nào để đăng nhập, vì vậy tốt hơn là bạn nên chạy shell trên bảng điều khiển khác). Lưu ý rằng hệ thống tập tin gốc được gắn kết chỉ đọc; chạy mount -o remount,rw /để có thể viết cho nó
  • systemd.unit=basic.targetbắt đầu một bộ dịch vụ rất cơ bản Lưu ý rằng điều này không bao gồm bất kỳ cách nào để đăng nhập! Bạn có thể đặt mặc định này bằng cách chạy systemctl set-default basic.targettại dấu nhắc gốc. Để khôi phục mục tiêu mặc định ban đầu, hãy chạy systemctl set-default graphical.target(hoặc systemctl set-default multi-user.targetcho một máy chủ không có GUI).
  • systemd.debug-shellbắt đầu một vỏ gốc trên tty9. Bạn có thể kích hoạt tính năng này cho mọi khởi động bằng cách chạy systemctl enable debug-shelltại dấu nhắc gốc. Đừng quên tắt điều này sau khi bạn đã giải quyết vấn đề systemctl disable debug-shell. Nhấn Alt+ F9để chuyển sang tty9.
  • Xem thêm mẹo hệ thống Fedora , mẹo khởi động Arch Linux .

Vấn đề

Hóa ra vấn đề của tôi là một vấn đề đã biết giữa bộ vi mã Intel mới nhất trên (một số?) CPU Skylake và các nhân Linux gần đây, chủ yếu được kích hoạt bởi sssd . Xem lỗi Ubuntu # 1759920, mã intel-microcode 3.20180412.0 gây ra khóa máy ở màn hình đăng nhập (w / linux-image-4.13.0-37-generic) , và một số lỗi khác cũng xảy ra với cùng một vấn đề , chẳng hạn như lỗi Ubuntu # 1746806, sssd dường như gặp sự cố AWS c5 và m5, gây ra 100% CPU CPU và Ubuntu # 1746418 Lỗi hệ thống bị đóng băng khi khởi động Xorg sau khi cài đặt linux-image-4.13.0-32-chung . Bạn có thể gặp phải lỗi này nếu:

• Bạn có một CPU Intel rất gần đây. Theo như tôi có thể nói, lỗi này chỉ phát sinh trên CPU Skylake .
• Bạn đã cài đặt gói intel-microcode . Hoàn nguyên về một kernel đã được kiểm tra trước đó không hoạt động với tôi vì tôi chỉ chạy kernel đó với một microcode trước đó.
• Máy tính của bạn được kết nối với mạng công ty (thường là LDAP hoặc Active Directory) để xác thực người dùng. Mặc dù có nhiều cách khác để kích hoạt lỗi, nhưng chạy sssd dường như là thủ phạm phổ biến nhất. Ngoài ra còn có báo cáo về Xorg bị rơi .

Lỗi này là do giảm nhẹ cho vấn đề bảo mật Spectre đã được xuất bản vào tháng 1 năm 2018. Có sự không tương thích giữa một số mã hạt nhân và một số vi mã bộ xử lý gây ra khóa trong một số trường hợp nhất định.

Cách sửa chữa

1. Nếu bạn không thể khởi động bình thường, bạn sẽ cần chỉnh sửa dòng lệnh kernel tại dấu nhắc Grub. Xem câu hỏi để được giải thích và các cách có thể để có được một vỏ gốc.
2. Một cách giải quyết cho lỗi cụ thể này là thêm noibpbtham số vào dòng lệnh kernel ( 1746418/14 , 1759920/56 ). Điều này sẽ cho phép bạn khởi động bình thường và thực hiện một số sửa chữa.
   Điều này vô hiệu hóa giảm thiểu lỗ hổng gây ra vấn đề, có nghĩa là máy tính của bạn hiện dễ bị tấn công. Chúng là các cuộc tấn công cục bộ, tức là kẻ tấn công cần chạy mã trên máy của bạn, nhưng các cuộc tấn công này có thể có khả năng được thực hiện, ví dụ như thông qua JavaScript trong trình duyệt web.
   Nếu bạn không có cách nào khác, bạn có thể thực hiện điều này vĩnh viễn bằng cách thêm noibpbvào dòng lệnh kernel cho đến khi bạn có thể lấy kernel cố định.
3. Trong Ubuntu, bản sửa lỗi dự kiến vào tuần 23 tháng 4 năm 2018 , trong đó có lẽ sẽ là kernel 4.4.0-117 và 4.13.0-39. Trong khi đó, Tyler Hicks đã xuất bản các hạt nhân thử nghiệm cho 4.4 và 4.13 .

Làm thế nào tôi chẩn đoán vấn đề

Tôi đã thử một vài thứ (xem câu hỏi) và xác định rằng lỗi đã được kích hoạt ở đâu đó giữa việc tiếp cận basic.targetvà tiếp cận multi-user.target. Vì vậy, tôi đặt mục tiêu systemd mặc định thành basic.target( systemctl set-default basic.target) và kích hoạt debug-shelldịch vụ ( systemctl enable debug-shell) để lấy shell gốc.

Tôi chạy systemctl list-dependencies multi-user.targetvà tự khởi động các phụ thuộc được liệt kê từng cái một. Điều này đã không kích hoạt sự cố.

Không phải tất cả các dịch vụ được quản lý trực tiếp bởi systemd . Một số được quản lý dưới dạng dịch vụ Upstart và một số được quản lý dưới dạng tập lệnh SysVinit . Kịch bản shell bên dưới chạy tất cả chúng. Lưu ý: Tôi chỉ thử nghiệm nó một lần và nó bị lỗi do thiết kế.

#!/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áy tính của tôi bị hỏng sau khi bắt đầu sssd. Từ đó, một tìm kiếm trên web về kernel sssd linux treo hang đã dẫn tôi đến https://bugs.launchpad.net/cloud-images/+orms/1746806 và để chẩn đoán và giải pháp.