ความล้มเหลวในการโหลดโมดูลบูต SLES: ค้นหาไดรเวอร์และแก้ไขปัญหา

เมื่อ SLES แสดงข้อความ “Failed to Start Load Kernel Modules” ระหว่างการบูต ให้ตรวจสอบsystemd-modules-load.serviceบันทึก (log) ก่อนเพื่อระบุโมดูลที่ล้มเหลว หากโมดูลนั้นเป็นรายการเสริมที่ล้าสมัย ให้ลบคำขอออกจากไฟล์การกำหนดค่า หากเป็นโมดูลที่จำเป็น ให้แก้ไขความไม่ตรงกันของไดรเวอร์หรือเคอร์เนลแทนที่จะปิดใช้งานบริการ

ขั้นตอนการดำเนินการนี้ใช้ได้กับ SUSE Linux Enterprise Server (SLES) 15 โดยใช้เอกสารการดูแลระบบ SLES 15 SP7 เป็นข้อมูลอ้างอิง ควรเรียกใช้คำสั่งจากคอนโซลภายในเครื่องหรือเซสชัน SSH ที่ใช้งานได้และมีsudoสิทธิ์เข้าถึง

เข้าใจความหมายของข้อความก่อนที่จะเปลี่ยนแปลงอะไรก็ตาม

โมดูลเคอร์เนลคือไดรเวอร์หรือฟีเจอร์ของเคอร์เนลที่สามารถโหลดแยกต่างหากได้ ในระหว่างการเริ่มต้นsystemd-modules-load.serviceระบบ จะประมวลผลคำขอโหลดโมดูลเฉพาะ รวมถึงโมดูลที่กำหนดไว้ในmodules-load.dไฟล์ คำขอที่ไม่สำเร็จอาจทำให้บริการนั้นล้มเหลว แม้ว่าส่วนอื่นๆ ของเซิร์ฟเวอร์จะยังคงทำงานต่อไปก็ตาม

SUSE ระบุว่าไดรเวอร์ส่วนใหญ่จะโหลดโดยอัตโนมัติเมื่อตรวจพบฮาร์ดแวร์ รายการโมดูลด้วยตนเองมักไม่จำเป็น ดังนั้นรายการที่ไม่ทันสมัยจึงเป็นไปได้—แต่ข้อความบูตเพียงอย่างเดียวไม่สามารถพิสูจน์ได้ ควรคงการเข้าถึงคอนโซลไว้ ถ่ายภาพสแนปช็อตของระบบหรือสำรองข้อมูลการกำหนดค่าหากมี และอย่าถอนการติดตั้งไดรเวอร์จัดเก็บข้อมูล เครือข่าย หรือคลัสเตอร์เพียงเพื่อให้คำเตือนหายไป ดูคู่มือการดูแลระบบโมดูลเคอร์เนล ของ SUSE สำหรับรุ่นที่รองรับ

ขั้นตอนที่ 1: อ่านสถานะการบริการและบันทึกการบูต

เริ่มต้นด้วยคำสั่ง `systemd status` systemdซึ่งเป็นตัวจัดการบริการที่รับผิดชอบในการเริ่มต้นบริการและรายงานสถานะของบริการเหล่านั้น

sudo systemctl status systemd-modules-load.service --no-pager
sudo journalctl -b -u systemd-modules-load.service --no-pager

แฟล็ก นี้-bจำกัดjournalctlการทำงานเฉพาะการบูตปัจจุบัน และ-uเลือกบริการนี้ มองหาข้อความต่างๆ เช่น “ไม่พบโมดูล” ตัวเลือกไม่ถูกต้อง หรือข้อผิดพลาดเกี่ยวกับสิทธิ์หรือลายเซ็น เหนือบรรทัดสุดท้าย “ล้มเหลวพร้อมผลลัพธ์” บันทึกชื่อโมดูลและข้อความแสดงข้อผิดพลาดให้ถูกต้อง อย่าสันนิษฐานว่าโมดูลที่ระบุในตัวอย่างด้านล่างมีอยู่ในเซิร์ฟเวอร์ของคุณ

หากบันทึกการบริการไม่ให้ข้อมูลที่ชัดเจน ให้ตรวจสอบข้อความจากเคอร์เนลเพื่อดูรายละเอียดเพิ่มเติม:

sudo journalctl -k -b --no-pager

