การวินิจฉัยปัญหาการบูตระบบ Linux และความล้มเหลวของฮาร์ดแวร์

อินฟอร์เมเทค ดิจิตอล » Recursos » การวินิจฉัยปัญหาการบูตระบบ Linux และความล้มเหลวของฮาร์ดแวร์

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

หากคุณพบข้อความต่างๆ เช่น“ไม่พบระบบไฟล์รูท” “พื้นที่บนอุปกรณ์ไม่เพียงพอ” “ข้อผิดพลาด EXT4-fs” “XFS: ข้อผิดพลาด CRC ของเมตาเดต้า” หรือ Kernel Panic ที่น่ากลัวในที่นี้คุณจะได้เรียนรู้วิธีการตีความข้อความเหล่านั้น คำสั่งที่ควรใช้ และลำดับการดำเนินการ นอกจากนี้เราจะมาดูวิธีการตรวจสอบว่าปัญหาเกิดจากซอฟต์แวร์จริงหรือไม่ หรือฮาร์ดแวร์ (RAM, SSD/HDD, การ์ดเครือข่าย ฯลฯ) กำลังจะเสีย และวิธีการลดความเสี่ยงในการสูญเสียข้อมูลขณะแก้ไขปัญหา

สาเหตุทั่วไปของปัญหาการบูตใน Linux

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

ปัญหาชุดแรกเกิดจากตัวจัดการการบูตและการกำหนดค่า BIOS/UEFIได้แก่ รายการ GRUB ที่สร้างขึ้นไม่ถูกต้อง MBR ถูกเขียนทับหลังจากติดตั้ง Windows ในการตั้งค่าบูตแบบคู่ Secure Boot ไม่เข้ากันกับระบบปฏิบัติการของคุณ หรือ BIOS พยายามบูตจากดิสก์ที่ไม่ถูกต้อง ในกรณีเหล่านี้ คุณมักจะไม่เห็นเมนู GRUB หรือเมื่อคุณเลือกระบบปฏิบัติการ Linux ระบบจะค้างหรือกลับไปที่เฟิร์มแวร์

อีกประเด็นสำคัญคือเรื่องต่อไปนี้ ดิสก์และระบบไฟล์พาร์ติชั่นเสียหาย เซกเตอร์เสีย ความเสียหายของ EXT4 หรือ XFS ดิสก์ระบบเต็ม หรือข้อผิดพลาด LVM โดยปกติจะแสดงเป็นข้อความระหว่างการบูต เช่น “ไม่สามารถติดตั้งได้ /…","ข้อผิดพลาด EXT4-fs","XFS: ยกเลิกการเมานต์และเรียกใช้ xfs_repair"หรืออาจถึงขั้นเข้าสู่โหมดฉุกเฉินและขอให้คุณดำเนินการบางอย่าง" journalctl -xb.

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

เราต้องไม่ลืมส่วนเกี่ยวกับการกำหนดค่าระบบเองด้วย เช่น กฎการบูตที่ปลอดภัยที่เข้มงวดเกินไป (ตัวอย่างเช่น auditd ที่กำหนดค่าให้หยุดทำงานเมื่อ /var/log/audit เต็ม) บริการที่สำคัญซึ่งล้มเหลวเนื่องจากพื้นที่ไม่เพียงพอ หรือการเปลี่ยนแปลงในไฟล์การกำหนดค่าที่ป้องกันไม่ให้โปรแกรมพื้นฐานที่จำเป็นเริ่มต้นทำงาน (เครือข่าย, systemd, cloud-init ในระบบคลาวด์เช่น Azure เป็นต้น)

สุดท้ายนี้ มาดูที่ส่วนของฮาร์ดแวร์กันบ้าง เช่น ดิสก์ที่มีเครื่องหมาย SMART สีแดง, RAM ที่มีข้อผิดพลาด ECC, การ์ดเครือข่ายที่สูญเสียแพ็กเก็ต หรือ SSD ที่ร้อนเกินไปบ่อยครั้งที่เบาะแสจะอยู่ในข้อความจากเคอร์เนล (dmesg) หรือในตัวนับ SMART และ EDAC ดังนั้นเราจะมาดูกันว่าวิธีการอ่านข้อความเหล่านี้อย่างละเอียดนั้นทำอย่างไร

วิธีระบุสาเหตุของปัญหาการสตาร์ทเครื่องยนต์

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

ในระบบที่ใช้ GRUB คุณสามารถปิดโหมดเงียบได้โดยแก้ไขไฟล์ /etc/default/grubมองหาบรรทัด:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

และแทนที่ด้วย:

