วิธีการบูต Ubuntu Server เข้าสู่โหมดฉุกเฉิน: คู่มือการกู้คืนทีละขั้นตอน

สถานการณ์จำลอง:เคซีย์ดูแลเครื่องเสมือน Ubuntu Server ที่สมมติว่าเครื่องนั้นเข้าสู่โหมดฉุกเฉินหลังจากรีบูตเครื่องได้ไม่นาน หลังจากที่เพิ่มการเชื่อมต่อไดรฟ์ข้อมูลเสริมเข้าไป/etc/fstabเคซีย์สามารถเข้าถึงคอนโซลได้ แต่ไม่มีเซสชัน SSH การเปลี่ยนแปลงการเชื่อมต่อไดรฟ์ข้อมูลเป็นเพียงเบาะแส ไม่ใช่สาเหตุที่พิสูจน์ได้: โหมดฉุกเฉินอาจเกิดขึ้นหลังจากความล้มเหลวในการบูตหลายครั้ง ดังนั้นเคซีย์จึงตรวจสอบบันทึกของเครื่องปัจจุบันก่อนที่จะเปลี่ยนแปลงอะไร แผงเทอร์มินัลด้านล่างแสดงเค้าโครงตัวอย่างและผลลัพธ์ที่เป็นตัวแทน ไม่ใช่การซ่อมแซมหรือการทดสอบจริง

โหมดฉุกเฉินหมายความว่าอย่างไร

ในการติดตั้ง Ubuntu Server โดยใช้ systemd คำสั่งนี้emergency.targetจะเริ่มต้นเชลล์แบบจำกัดบนคอนโซลหลัก ซึ่งมีข้อจำกัดมากกว่าrescue.targetคำสั่ง `update` ที่จะเริ่มต้นระบบพื้นฐานและเมานต์ระบบพร้อมบริการที่จำเป็นเท่านั้น ขึ้นอยู่กับเส้นทางที่เข้าสู่โหมดฉุกเฉิน ระบบไฟล์รูทอาจถูกเมานต์แบบอ่านอย่างเดียวหรืออ่านเขียนก็ได้ ตรวจสอบสถานะแทนที่จะสันนิษฐานเอาเอง ดูเอกสารประกอบของ systemd special-targetต้นฉบับ เพิ่มเติม

ขั้นแรก ให้แยกแยะข้อความแจ้งเตือนก่อน โดยปกติแล้ว ข้อความแจ้งเตือนฉุกเฉินของ systemd จะแสดงข้อความว่า “ยินดีต้อนรับสู่โหมดฉุกเฉิน!” และอาจขอรหัสผ่าน root สำหรับการบำรุงรักษา ข้อความแจ้งเตือนของ BusyBox เช่น(initramfs)หมายความว่าการบูตยังไม่ได้เปลี่ยนไปใช้ระบบไฟล์ root ที่ติดตั้งไว้ ข้อความ แจ้งเตือน grub>หรือgrub rescue>แสดงว่ามีปัญหาเกี่ยวกับบูตโหลดเดอร์ ซึ่งต้องใช้เส้นทางการกู้คืนที่แตกต่างกัน หากบัญชี root ถูกล็อกหรือเซิร์ฟเวอร์อยู่ระยะไกล ให้ใช้คอนโซล serial/VNC หรือสภาพแวดล้อมการกู้คืนของผู้ให้บริการโฮสติ้ง โดยปกติแล้ว SSH จะไม่สามารถใช้งานได้ในขั้นตอนนี้ อย่ากด Ctrl+D เพื่อดำเนินการต่อจนกว่าคุณจะเข้าใจและแก้ไขข้อผิดพลาดที่รายงาน

การช่วยเหลือทีละขั้นตอน

1. รักษาการเข้าถึงคอนโซลและบันทึกข้อผิดพลาดที่เกิดขึ้นอย่างแม่นยำ

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

2. อ่านบันทึกการบูตปัจจุบันและหน่วยที่ล้มเหลว

ในเชลล์ฉุกเฉิน ให้รันคำสั่ง:

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-bจำกัดการค้นหาบันทึกข้อผิดพลาดเฉพาะการบูตครั้งนี้ และ-p errกรองตามลำดับความสำคัญของข้อผิดพลาดขึ้นไป มองหาข้อผิดพลาดที่เกี่ยวข้องเป็นครั้งแรก ไม่ใช่เพียงแค่ข้อความ "การพึ่งพาไม่สำเร็จ" ที่เรียงลำดับกันล่าสุด หากหน่วยการเมานต์ล้มเหลว ให้จดบันทึกชื่อหน่วยที่ถูกแปลงและเส้นทางเป้าหมาย หากบริการล้มเหลว ให้ระบุว่าเป็นสาเหตุหรือเป็นเพียงผลที่ตามมาจากการเมานต์ที่หายไปjournalctl(1)คู่มือ ของ Ubuntu อธิบายการบูตและการกรองหน่วยไว้