หากคอมพิวเตอร์ไม่สามารถเข้าสู่ระบบได้ ให้เริ่มใช้งานเคอร์เนลเวอร์ชันเก่าที่ติดตั้งไว้จาก GRUB หากมี หรือใช้สื่อกู้คืน SLES อย่าแก้ไขโมดูลที่สำคัญต่อการบูตจากเซสชันระยะไกลที่ยังไม่ได้ทดสอบ เอกสารของ SUSE อธิบายตัวกรองบันทึกในบทการจัดการ journalctl

ขั้นตอนที่ 2: ค้นหาการตั้งค่าเริ่มต้นที่ร้องขอการตั้งค่าดังกล่าว

สมมติว่าชื่อวารสารคือexample_driver. แทนที่ตัวยึดตำแหน่งนั้นด้วยชื่อโมดูลจริง จากนั้นค้นหาในรายการโมดูล:

sudo grep -Rns --include='*.conf' 'example_driver' \
  /etc/modules-load.d /run/modules-load.d \
  /usr/lib/modules-load.d 2>/dev/null

แต่ละบรรทัดที่ตรงกันจะบอกคุณว่าไฟล์ใดร้องขอโมดูลนั้นเมื่อบูตเครื่อง การกำหนดค่าในเครื่องของผู้ดูแลระบบมักจะอยู่ใน `/etc/ systemd/systemd.com` /etc/modules-load.d/ในขณะที่แพ็กเกจอาจจัดเตรียมไฟล์ไว้/usr/lib/modules-load.d/ใน `/etc/systemd/systemd.com` ไฟล์ในเครื่องที่มีชื่อเดียวกันจะมีลำดับความสำคัญเหนือกว่าไฟล์ของผู้จำหน่าย ตามที่อธิบายไว้ในคู่มือการกำหนดค่า systemd ของ SUSE หากการค้นหาไม่พบอะไรเลย ให้ตรวจสอบcat /proc/cmdlineการร้องขอโมดูลเมื่อบูตเครื่องและตรวจสอบว่าชื่อที่เกิดข้อผิดพลาดถูกคัดลอกอย่างถูกต้องหรือไม่

เปิดไฟล์ที่ตรงกันและตรวจสอบว่าฮาร์ดแวร์หรือแอปพลิเคชันยังต้องการรายการนั้นอยู่หรือไม่ โมดูลที่ร้องขอสำหรับอุปกรณ์เก่าที่ถูกถอดออกไปแล้วจะแตกต่างจากไดรเวอร์ตัวควบคุมการจัดเก็บข้อมูลหรือตัวเฝ้าระวังคลัสเตอร์

ขั้นตอนที่ 3: ทดสอบโมดูล จากนั้นทำการซ่อมแซมที่เหมาะสม

ตรวจสอบว่าเคอร์เนลใดกำลังทำงานอยู่และไดรเวอร์พร้อมใช้งานสำหรับเคอร์เนลนั้นหรือไม่modprobeโหลดโมดูลเคอร์เนลและแก้ไขการพึ่งพา ตัว-nเลือกของฟังก์ชันนี้จะทำการทดสอบแบบจำลองโดยไม่ใส่โมดูลจริงเข้าไป

uname -r
modinfo example_driver
sudo modprobe -n -v example_driver

อีกครั้ง ให้เปลี่ยนexample_driverการทดสอบแบบจำลอง (dry run) ช่วยระบุปัญหาการค้นหาหรือการกำหนดค่า แต่ไม่ได้พิสูจน์ว่าไดรเวอร์จะเริ่มต้นทำงานบนฮาร์ดแวร์ของคุณได้สำเร็จหรือผ่านการตรวจสอบลายเซ็น Secure Boot SUSE แนะนำให้ใช้modprobeแทนinsmodการโหลดโดยตรง รายละเอียดของแฟล็กการทดสอบแบบจำลองปรากฏอยู่ในคู่มือmodprobe

หากรายการเสริมที่ล้าสมัยชี้ไปยังโมดูลที่หายไป

สำรองไฟล์โลคัลเฉพาะนั้นไว้ แล้วคอมเมนต์เฉพาะบรรทัดที่ล้าสมัยเท่านั้น ตัวอย่างเช่น ถ้า/etc/modules-load.d/example.confเป็นแหล่งที่มาที่ได้รับการยืนยันแล้ว:

sudo cp -a /etc/modules-load.d/example.conf \
  /etc/modules-load.d/example.conf.bak
sudoedit /etc/modules-load.d/example.conf