GRUB_CMDLINE_LINUX_DEFAULT=""

จากนั้นเรียกใช้ คำสั่ง `update-grub` (หรือคำสั่งที่เทียบเท่าในระบบปฏิบัติการของคุณ) เพื่อสร้างการกำหนดค่าใหม่ ในการบูตครั้งถัดไป คุณจะเห็นข้อความทั้งหมดของเคอร์เนลและ systemd แสดงขึ้น ทำให้คุณสามารถระบุข้อผิดพลาดที่ทำให้ระบบล่มได้อย่างแม่นยำ

หากระบบสามารถบูตได้บางส่วน หรือคุณสามารถเข้าถึงได้จากสภาพแวดล้อม Live คุณจะพบไฟล์บันทึกสำคัญหลายไฟล์ใน/var/log :

• /var/log/boot.logบันทึกทุกสิ่งที่เกิดขึ้นระหว่างขั้นตอนการเริ่มต้นระบบ หากพบข้อผิดพลาดในขั้นตอนนี้ ควรตรวจสอบที่นี่เป็นที่แรก
• / var / log / ข้อความ o / var / log / syslog (ขึ้นอยู่กับดิสทริบิวชัน): เหตุการณ์ระบบทั่วไป มีประโยชน์มากสำหรับการดูข้อผิดพลาดในบริการ โปรแกรมเบื้องหลัง ฯลฯ
• dmesg: แสดงข้อความจากเคอร์เนล รวมถึงข้อผิดพลาดของฮาร์ดแวร์ ปัญหาของโมดูล ข้อผิดพลาดของบัส ข้อผิดพลาดของ PCI เป็นต้น
• journalctlในระบบที่ใช้ systemd นั้น มันเป็นเครื่องมือหลักสำหรับการสำรวจรีจิสทรีทั้งหมด; ด้วย journalctl -xb คุณจะได้เห็นการเริ่มต้นครั้งสุดท้ายอย่างงดงามตระการตา

หากระบบไม่สามารถเข้าสู่เดสก์ท็อปได้ แต่เข้าสู่โหมด TTY หรือโหมดกู้คืนได้ คุณสามารถเรียกใช้คำสั่ง`journalctl -xb`ได้โดยตรงจากที่นั่น หากวิธีนี้ไม่ได้ผล คุณจะต้องบูตจาก Live USB จากนั้นทำการเมานต์ดิสก์ระบบ และอ่านไฟล์เหล่านั้นจากสภาพแวดล้อมแบบ Live

ตรวจสอบว่าปัญหาเกิดจากฮาร์ดแวร์หรือซอฟต์แวร์

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

ขั้นตอนแรก หากคอมพิวเตอร์ไม่รู้จักฮาร์ดไดรฟ์เลย ให้เข้าไปในBIOS/UEFIและตรวจสอบว่าฮาร์ดไดรฟ์ปรากฏอยู่ในรายการหรือไม่ หากฮาร์ดไดรฟ์ไม่ปรากฏเลย หรือปรากฏบ้างไม่ปรากฏบ้าง ให้ตรวจสอบการเชื่อมต่อ สาย SATA และแหล่งจ่ายไฟ หรือสันนิษฐานว่าฮาร์ดไดรฟ์อาจต้องนำไปรีไซเคิล

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

ในการตรวจสอบสถานะของดิสก์ใน Linux ให้ใช้smartmontoolsหลังจากติดตั้งแล้ว ให้เปิดใช้งาน SMART และตรวจสอบคุณสมบัติที่สำคัญที่สุด:

• ย้ายเซกเตอร์_Ct: จำนวนเซกเตอร์ที่ถูกจัดสรรใหม่ หากมีค่ามากกว่า 0 แสดงว่าดิสก์นั้นเริ่มมีเซกเตอร์เสียแล้ว
• ภาคส่วนที่รอดำเนินการปัจจุบัน: ภาคส่วนที่รอการจัดสรรใหม่ ค่าใดๆ ที่มากกว่า 0 บ่งชี้ถึงความเสี่ยงสูงที่จะเกิดความล้มเหลวในเร็วๆ นี้
• ชั่วโมงการเปิดใช้งาน: จำนวนชั่วโมงการใช้งานสะสม ยิ่งตัวเลขสูง โอกาสที่ฮาร์ดดิสก์จะเสียก็ยิ่งมากขึ้น

การใช้คำสั่ง`smartctl -H /dev/sdX`จะช่วยให้คุณตรวจสอบได้อย่างรวดเร็วว่าดิสก์ผ่านหรือไม่ผ่านการทดสอบความสมบูรณ์ หากผลลัพธ์ไม่ใช่ "ผ่าน" คุณจำเป็นต้องสำรองข้อมูลของคุณโดยเร็วที่สุดและเริ่มพิจารณาเปลี่ยนดิสก์ใหม่