3. ตรวจสอบไดเร็กทอรีหลักและพื้นที่ว่างที่มีอยู่

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

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

ในfindmntผลลัพธ์roหมายถึงอ่านอย่างเดียว และrwหมายถึงอ่านและเขียนได้ รูทที่อ่านอย่างเดียวอาจเป็นไปโดยเจตนาในระหว่างขั้นตอนการกู้คืน หรืออาจสะท้อนถึงปัญหาของระบบไฟล์ อย่าบังคับการเมานต์ใหม่เป็นแบบอ่านและเขียนทันทีหากบันทึกของเคอร์เนลรายงานข้อผิดพลาด I/O หรือระบบไฟล์ ระบบไฟล์เต็มหรือตาราง inode หมดอาจทำให้บริการและการเมานต์ที่ไม่เกี่ยวข้องล้มเหลวได้เช่นกันfindmnt(8)คู่มือ Ubuntu อธิบายวิธีการตรวจสอบระบบไฟล์ที่เมานต์ไว้

4. ตรวจสอบ/etc/fstabและยืนยันรหัสประจำตัวอุปกรณ์

เนื่องจาก Casey เพิ่งมีการเปลี่ยนแปลง/etc/fstabโปรดตรวจสอบทั้งไวยากรณ์และตรวจสอบว่าอุปกรณ์ที่อ้างถึงมีอยู่จริงหรือไม่:

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verboseตรวจสอบรายการในไฟล์ fstab เพื่อหาปัญหาในการแยกวิเคราะห์และการใช้งาน เปรียบเทียบทุกรายการUUID=ในแถวที่ต้องสงสัยกับ UUID ที่แสดงโดยlsblk -fหรือblkidตรวจสอบจุดเชื่อมต่อ ประเภทของระบบไฟล์ และตัวเลือกต่างๆ ด้วย UUID ที่คัดลอกมาจากดิสก์อื่น อุปกรณ์ที่ไม่ได้เชื่อมต่อ หรือตัวเลือกที่ไม่ถูกต้อง อาจทำให้การเชื่อมต่อที่จำเป็นไม่เสร็จสมบูรณ์ อย่าเดาพาร์ติชั่น เช่น/dev/sda1; ชื่ออุปกรณ์อาจเปลี่ยนแปลงได้ระหว่างการบูต

5. แก้ไขเฉพาะปัญหาการติดตั้งที่ได้รับการยืนยันแล้วเท่านั้น

หากระบบไฟล์รูทสามารถเขียนได้ และการตรวจสอบ fstab พบว่ามีแถวที่ไม่ถูกต้อง ให้ทำการสำรองข้อมูลก่อนทำการแก้ไข:

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

แก้ไข UUID หรือฟิลด์อื่นๆ หลังจากยืนยันอุปกรณ์ที่ต้องการแล้วเท่านั้น หากการเมานต์เป็นทางเลือกอย่างแท้จริง และเซิร์ฟเวอร์ควรยังคงบูตได้แม้ไม่มีวอลุ่มนั้น สามารถใช้บรรทัด fstab ที่รองรับ systemd nofailและกำหนดเวลาการรออุปกรณ์ที่แน่นอนได้ เช่น:

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

แทนที่ตัวยึดตำแหน่งด้วย UUID จริง และใช้ประเภทระบบไฟล์จริง อย่าเพิ่มnofailลงในรูท บูต หรือระบบไฟล์อื่นๆ ที่จำเป็นสำหรับเครื่องหรือแอปพลิเคชันในการทำงานอย่างถูกต้อง ด้วยวิธี นี้ การบูตจะดำเนินต่อไปแม้ว่าการเมานต์จะล้มเหลว ดังนั้นบริการที่เกี่ยวข้องอาจยังคงต้องการการดูแล คู่มือการเมานต์หน่วยระบบของnofail Ubuntu มีเอกสารเกี่ยวกับตัวเลือก fstab เหล่านี้

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

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

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

6. ตรวจสอบบริการที่ล้มเหลวเฉพาะเมื่อบันทึกชี้ไปที่บริการนั้นเท่านั้น

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

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

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

7. จัดการข้อผิดพลาดของระบบไฟล์เป็นงานซ่อมแซมแบบออฟไลน์