เปลี่ยนรายการเดียวexample_driverเป็น# example_driverบันทึก และคงคำขอโมดูลอื่นๆ ไว้เหมือนเดิม หากแหล่งที่มาเป็นไฟล์แพ็กเกจภายใต้/usr/libอย่าแก้ไขไฟล์แพ็กเกจนั้นโดยตรง ให้ใช้การแทนที่ในเครื่องที่ได้รับการตรวจสอบอย่างถูกต้อง หรือแก้ไขการกำหนดค่าของแพ็กเกจนั้น อย่าลบคำขอโมดูลเพียงเพราะmodinfoรายงานว่าขาดหายไป หากอุปกรณ์ที่เกี่ยวข้องนั้นจำเป็น

หากโมดูลที่จำเป็นหายไปหรือไม่เข้ากันไม่ได้

อย่าคอมเมนต์บรรทัดนั้นทิ้งไป ตรวจสอบให้แน่ใจว่าแพ็คเกจไดรเวอร์รองรับเอาต์พุตของคำสั่งuname -rและ Service Pack ของ SLES ที่ติดตั้งไว้ ข้อความ “ไม่พบโมดูล” อาจบ่งชี้ว่าไม่ได้ติดตั้งไดรเวอร์ที่ตรงกัน หรือไม่ได้สร้างใหม่หลังจากอัปเดตเคอร์เนล ข้อความ “รูปแบบโมดูลไม่ถูกต้อง” บ่งชี้ถึงปัญหาความเข้ากันได้ บรรทัดบันทึกของเคอร์เนลสามารถช่วยระบุปัญหาได้ละเอียดขึ้น กู้คืนหรือติดตั้งไดรเวอร์ที่รองรับอีกครั้งผ่านคำแนะนำของ SUSE หรือผู้จำหน่ายฮาร์ดแวร์ หลีกเลี่ยงการคัดลอก.koไฟล์ใดๆ จากเคอร์เนลอื่น

หากโมดูลมีอยู่จริง แต่ดัชนีการพึ่งพาของโมดูลนั้นล้าสมัยอย่างเห็นได้ชัด ให้สร้างดัชนีนั้นใหม่สำหรับเคอร์เนลปัจจุบัน แล้วลองทำการทดสอบแบบจำลองอีกครั้ง:

sudo depmod -a "$(uname -r)"
sudo modprobe -n -v example_driver

ขั้นตอนนี้ไม่ได้ติดตั้งไดรเวอร์ที่ขาดหายไป หากคุณเห็นข้อความ “คีย์ที่จำเป็นไม่พร้อมใช้งาน” หรือการปฏิเสธลายเซ็นโมดูลในระบบ Secure Boot ให้ปฏิบัติตามขั้นตอนการลงทะเบียนคีย์ที่เชื่อถือได้และการลงนามไดรเวอร์ของ SUSE อย่าปิดใช้งาน Secure Boot เป็นวิธีแก้ปัญหาทั่วไป SUSE อธิบายข้อจำกัดของไดรเวอร์จากบุคคลที่สามในคำแนะนำการปรับใช้ Secure Boot ของ ตน

ขั้นตอนที่ 4: ตรวจสอบว่าการบูตครั้งต่อไปนั้นสะอาดหมดจด

หลังจากแก้ไขการตั้งค่าหรือกู้คืนไดรเวอร์แล้ว ให้ลองโหลดโปรแกรมอีกครั้งและตรวจสอบสถานะ ทำเช่นนี้หลังจากตรวจสอบแล้วว่ารายการที่เหลือทั้งหมดถูกต้อง การรีสตาร์ทจะพยายามโหลดตามการตั้งค่าอีกครั้ง

sudo systemctl restart systemd-modules-load.service
sudo systemctl status systemd-modules-load.service --no-pager
sudo journalctl -b -u systemd-modules-load.service --no-pager

หากการดำเนินการสำเร็จ ให้กำหนดเวลาการรีบูตแบบควบคุมโดยเข้าถึงคอนโซล และเรียกใช้คำสั่งสถานะและบันทึกอีกครั้ง การแก้ไขจะได้รับการยืนยันเมื่อบริการไม่ล้มเหลวอีกต่อไปในการบูตครั้งใหม่ และฮาร์ดแวร์หรือซอฟต์แวร์ที่จำเป็นใดๆ ที่ขึ้นอยู่กับโมดูลยังคงทำงานได้ หากข้อผิดพลาดกลับมา ให้เปรียบเทียบบันทึกใหม่กับบันทึกเก่า: โมดูลอื่นที่แสดงอยู่อาจล้มเหลวเช่นกัน เก็บสำเนาสำรองไว้จนกว่าการตรวจสอบนั้นจะผ่าน อย่าปิดบังsystemd-modules-load.serviceเพียงเพื่อระงับข้อความเริ่มต้น