หากคุณสงสัยว่าอุณหภูมิสูง ให้ติดตั้ง lm- เซ็นเซอร์ และเรียกใช้ sensors (o watch -n 2 sensors (เพื่อดูข้อมูลแบบเรียลไทม์) สำหรับ SSD และไดรฟ์ SATA hddtemp มันแสดงอุณหภูมิปัจจุบันให้คุณเห็น ช่วยให้คุณตรวจจับอุปกรณ์ที่มีอุณหภูมิสูงขึ้นอย่างผิดปกติแม้ในขณะที่ไม่ได้ใช้งาน ซึ่งมีประโยชน์สำหรับ... การเพิ่มประสิทธิภาพเซิร์ฟเวอร์.

การวินิจฉัยฮาร์ดแวร์เฉพาะทางใน Linux

นอกจาก CPU, RAM และดิสก์แล้ว Linux ยังมีเครื่องมือเฉพาะสำหรับการประเมินหน่วยความจำ ECC, การ์ดเครือข่าย, GPU และส่วนประกอบอื่นๆการใช้เวลาเพียงไม่กี่นาทีในการตรวจสอบประเด็นเหล่านี้สามารถช่วยประหยัดเวลาในการแก้ไขปัญหาได้หลายชั่วโมง

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

dmesg | grep EDAC

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

เพื่อตรวจสอบโครงสร้างและความจุของหน่วยความจำ คำสั่ง`dmidecode -t memory`จะแสดงประเภทของโมดูล (DDR3, DDR4, DDR5) ความจุ แบงค์ที่ใช้งานอยู่ และอื่นๆ และด้วย คำสั่ง `dmidecode -t 16`คุณจะสามารถเห็นความจุ RAM สูงสุดที่เมนบอร์ดรองรับ ซึ่งมีประโยชน์หากคุณกำลังคิดที่จะอัปเกรด

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

สำหรับการวินิจฉัยปัญหาของดิสก์และไดรฟ์ USBนอกเหนือจากการใช้คำสั่ง lsblk และ fdisk -l เพื่อแสดงรายการอุปกรณ์แล้ว การใช้คำสั่งต่อไปนี้ร่วมกันจะมีประโยชน์มาก:

• df -h y df -i: เปอร์เซ็นต์การใช้งานพื้นที่และ inode; คุณอาจมีพื้นที่ว่างหลายกิกะไบต์ แต่ inode ถูกใช้งานไป 100% และระบบก็จะยังคงแจ้งเตือนว่า "พื้นที่ไม่เพียงพอ"
• fsck /dev/sdXN -y: ค้นหาและแก้ไขข้อผิดพลาดเชิงตรรกะในระบบไฟล์ (EXT2/3/4 และอื่นๆ)
• badblocks /dev/my_disk: สแกนหาเซกเตอร์ที่ชำรุดและทำเครื่องหมายไว้ เพื่อไม่ให้ระบบใช้งานเซกเตอร์เหล่านั้น (ขอแนะนำอย่างยิ่งให้สำรองข้อมูลก่อนดำเนินการนี้)

ในกรณีของการ์ดเครือข่ายอาการทั่วไปที่พบได้แก่ การตัดการเชื่อมต่อ ความล่าช้า หรือการสูญหายของแพ็กเก็ตโดยไม่ทราบสาเหตุ คุณสามารถใช้ethtoolเพื่อตรวจสอบสถิติ และnetstatเพื่อตรวจสอบอัตราการสูญหายของแพ็กเก็ต (RX-DRP และ TX-DRP) หากเปอร์เซ็นต์การสูญหายของแพ็กเก็ตเกินประมาณ0,2%ประสิทธิภาพของเครือข่ายจะได้รับผลกระทบอย่างชัดเจน และการ์ดเครือข่ายอาจมีข้อบกพร่องหรือไดรเวอร์ไม่รองรับอย่างเหมาะสม

ข้อผิดพลาดเกี่ยวกับพื้นที่ดิสก์เต็มและพื้นที่ไม่เพียงพอ: ข้อความคลาสสิก “ไม่มีพื้นที่เหลือบนอุปกรณ์”

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

ในสภาพแวดล้อมอย่างเช่น Azure เป็นเรื่องปกติที่จะเห็นข้อความลักษณะนี้ในคอนโซลหรือในการวินิจฉัยการเริ่มต้นระบบ:

• ไม่มีพื้นที่เหลือบนอุปกรณ์ ใน cloud-init ซึ่งอาจป้องกันไม่ให้ VM บูตเสร็จสมบูรณ์
• ข้อความซ้ำจาก “พื้นที่ในอุปกรณ์เต็มแล้ว” ซึ่งส่งผลกระทบต่อบริการที่สำคัญ รวมถึงเอเจนต์บนคลาวด์
• พบข้อผิดพลาดในบันทึกระบบที่ระบุว่าไม่สามารถเขียนบันทึกการตรวจสอบหรือบันทึกเครือข่ายได้

เพื่อค้นหาสิ่งที่ครอบครองพื้นที่ได้อย่างรวดเร็ว คุณสามารถใช้คำสั่งต่างๆ เช่น:

• du -ks /* | sort -n: แสดงรายการไดเร็กทอรีรากเรียงตามขนาด และจะทำซ้ำในไดเร็กทอรีที่มีขนาดใหญ่ที่สุดจนกว่าจะพบต้นตอของปัญหา
• ls -altSr /var/log: แสดงไฟล์บันทึกที่เรียงลำดับตามขนาดจากเล็กที่สุดไปใหญ่ที่สุด คุณมักจะเห็นไฟล์บันทึกเก่าขนาดใหญ่ที่สามารถหมุนเวียนหรือลบได้
• find / -size +500M -exec ls -alFh {} \;: ค้นหาไฟล์ขนาดใหญ่แต่ละไฟล์ ปรับค่า 500M ตามความจำเป็น

นอกเหนือจากการที่ไฟล์ /var/log หรือ /tmp จะถูกเติมเต็มตามปกติแล้ว ยังมีการตั้งค่าด้านความปลอดภัยอื่นๆ อีกด้วย เช่น ตรวจสอบ ซึ่งอาจทำให้เครื่องดับหรือสตาร์ทไม่ติดเมื่อ พื้นที่ใน /var/log/audit เต็มแล้ว. ถ้าอยู่ใน /etc/audit/auditd.conf คุณมี:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

ระบบอาจปิดตัวลงอย่างเป็นระบบหรือปฏิเสธการบูตหากไม่สามารถเขียนลงในบันทึกการตรวจสอบได้ วิธีแก้ปัญหาชั่วคราวคือการเปลี่ยนค่าเหล่านั้นเป็นSUSPEND, IGNOREหรือตัวเลือกที่ถูกต้องอื่นๆ (ห้ามใช้ SINGLE ในบริบทนี้เด็ดขาด) เพื่อให้ระบบสามารถบูตและเพิ่มพื้นที่ว่างได้หลังจากแก้ไขปัญหาแล้ว คุณควรกลับไปใช้นโยบายเดิมหากจำเป็นต้องปฏิบัติตามข้อกำหนด

เมื่อไม่มีวิธีลบไฟล์เนื่องจากระบบไม่สามารถบูตได้ คุณสามารถใช้วิธีการกู้คืน ได้ เช่น คำสั่งซ่อมแซมระบบคลาวด์อัตโนมัติ (เช่น az vm repair ใน Azure) เครื่องเสมือนสำหรับการกู้คืน หรือโหมดผู้ใช้คนเดียวเพื่อเชื่อมต่อดิสก์และลบไฟล์ที่ไม่จำเป็นจนกว่าจะมีพื้นที่ว่างอย่างน้อย 10%ในระบบไฟล์ที่เก็บ /var/log และไดเร็กทอรีสำคัญอื่นๆ

ระบบไฟล์ EXT4 และ XFS เสียหาย: วิธีซ่อมแซมระบบไฟล์ที่เสียหาย

หากตอนเริ่มต้นระบบ คุณเห็นข้อความต่างๆ เช่น“EXT4-fs error (device sda1)” , “bad extra_isize” , “no journal found”หรือข้อความจาก XFS เช่น“Metadata CRC error detected… Unmount and run xfs_repair”แสดงว่านี่ไม่ใช่ปัญหาครั้งเดียว: ระบบไฟล์เสียหาย และจนกว่าคุณจะซ่อมแซมมัน เครื่องจะไม่สามารถบูตได้ตามปกติ

ขั้นตอนแรกคือการระบุว่าอุปกรณ์ใดได้รับผลกระทบในบันทึกการบูต ให้ดูข้อความที่ปรากฏในวงเล็บในข้อความเคอร์เนล: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname เป็นต้น ข้อความนี้จะบอกคุณว่าคุณกำลังจัดการกับพาร์ติชั่นโดยตรง (sdXN) หรือวอลุ่มลอจิคัล LVM (dm-N, /dev/vgname/lvname)

เมื่อคุณเข้าถึงเชลล์ได้แล้ว (โหมดฉุกเฉิน โหมดผู้ใช้คนเดียว หรือเครื่องกู้คืน) ให้รันคำสั่ง`lsblk -f`เพื่อดูโครงสร้างทั้งหมด: ดิสก์ พาร์ติชัน LVM และประเภทของระบบไฟล์ สิ่งสำคัญมากคือต้องตรวจสอบให้แน่ใจว่าพาร์ติชันนั้นเป็นext4, xfs, vfat, LVM2_memberฯลฯ จริงๆ และอย่าพึ่งพาเฉพาะข้อมูลจาก `/etc/fstab` เท่านั้น หากคุณสงสัยว่าอาจมีการตั้งค่าผิดพลาด

ในการซ่อมแซม ระบบไฟล์EXT4จะใช้ คำสั่ง fsckโดยทั่วไปแล้ว:

• ตรวจสอบให้แน่ใจว่าระบบไฟล์ถูกต้อง ไม่ได้ต่อเชื่อม (หากเป็นดิสก์ข้อมูล) หรือว่าคุณกำลังทำงานจากสภาพแวดล้อมการกู้คืนซึ่งไม่ได้ใช้งานดิสก์นั้นอยู่
• หอก fsck /dev/sdXN o fsck /dev/vgname/lvnameระบบจะถามคุณว่าต้องการแก้ไขความไม่สอดคล้องกัน สร้าง inode ใหม่ที่ปรับขนาดแล้ว ปรับตัวนับบล็อก ฯลฯ หรือไม่
• หากมีคำถามปรากฏขึ้นจำนวนมาก ให้กด CTRL+C เพื่อหยุดการทำงาน แล้วเริ่มการทำงานใหม่อีกครั้ง ฟสค์-วาย เพื่อให้ระบบตอบว่า "ใช่" โดยอัตโนมัติ ด้วยวิธีนี้คุณจะไม่พลาดอะไรเลย
• หากคุณย้ายไฟล์ไปที่ หาย+เจอคุณจะต้องตรวจสอบพวกมันอีกครั้งในภายหลังและนำพวกมันกลับไปวางไว้ที่เดิม
• เรียกใช้ fsck อีกครั้งจนกว่าผลลัพธ์จะระบุว่าระบบไฟล์อยู่ในสภาพสมบูรณ์ ปลาเดยส์.

ในกรณีของXFSเครื่องมือที่ใช้คือxfs_repairขั้นตอนการทำงานโดยทั่วไปมีดังนี้:

• ขั้นแรก ตรวจสอบแบบแห้งก่อน: xfs_repair -n /dev/vgname/homelv เพื่อตรวจสอบความเสียหายโดยไม่ต้องดัดแปลงอะไรเลย
• หากการวิเคราะห์มีความสมเหตุสมผล ให้ทำซ้ำโดยไม่ต้องใส่ -n เพื่อให้ระบบพยายามแก้ไข: xfs_repair /dev/vgname/homelv.
• หากคำสั่งแจ้งว่าระบบไฟล์มี "การเปลี่ยนแปลงเมตาเดต้าที่มีค่าในบันทึกที่ต้องทำซ้ำ" ให้ลองเมานต์ระบบไฟล์ดู: ในระบบ XFS การเปลี่ยนแปลงที่รอการดำเนินการจำนวนมากจะถูกนำไปใช้ทันทีที่เมานต์ หากคุณอยู่ในเครื่องเสมือนกู้คืน คุณสามารถทำเช่นนี้ได้ในจุดใดจุดหนึ่งเช่น... /recovery.
• หากไม่มีวิธีอื่นและข้อผิดพลาดในบันทึกไม่ได้รับการแก้ไข ทางเลือกสุดท้ายคือการใช้ xfs_repair -L เพื่อยกเลิกบันทึกการเปลี่ยนแปลงและบังคับให้ทำการประกอบใหม่ราวกับว่าการเปลี่ยนแปลงทั้งหมดได้ถูกนำไปใช้แล้ว วิธีนี้อาจทำให้ข้อมูลล่าสุดสูญหาย ดังนั้นควรใช้เป็นวิธีสุดท้ายเท่านั้น

ในทุกกรณี สิ่งสำคัญคือต้องเข้าใจว่าfsck และ xfs_repair ไม่ใช่เวทมนตร์ : มันแก้ไขโครงสร้างของระบบไฟล์ได้ แต่ไม่สามารถกู้คืนข้อมูลทั้งหมดได้เสมอไป นั่นเป็นเหตุผลว่าทำไมการสำรองข้อมูลก่อนหน้านี้จึงมีความสำคัญมาก และหากคุณใช้งานบนคลาวด์หรือเครื่องเสมือน (VM) คุณควรทำงานจากสแนปช็อตของดิสก์หรือสำเนาที่แนบมากับเครื่องกู้คืน

GRUB, UEFI, Secure Boot และระบบบูตแบบคลาสสิกอื่นๆ

เมื่อคุณเปิดคอมพิวเตอร์แล้วไม่เห็นเมนู GRUB หรือ BIOS/UEFI แสดงข้อผิดพลาดเช่น"Failed to open \EFI\ubuntu\grubx64.efi - Not found"และเข้าสู่ลูปพยายามบูตจากรายการนั้น ปัญหาเกือบจะแน่นอนว่าอยู่ที่ตัวจัดการการบูตหรือการกำหนดค่าเฟิร์มแวร์

ข้อผิดพลาดเหล่านี้อาจเกิดขึ้นหลังจากติดตั้ง Windows ในการกำหนดค่าแบบ dual-boot (ซึ่งมักจะเข้าควบคุม MBR หรือเขียนทับรายการ UEFI) หลังจากลบพาร์ติชั่น EFI โดยไม่ตั้งใจ หรือหลังจากแก้ไขลำดับการบูตใน BIOS บนแล็ปท็อปรุ่นใหม่ๆ ไม่ใช่เรื่องแปลกที่เครื่องจะรีบูตวนซ้ำหากรายการ UEFI "ubuntu" ชี้ไปยังไฟล์ที่ไม่มีอยู่อีกต่อไปและพยายามโหลดไฟล์นั้น

วิธีที่ง่ายที่สุดในการซ่อมแซมบูตโหลดเดอร์ GRUB ที่เสียหายคือการบูตจากระบบปฏิบัติการแบบ Live (เช่น Ubuntu)และใช้ เครื่องมือ Boot-Repairขั้นตอนทั่วไปมีดังนี้:

• เริ่มต้นจาก ยูเอสบีไลฟ์ และเปิดเทอร์มินัล
• เพิ่มที่เก็บข้อมูลและอัปเดต: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• ติดตั้งเครื่องมือ: sudo apt install -y boot-repair.
• เรียกใช้ด้วย boot-repair และเลือกตัวเลือกของ “การซ่อมแซมที่แนะนำ”.

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

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

ในกรณีเหล่านี้ วิธีแก้ปัญหามักจะเกี่ยวข้องกับการเข้าถึงการตั้งค่า UEFI เปิดใช้ งานโหมด Legacy/CSMเพื่อให้สามารถบูตแบบ BIOS ดั้งเดิมได้ และปิดใช้งาน Secure Bootอย่างไรก็ตามหากคุณใช้ Windows 11 บนคอมพิวเตอร์เครื่องนั้นด้วย หรือต้องการย้ายจาก Windows ไปยัง Linuxการปิดใช้งาน Secure Boot อาจทำให้ข้อกำหนดการบูตของ Windows เสียหายได้ ดังนั้นคุณควรพิจารณาว่าระบบใดมีความสำคัญกว่า หรือมองหา Linux เวอร์ชันที่เข้ากันได้กับ Secure Boot เพื่อหลีกเลี่ยงการเข้าถึง BIOS ทุกครั้ง

ฟังก์ชัน Fast Boot ของ Windows ยังก่อให้เกิดปัญหาในสถานการณ์การใช้งานระบบปฏิบัติการสองระบบพร้อมกัน (dual-boot) ด้วย เมื่อปิดเครื่องโดยเปิดใช้งาน Fast Boot ไว้ Windows จะไม่ปิดเครื่องอย่างสมบูรณ์: มันจะเหลือส่วนหนึ่งของเคอร์เนลไว้ในสถานะจำศีลบนดิสก์ ทำให้ไม่สามารถเข้าถึงระบบไฟล์ NTFS ได้อย่างเต็มที่ เมื่อ Linux พยายามเมานต์พาร์ติชันเหล่านี้ อาจเกิดข้อผิดพลาดหรือระบบอาจค้างได้ ขอแนะนำให้ปิดใช้งาน Fast Boot ทั้งในตัวเลือกการจัดการพลังงานของ Windowsและหาก UEFI ของคุณอนุญาต ก็ให้ปิดใช้งานใน BIOS ด้วย

การใช้งานโหมดการกู้คืนและเครื่องมือซ่อมแซมในตัว

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

เมนู GRUB มักจะมีรายการที่เรียกว่า " ตัวเลือกขั้นสูง " หรืออะไรทำนองนั้น ภายในนั้น คุณจะเห็นเวอร์ชันเคอร์เนลที่มีอยู่ทั้งหมด และสำหรับแต่ละเวอร์ชันจะมีโหมดการกู้คืนเลือกโหมดการกู้คืนสำหรับเวอร์ชันล่าสุด (และหากไม่ได้ผล ให้ลองเวอร์ชันก่อนหน้า)

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

• ฟคตรวจสอบและซ่อมแซมระบบไฟล์ (คล้ายกับคำสั่ง chkdsk ใน Windows)
• ปลาเดยส์: เพิ่มพื้นที่ว่างโดยการลบไฟล์ชั่วคราวและไฟล์ตกค้างอื่นๆ
• dpkg: แก้ไขแพ็กเกจที่เสียหาย, ความต้องการที่ไม่ตรงกัน หรือการติดตั้งที่ค้างอยู่
• ด้วง: สร้างการกำหนดค่าตัวจัดการบูตขึ้นใหม่

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

ในระบบคลาวด์อย่างAzureนอกเหนือจากโหมดฉุกเฉินและโหมดผู้ใช้คนเดียวแล้ว คุณยังมีเครื่องมือเฉพาะ เช่นAzure Linux Automatic Repair (ALAR) และ คำสั่งaz vm repairซึ่งจะช่วยทำให้กระบวนการบางส่วนเป็นไปโดยอัตโนมัติ กล่าวคือ จะทำการเมานต์ดิสก์ระบบใน VM สำหรับกู้คืน เรียกใช้คำสั่งต่างๆ เช่น “auditd” เพื่อแก้ไขการกำหนดค่าทั่วไป และช่วยให้คุณสามารถย้อนกลับได้อย่างง่ายดายหากเกิดข้อผิดพลาด

กลยุทธ์ในการติดตั้ง Linux ใหม่โดยไม่สูญเสียข้อมูล

ในบางสถานการณ์ ไม่ว่าคุณจะตรวจสอบอย่างละเอียดแค่ไหน ระบบก็อาจเสียหายอย่างหนัก หรือฮาร์ดแวร์ของคุณอาจผิดปกติ (เช่นHP N150หรือแล็ปท็อปรุ่นใหม่ที่มีคอนโทรลเลอร์แปลกๆ) วิธีที่สมเหตุสมผลที่สุดคือการติดตั้งระบบปฏิบัติการใหม่อย่างไรก็ตาม การทำเช่นนั้นไม่ได้หมายความว่าคุณจะสูญเสียข้อมูลทั้งหมดเสมอไป

ระบบปฏิบัติการ Linux หลายตัว เช่น Ubuntu และระบบปฏิบัติการที่พัฒนาต่อยอดจาก Ubuntu มีตัวเลือกในระหว่างการติดตั้งที่เรียกว่า"ติดตั้งระบบปฏิบัติการใหม่โดยเก็บเอกสารและการตั้งค่าไว้ " ตัวเลือกนี้จะติดตั้งระบบพื้นฐานใหม่ แต่พยายามรักษาโฟลเดอร์ /home ของคุณไว้ และบางครั้งอาจรวมถึงแอปพลิเคชันที่ติดตั้งไว้บางส่วนด้วย นี่เป็นตัวเลือกที่สะดวก แต่ก็ไม่ปลอดภัย 100% ดังนั้นจึงควรสำรองข้อมูลที่คุณไม่ต้องการสูญเสีย ด้วยตนเอง

วิธีที่มีประสิทธิภาพที่สุดในการป้องกันการติดตั้งระบบใหม่ในอนาคตคือการแบ่งดิสก์ออกเป็นพาร์ติชั่นแยกกัน หลายส่วน :

• หนึ่งสำหรับ / (ราก): ระบบพื้นฐาน
• อีกหนึ่งรายการสำหรับ / boot (และ /boot/efi ใน UEFI) หากคุณต้องการควบคุมการบูตมากขึ้น
• ส่วนพิเศษสำหรับ / หน้าแรก หรือเพื่อเก็บข้อมูล

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

ในเครื่องเสมือน ไม่ว่าจะเป็นจาก VirtualBox, VMware หรือระบบคลาวด์ การแยกดิสก์ข้อมูลออกจากดิสก์ระบบ นั้นเป็นแนวคิดที่ดี ตัวอย่างเช่น ใน Azure แนะนำว่าไม่ควรใช้ LVM data volumes ในกลุ่มวอลุ่มเดียวกันกับดิสก์ระบบ เพื่อป้องกันไม่ให้ความล้มเหลวของระบบปฏิบัติการส่งผลกระทบต่อข้อมูลด้วย

แนวทางปฏิบัติที่ดีที่สุดในการป้องกันปัญหาไม่ให้เกิดขึ้นซ้ำอีก

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

ข้อแรกคือการอัปเดตระบบและซอฟต์แวร์ของคุณให้ทันสมัยอยู่เสมอแต่ควรทำอย่างรอบคอบ ในระบบปฏิบัติการแบบ rolling release เช่น Arch การอัปเดตบ่อยๆ เป็นสิ่งจำเป็น ในระบบปฏิบัติการแบบอนุรักษ์นิยมมากกว่า (Debian Stable, Ubuntu LTS) คุณสามารถเว้นระยะการอัปเดตได้บ้าง แต่ไม่แนะนำให้ปล่อยทิ้งไว้โดยไม่อัปเดตเป็นเวลาหลายปี ก่อนที่จะมีการเปลี่ยนแปลงเคอร์เนลหรือเวอร์ชันหลัก ควรทำการสำรองข้อมูลอย่างดีเสมอ

อีกหนึ่งนิสัยที่ดีต่อสุขภาพมากคือ บันทึกการเปลี่ยนแปลงการกำหนดค่าที่สำคัญใดๆ: ไฟล์ที่คุณแก้ไข บรรทัดที่คุณเปลี่ยนแปลง และไฟล์นั้นเป็นอย่างไรก่อนหน้านี้ เทคนิคอย่างง่ายคือการบันทึกสำเนาของไฟล์ต้นฉบับโดยเพิ่มคำต่อท้ายเสมอ บาก (ตัวอย่างเช่น sshd_config.bak) ดังนั้นคุณจึงสามารถกู้คืนได้ง่ายหากคุณทำผิดพลาด

ในส่วนของข้อมูลการสำรองข้อมูลเป็นประจำนั้น จำเป็นอย่างยิ่ง คุณสามารถใช้ rsync สำหรับการสำรองข้อมูลแบบเพิ่มทีละส่วน (incremental backups) ใช้ tar เพื่อบีบอัดทั้งไดเร็กทอรี หรือใช้โซลูชันบนคลาวด์และ NAS นอกจากนี้ หากข้อมูลของคุณอยู่ในพาร์ติชันที่แตกต่างจากพาร์ติชันระบบ คุณสามารถติดตั้งระบบใหม่ได้โดยไม่ยุ่งยากมากนัก แม้ว่าดิสก์จะไม่สามารถบูตได้ก็ตาม

สุดท้ายนี้ การตรวจสอบสถานะของระบบอย่างสม่ำเสมอถือเป็นสิ่งที่ดีเสมอ: ตรวจสอบ SMART ทุกเดือน ตรวจสอบinode และพื้นที่ว่างในพาร์ติชั่นที่สำคัญ (/, /var, /home) ดูบันทึกการทำงานเพื่อหาข้อความที่ซ้ำกัน และรักษาอุณหภูมิและระดับฝุ่นบนอุปกรณ์ให้อยู่ในระดับที่เหมาะสม การบำรุงรักษาอย่างง่ายๆ จะช่วยประหยัดเวลาในช่วงเช้าตรู่ในการแก้ไขปัญหาเครื่องที่ "หยุดทำงานโดยไม่คาดคิด" ได้มากมาย

ด้วยชุดเทคนิค คำสั่ง และแนวทางปฏิบัติที่ดีที่สุดเหล่านี้ การวินิจฉัยและแก้ไขปัญหาการบูตและข้อผิดพลาดของฮาร์ดแวร์ใน Linuxจึงไม่ใช่เรื่องที่ต้องอาศัยความเชื่ออีกต่อไป แต่กลายเป็นกระบวนการที่สมเหตุสมผลมากขึ้น: ขั้นแรก คุณต้องระบุว่าความล้มเหลวเกิดจากดิสก์ ระบบไฟล์ GRUB เคอร์เนล การกำหนดค่า หรือฮาร์ดแวร์ จากนั้นใช้เครื่องมือที่เหมาะสม (fsck, xfs_repair, Boot-Repair, smartctl, MemTest, โหมดการกู้คืน ฯลฯ) และในกรณีที่เลวร้ายที่สุด คุณจะมีแผนสำรองที่จัดระเบียบไว้อย่างดี พร้อมพาร์ติชั่นและข้อมูลสำรองที่แยกต่างหาก ซึ่งช่วยให้คุณสามารถติดตั้งใหม่ได้โดยไม่ต้องกลัวว่าโลกจะแตก