แก้ไขข้อผิดพลาด “Failed to Start Load Kernel Modules” ระหว่างการบูต SLES

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

คู่มือนี้เขียนขึ้นสำหรับ SUSE Linux Enterprise Server 15 และสอดคล้องกับคู่มือการดูแลระบบ SLES 15 SP7 ฉบับปัจจุบัน เอกสารของ SUSE ระบุว่าsystemd-modules-load.serviceโมดูลจะถูกโหลดโดยระบุชื่อในไฟล์ `<module_name>` /etc/modules-load.d/*.confในขณะที่โมดูลฮาร์ดแวร์สมัยใหม่ส่วนใหญ่จะถูกโหลดโดยอัตโนมัติเมื่อตรวจพบอุปกรณ์ ความแตกต่างนี้มีความสำคัญ: หากรายการคงที่ที่ล้าสมัยชี้ไปยังโมดูลที่ไม่มีอยู่อีกต่อไป การลบหรือแก้ไขรายการนั้นมักจะปลอดภัยกว่าการบังคับให้ไดรเวอร์ที่ล้าสมัยกลับเข้าไปในระบบ โปรดดูเอกสารการจัดการโมดูลเคอร์เนลของ SUSE สำหรับSLES 15 SP7

วิธีแก้ปัญหาที่ประสบความสำเร็จควรมีลักษณะอย่างไร

ก่อนทำการเปลี่ยนแปลงใดๆ ให้กำหนดผลลัพธ์ที่คุณต้องการก่อน หลังจากซ่อมแซมเสร็จแล้ว:

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

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

ขั้นตอนที่ 1: ยืนยันหน่วยที่ล้มเหลวและบันทึกข้อผิดพลาดของโมดูลอย่างแม่นยำ

เริ่มต้นที่ตัวบริการเองแทนที่จะเดาจากข้อความบนหน้าจอเริ่มต้น:

sudo systemctl status systemd-modules-load.service --no-pager

มองหาชื่อโมดูลและข้อผิดพลาด เช่นModule ... not found, No such device, Operation not permitted, หรือข้อความที่ระบุว่าโมดูลที่ไม่รองรับถูกปฏิเสธ ถ้อยคำที่ใช้จะกำหนดขั้นตอนต่อไป

หากข้อความแสดงสถานะถูกตัดทอน อย่าเพิ่งแก้ไขการตั้งค่า ให้ดึงบันทึกการบูตฉบับเต็มมาก่อน

ขั้นตอนที่ 2: อ่านบันทึกการบูตก่อนทำการแก้ไขไฟล์โมดูล

สอบถามเฉพาะบริการนี้สำหรับการบูตปัจจุบันเท่านั้น:

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

คุณสามารถตรวจสอบข้อความเคอร์เนลที่เกี่ยวข้องกับการโหลดโมดูลได้เช่นกัน:

sudo journalctl -b -k --no-pager | grep -iE 'module|modprobe|firmware|taint'

คำสั่งแรกจะตอบว่าคำขอโหลดแบบคงที่ใดล้มเหลวบันทึกของเคอร์เนลอาจเพิ่มบริบทเพิ่มเติม เช่น ไดรเวอร์ปฏิเสธอุปกรณ์ที่ตรวจพบ การพึ่งพาเฟิร์มแวร์ ปัญหาเกี่ยวกับลายเซ็น หรือข้อผิดพลาดระดับต่ำอื่นๆ

ผลลัพธ์เช่นนี้Module foo not found in directory /lib/modules/...มักบ่งชี้ถึงการกำหนดค่าที่ล้าสมัย ความไม่ตรงกันของเคอร์เนล/แพ็กเกจ หรือไดรเวอร์ของบุคคลที่สามที่ไม่ได้สร้างใหม่สำหรับเคอร์เนลที่ใช้งานอยู่ แต่ผลลัพธ์No such deviceนี้แตกต่างออกไป: ไฟล์โมดูลอาจมีอยู่ แต่ฮาร์ดแวร์หรืออุปกรณ์เสมือนปัจจุบันอาจไม่ตรงกับสิ่งที่ไดรเวอร์คาดหวัง

ขั้นตอนที่ 3: ค้นหาว่าใครเป็นผู้ขอให้ SLES โหลดโมดูลนั้น

ค้นหาตำแหน่งโหลดคงที่ปกติและการกำหนดค่า modprobe:

grep -Rns --color=auto 'MODULE_NAME'   /etc/modules-load.d /run/modules-load.d /usr/lib/modules-load.d   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

แทนที่MODULE_NAMEด้วยชื่อจากบันทึก ใน SLES 15 SP7 รายการภายในเครื่องใน/etc/modules-load.d/เป็นตำแหน่งมาตรฐานที่ผู้ดูแลระบบจัดการสำหรับโมดูลที่ต้องโหลดเมื่อบูตเครื่อง ในขณะที่รายการที่บรรจุไว้สามารถอยู่ใน ได้/usr/lib/modules-load.d/SUSE ระบุว่าโมดูลส่วนใหญ่ไม่จำเป็นต้องมีรายการ modules-load.d ด้วยตนเองเลย

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

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

หากโมดูลนั้นล้าสมัยแล้ว

ลบหรือปิดใช้งานไฟล์ในเครื่องที่ร้องขอไฟล์นั้น อย่าลบไฟล์ของผู้จำหน่าย/usr/libเพียงเพื่อระงับข้อผิดพลาด เพราะการอัปเดตแพ็กเกจอาจกู้คืนไฟล์นั้นกลับมา หากคุณพบว่า/etc/modules-load.d/*.confไฟล์ในเครื่องถูกสร้างขึ้นสำหรับฮาร์ดแวร์ที่เลิกผลิตแล้วหรือซอฟต์แวร์รุ่นเก่า ให้ลบรายการในเครื่องนั้นออกแล้วทดสอบอีกครั้ง

หากโมดูลควรมีอยู่ แต่ modinfo หาไม่พบ

ตรวจสอบว่าเคอร์เนลที่กำลังทำงานอยู่ตรงกับโครงสร้างโมดูลที่ติดตั้งไว้หรือไม่:

uname -r
ls -ld /lib/modules/$(uname -r)
rpm -q kernel-default

การตรวจสอบคุณภาพขั้นพื้นฐานนั้นง่ายมาก: /lib/modules/$(uname -r)ไฟล์นั้นต้องมีอยู่จริงและมีโมดูลสำหรับเคอร์เนลที่กำลังทำงานอยู่ หากไดรเวอร์ของบุคคลที่สามถูกคอมไพล์สำหรับเคอร์เนลเวอร์ชันเก่ากว่า ให้ติดตั้งใหม่หรือสร้างไดรเวอร์นั้นใหม่โดยใช้เคอร์เนล SLES เวอร์ชันปัจจุบันตามขั้นตอนที่ผู้ผลิตกำหนด หลีกเลี่ยงการคัดลอก.koไฟล์จากเคอร์เนลเวอร์ชันอื่นเพียงเพื่อmodprobeค้นหาบางสิ่ง เพราะความแตกต่างของ ABI หรือลายเซ็นของเคอร์เนลอาจทำให้การทำเช่นนั้นไม่ปลอดภัยหรือไม่ได้ผล

หากโมดูลถูกขึ้นบัญชีดำ

ค้นหารายการที่ถูกบล็อก หรือติดตั้งโปรแกรมเพื่อแก้ไข:

grep -Rns --color=auto -E '^[[:space:]]*(blacklist|install)[[:space:]]+MODULE_NAME'   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

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

หาก SLES รายงานว่าโมดูลนั้นไม่รองรับ

อย่าเปิดใช้งานการโหลดโมดูลที่ไม่รองรับโดยอัตโนมัติ SLES จะกำหนดสถานะการรองรับให้กับโมดูลเคอร์เนล และการบังคับใช้โมดูลที่ไม่รองรับอาจส่งผลต่อการรองรับ เอกสารของ SUSE อธิบายกลไกข้อยกเว้นสำหรับสถานการณ์การทดสอบหรือการแก้ไขด่วนของผู้จำหน่ายในคู่มือการดูแลระบบ ควรใช้เฉพาะเมื่อคุณเข้าใจผลกระทบต่อการรองรับและมีความต้องการไดรเวอร์ที่ถูกต้อง คู่มือ SUSE ฉบับปัจจุบันเดียวกันนี้มีอยู่ในSLES 15 SP7 Administration Guide

ขั้นตอนที่ 4: สร้าง initramfs ใหม่เฉพาะเมื่อการเปลี่ยนแปลงนั้นส่งผลต่อการบูตในช่วงแรกเท่านั้น

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

sudo dracut -f

SUSE ได้จัดทำเอกสารอธิบายอย่างละเอียดเกี่ยวกับการสร้าง initramfs ขึ้นใหม่หลังจากมีการเปลี่ยนแปลงไดรเวอร์ที่ส่งผลต่อการบูต คู่มือขั้นตอนการบูตฉบับปัจจุบันของ SUSE อธิบายว่าเมื่อใดที่จำเป็นต้องเพิ่มไดรเวอร์ลงใน initramfs และวิธีdracutการใช้งานเพื่อสร้าง initramfs ขึ้นใหม่: บทนำเกี่ยวกับกระบวนการบูตใน SLES 15 SP7

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

ตรวจสอบการซ่อมแซมให้เรียบร้อยก่อนสรุปว่าเหตุการณ์ดังกล่าวจบลงแล้ว

ทดสอบครั้งแรกโดยไม่ต้องรีบูตเครื่อง เมื่อสามารถทำได้อย่างปลอดภัย:

sudo systemctl restart systemd-modules-load.service
systemctl status systemd-modules-load.service --no-pager
systemctl is-failed systemd-modules-load.service

หากโมดูลที่ต้องการโหลดเสร็จสมบูรณ์แล้ว โปรดยืนยัน:

lsmod | grep -w MODULE_NAME

จากนั้นให้รีบูตเครื่องในช่วงเวลาการบำรุงรักษาที่เหมาะสม และตรวจสอบการบูตเครื่องใหม่:

sudo reboot

หลังจากเข้าสู่ระบบ:

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

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

เมื่อใดควรเปลี่ยนวิธีการ

ข้อจำกัดของการแก้ไขนี้

ข้อความ “Failed to Start Load Kernel Modules” เป็นเพียงอาการของปัญหา ไม่ใช่ข้อบกพร่องเพียงอย่างเดียว ขั้นตอนนี้จะแก้ไขปัญหาที่เกิดจากคำขอโมดูลแบบคงที่ โมดูลที่หายไปหรือไม่ตรงกัน บัญชีดำ และการซิงโครไนซ์ initramfs แต่จะไม่สามารถทดแทนการวินิจฉัยฮาร์ดแวร์ การสนับสนุนไดรเวอร์จากบุคคลที่สาม การทำงานของการลงนาม Secure Boot หรือการกู้คืนข้อมูลในกรณีที่อุปกรณ์รูทไม่สามารถใช้งานได้

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