หากบันทึกเคอร์เนลรายงานความเสียหายของระบบไฟล์หรือข้อผิดพลาดในการอ่านเขียนข้อมูล ให้หยุดการเขียนข้อมูลเท่าที่จะทำได้ และทำการสำรองข้อมูลหรือสร้างสแนปช็อตจากผู้ให้บริการก่อนทำการซ่อมแซม ตรวจสอบอุปกรณ์และระบบไฟล์ที่แน่นอนด้วยคำสั่ง ` lsblk -fnpm install` สำหรับระบบไฟล์รูท ให้บูตเข้าสู่ระบบกู้คืนของผู้ให้บริการหรือสื่อกู้คืน/ไลฟ์ของ Ubuntu ตรวจสอบให้แน่ใจว่าพาร์ติชันเป้าหมายไม่ได้ถูกเมานต์อยู่ และใช้เครื่องมือตรวจสอบที่เหมาะสมกับระบบไฟล์นั้น สำหรับ ext2/3/4 เครื่องมือดังกล่าวคือe2fsck`npm install`; XFS, Btrfs และรูปแบบอื่นๆ มีขั้นตอนที่แตกต่างกัน

ห้ามเรียกใช้fsckคำสั่งใดๆe2fsckบนระบบไฟล์ที่ถูกเมานต์อยู่ รวมถึงไดเร็กทอรีรูทที่ถูกเมานต์แบบอ่านอย่างเดียวe2fsck(8)คู่มือ ของ Ubuntu เตือนว่าการตรวจสอบระบบไฟล์ที่ถูกเมานต์นั้นโดยทั่วไปไม่ปลอดภัยและผลลัพธ์ที่ได้จะไม่ถูกต้อง หากดิสก์รายงานข้อผิดพลาด I/O ซ้ำๆ ให้ให้ความสำคัญกับการกู้คืนข้อมูลหรือติดต่อผู้ให้บริการจัดเก็บข้อมูลมากกว่าการพยายามซ่อมแซมซ้ำๆ

8. กลับสู่โหมดบูตปกติและตรวจสอบผลลัพธ์

เมื่อแก้ไขสาเหตุที่ยืนยันแล้ว ให้รีบูตเครื่องจากคอนโซล:

systemctl reboot

หลังจาก Ubuntu เริ่มทำงานแล้ว ให้ตรวจสอบเป้าหมายเริ่มต้นที่กำหนดค่าไว้ สถานะระบบปัจจุบัน หน่วยที่ล้มเหลว และการบูตใหม่:

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

หากคุณตั้งใจดำเนินการต่อในการบูตปัจจุบันแทนsystemctl defaultระบบจะขอให้ systemd เริ่มเป้าหมายเริ่มต้นที่กำหนดค่าไว้ ใช้คำสั่งนี้หลังจากแก้ไขข้อผิดพลาดที่ขัดขวางแล้วเท่านั้น คำสั่งนี้จะไม่ซ่อมแซมการเมานต์ที่ไม่ถูกต้องหรือระบบไฟล์ที่เสียหายsystemctl get-defaultจะแสดงเป้าหมายเริ่มต้นที่กำหนดค่าไว้ และsystemctl is-system-runningรายงานว่า systemd พิจารณาสถานะปัจจุบันว่ากำลังทำงาน เสื่อมสภาพ หรือสถานะอื่น ๆ การกู้คืนที่สมบูรณ์หมายความว่าระบบไฟล์ที่คาดหวังได้รับการเมานต์ บริการที่จำเป็นทำงานอยู่ และสภาวะฉุกเฉินเดียวกันจะไม่เกิดขึ้นซ้ำอีกหลังจากรีบูต

หากข้อความแจ้งเตือนเป็น(initramfs)อย่างอื่น

อย่าทำตามขั้นตอนของ systemd emergency-shell ใน BusyBox initramfs โดยไม่คิดไตร่ตรอง ขั้นตอน initramfs พยายามค้นหาและเมานต์ระบบไฟล์รูทจริงก่อนที่จะส่งการควบคุมไปยังระบบที่ติดตั้ง บันทึกข้อผิดพลาดที่เกิดขึ้นอย่างละเอียด ตรวจสอบว่าอุปกรณ์ที่คาดหวังปรากฏใน/devและ/dev/disk/by-uuidและเปรียบเทียบค่าของบรรทัดคำสั่งบูตroot=กับ UUID รูทจริง หากดิสก์หรือวอลุ่มที่เข้ารหัส/LVM หายไป ให้ใช้เครื่องมือจัดเก็บข้อมูลและกู้คืนของผู้ให้บริการเพื่อตรวจสอบ การสร้าง initramfs ใหม่หรือการเปลี่ยนพารามิเตอร์ GRUB โดยไม่ระบุอุปกรณ์ที่หายไปอาจทำให้การกู้คืนการบูตทำได้ยากขึ้น

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