การช่วยเหลือด้วงบน Ubuntu 18.04 พร้อมพาร์ติชัน btrfs

ฉันมีเซิร์ฟเวอร์ขนาดเล็ก (HP ProLiant MicroServer Gen8) ที่ใช้ Ubuntu 18.04 64 บิตด้วย เคอร์เนลทั่วไป HWE ล่าสุด (5.4.0.74.83~18.04.67); มีไดรฟ์ SATA สองตัวแบ่งพาร์ติชัน GPT แต่บูตในโหมด BIOS เดิม ไดรฟ์ทั้งสองถูกแบ่งพาร์ติชันดังนี้:

• พาร์ติชัน 1 (1 MB): พาร์ติชันสำหรับบูต "shadow" สำหรับรหัส GRUB;
• พาร์ติชัน 2 (หลาย TB): BtrFS ที่มี @ ปริมาณย่อยสำหรับ / และ @บ้าน ปริมาณย่อยสำหรับ /บ้าน; /บูต อยู่ภายใต้ //@/บูต
• พาร์ติชัน 3 (4 GB): สลับ

พาร์ติชัน BtrFS ของทั้งสองไดรฟ์เชื่อมโยงกันในการกำหนดค่ามิเรอร์ BtrFS

ไฟฟ้าดับไปสองสามวันและ NAS ก็ไม่เคยฟื้นตัว ตอนบูต ฉันเพิ่งได้รับ "grub Rescue" ที่น่าหวาดกลัว โดยบอกว่าไม่พบพาร์ติชันเป้าหมาย (ฉันคิดว่าระบุด้วย BtrFS Volume GUID) กำลังพยายามทำ ls (hd0,gpt2) (หรือพาร์ติชันอื่น ๆ จริงๆ) บอกฉันว่า "ระบบไฟล์ที่ไม่รู้จัก" (แม้ว่า insmod btrfs ดูเหมือนว่าจะทำงานได้อย่างถูกต้อง)

เมื่อคิดว่ามีบางอย่างถูกผัดกับของ GRUB ฉันบูตด้วยคีย์การติดตั้งเซิร์ฟเวอร์ Ubuntu 18.04 และพยายามซ่อมแซม GRUB ดังนี้:

• เมานต์ /dev/sda2 /mnt (/dev/sda2 เป็นพาร์ติชัน BtrFS); ฉันเห็นว่าข้อมูลทั้งหมดยังคงอยู่
• เมานต์ --bind /dev /mnt/@/dev; เหมือนกันสำหรับ /dev/pts, /proc, /ระบบ, /วิ่ง (ไม่เช่นนั้น DNS ที่จัดการโดย resolvconf ทั้งในระบบที่ใช้งานจริงและระบบ "เสีย" จะไม่ทำงาน)
• chroot /mnt/@
• ข้างใน chroot ฉันทำ เมานต์ /dev/sda2 / -o subvol=@ มิฉะนั้น หัววัดด้วง/ติดตั้งด้วง จะสับสน; นอก chroot ให้ทำซ้ำสิ่งผูกมัดตามที่ถูกบดบังด้วยรีเมาท์
• เมานต์ -a

จากนั้น (จากการลองหลายครั้ง) ฉันลองหลายสิ่งหลายอย่าง:

• ติดตั้ง GRUB ใหม่เป็น /dev/sda (ด้วงติดตั้ง /dev/sda); พยายามด้วย --recheck และไม่มีพยายาม ด้วง-mkdevicemap (การถอดอุปกรณ์คีย์ USB ออกจากอุปกรณ์ที่สร้างขึ้นด้วยตนเอง อุปกรณ์ แผนที่ ไฟล์);
• สร้างการกำหนดค่าด้วงใหม่ (ปรับปรุงด้วง);
• อัปเกรดเคอร์เนลโดยไม่คิดว่าเป็นปัญหาเวอร์ชันเคอร์เนลมากนัก แต่เพื่อให้แน่ใจว่า (1) ฉันกำลังพยายามบู๊ตบางสิ่งที่ไม่เสียหายอย่างแน่นอนและ (2) เพื่อเริ่มต้นใหม่
• ตรวจสอบว่าไฟล์ kernel/initrd สามารถอ่านได้ทั้งหมดหรือไม่ (เช่น with sha1sum /boot/*) เนื่องจากข้อความของ GRUB เกี่ยวกับสิ่งนั้นน่ากลัว - ดูภายหลัง
• ดาวน์เกรด GRUB (ซึ่งเป็นเวอร์ชันล่าสุด 2.02 ที่มีอยู่ใน repos) เป็นการแก้ไขแพตช์เล็กน้อยก่อนหน้านี้ เนื่องจากฉันสงสัยว่าการสูญเสียพลังงานไม่ได้ทำอะไรกับมันมากนัก แต่เป็นการอัปเกรดบางอย่างที่ทำลายมันแทน
• วิ่ง ตรวจสอบ btrfs /dev/sda2.dll และ ตรวจสอบ btrfs /dev/sdb2; ทั้งคู่ทำงานโดยไม่มีข้อผิดพลาด ปัญหาเดียว (รายงานสำหรับทั้งคู่) อยู่ในแคชพื้นที่ว่างของบล็อกเดียว (ฉันติดตั้งในภายหลัง /dev/sda2/ กับ clear_cache ตัวเลือกเพียงเพื่อความแน่ใจ)

ผลลัพธ์จากสิ่งทั้งหมดนี้ยังห่างไกลจากกำลังใจ: เมื่อทำอย่างถูกต้อง สิ่งนี้จะนำฉันไปสู่อีกครั้งเสมอ กู้ภัยด้วงแต่คราวนี้มีความน่าสนใจมากขึ้น:

• มัน สามารถ อ่านปริมาณ BtrFS บ้าง แต่พูดแทบไม่ได้ ทำ ls (hd0,gpt2)/ แสดง subvolumes แต่ทั้งสองอย่าง ls (hd0,gpt2)/@ และ ls (hd0,gpt2)/@บ้าน แสดงไดเร็กทอรีว่าง (ซึ่งเป็นสาเหตุที่หาไม่พบ (hd0,gpt2)/@/บูต/ แล้วทุกอย่างก็ต้องเข้าสู่โหมดปกติ);
• สิ่งที่น่าสนใจที่สุดคือมี subvolumes อื่น ๆ ได้แก่ สแน็ปช็อตสามชุดที่ทำโดยสคริปต์อัปเกรดเวอร์ชัน Ubuntu; เหล่านั้น ปริมาณย่อยแทน สามารถ อ่านโดย GRUB; ไม่เพียงแค่นั้น: ถ้าฉันปรับ คำนำหน้า, ราก & ร่วม เพื่อชี้ไปที่ภายในวอลุ่มย่อยของสแน็ปช็อต ฉันสามารถจัดการเพื่อเข้าสู่โหมด GRUB "ปกติ" และปรับพาธในรายการเมนูอีกครั้ง บูตเคอร์เนลเก่าที่อยู่ในสแน็ปช็อต (ปัญหาเดียวคือไม่พบโมดูล เนื่องจากฉันกำลังโหลดเคอร์เนลเวอร์ชันเก่าที่ไม่ได้ติดตั้งในระบบไฟล์รูทปัจจุบันอีกต่อไป แต่เนื่องจากไม่ได้ใช้จริง ๆ มันก็บู๊ตได้)

ครั้งหนึ่ง (เมื่อฉันอาจทำอะไรผิดพลาดในข้างต้น ภูเขา เต้นใน chroot) ฉันสามารถรีบูตและเข้าสู่โหมดปกติได้โดยตรง แต่ GRUB มักจะพบสิ่งที่ไม่ดีสำหรับรายการทั้งหมดในเมนูการบูต: โดยเฉพาะอย่างยิ่งสำหรับแต่ละรายการและทุกรายการนั้นไม่สามารถโหลดเคอร์เนลหรือ initrd ได้ ทำให้ ข้อความแสดงข้อผิดพลาด "inode not found" ที่น่ากลัว (หรือในอีกกรณีหนึ่งคือ "ไม่พบตัวอธิบายก้อน" ทั้งสองอย่างนี้ไม่ตรงกันใน Google นอกจากแหล่งที่มาของ GRUB ซึ่งเป็นสัญญาณที่ไม่ดีเสมอ) สังเกตได้ว่าอย่างที่ฉันได้กล่าวไปข้างต้น ภายในเซสชัน USB แบบสด พวกมันสามารถอ่านได้ทั้งหมด

ความคิดเพิ่มเติม:

• เมนบอร์ดเซิร์ฟเวอร์มีปัญหาแปลก ๆ เล็กน้อยกับคอนโทรลเลอร์ SATA - การแจงนับดิสก์ดูเหมือนจะใช้เวลานาน ซึ่งนำไปสู่ข้อผิดพลาดนี้เมื่อฉันอัปเกรดเป็น 18.04 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752961; การแก้ไข (เศร้า) เพียงอย่างเดียวคือการเพิ่มไฟล์ นอน5 ในเบื้องต้นก่อน btrfs สแกน; นอกจากนี้ยังนำไปสู่การมีดิสก์ที่สองเป็น /dev/sdc ใน บาง ของการเรียกใช้ USB สด แต่ดูเหมือนจะไม่สำคัญ (เมื่อมันเกิดขึ้นฉันก็ปรับชื่อไฟล์ด้วย /พัฒนาซึ่งดูเหมือนจะไม่เกี่ยวข้องกับผลลัพธ์มากนัก)
• ฉันคิดเกี่ยวกับ RAM ที่ไม่ดี แม้ว่ามันจะรู้สึกว่าไม่น่าเป็นไปได้เพราะ (1) เมื่อบูทระบบจะทำงานตามปกติและ (2) มันเป็น ECC RAM และฉันคาดว่าจะมีข้อความแสดงข้อผิดพลาดอย่างน้อยในกรณี อย่างไรก็ตาม ฉันเริ่มการทดสอบ MemTest และใช้เวลาหลายชั่วโมงที่การทดสอบทำงานโดยไม่มีข้อผิดพลาด
• iLO รายงานข้อผิดพลาดในการทดสอบตัวเองขณะบู๊ต ซึ่งดูเหมือนจะไม่เกี่ยวข้องกัน ข้อผิดพลาดได้รับการแก้ไขในภายหลังโดยอัปเกรดเป็นเฟิร์มแวร์เวอร์ชันล่าสุดและล้าง NVRAM ตามที่คาดไว้ สิ่งนี้ไม่ได้สร้างความแตกต่างเลย แต่อย่างน้อยหน้าจอ POST ก็สะอาดขึ้นเล็กน้อย

การเดาในปัจจุบันของฉันเป็นดังนี้: เคอร์เนล HWE ใช้เวอร์ชัน BtrFS ที่มีคุณลักษณะบางอย่างที่เข้ากันไม่ได้กับเวอร์ชัน "ปกติ" ของ Ubuntu 18.04 GRUB ดังนั้นไฟล์/ไดเร็กทอรีทั้งหมดที่เขียน "ตอนนี้" อาจเป็นปัญหาสำหรับ GRUB ในการอ่าน; ฉันเห็นว่าระหว่าง GRUB 2.02 และเวอร์ชันปัจจุบัน (2.06) มีงานบางอย่างเกี่ยวกับ BtrFS แม้ว่าสำหรับการบีบอัด zstd นั้นไม่ได้เปิดใช้งานบนดิสก์ของฉัน บางทีการลองใช้ GRUB ที่ใหม่กว่านี้อาจช่วยแก้ปัญหาได้ แต่มี GRUB 2.06 build บางตัวที่ใช้งานได้กับ 18.04 หรือไม่?

เรื่องสั้นสั้น: มีความคิดเกี่ยวกับปัญหาที่อาจเกิดขึ้นและจะแก้ไขได้อย่างไร

ความคิดใด ๆ เกี่ยวกับปัญหาที่อาจเกิดขึ้น

ไม่จริง แม้ว่าฉันจะแบ่งปันความสงสัยของคุณว่า grub และ btrfs อาจเล่นด้วยกันได้ไม่ดีนัก

และจะแก้ไขอย่างไร?

คุณคิดว่าจะช่วยตัวเองให้ปวดหัวและย้าย /บูต นอก btrfs?

คุณสามารถแกะสลักพื้นที่ได้เล็กน้อย (ลดขนาดพาร์ติชั่น swap ลง 1G - การแลกเปลี่ยนถูก overrated อยู่ดี) และรับตัวเองใหม่ /บูต พาร์ติชันของ 1G พิเศษนี้

สำหรับความซ้ำซ้อนของดิสก์คุณสามารถใช้ซอฟต์แวร์ Raid1 ได้ - grub รองรับได้ค่อนข้างดี

คุณจะสูญเสียความสามารถสแน็ปช็อตสำหรับ /บูต, แม้ว่า /บูต มีขนาดเล็กพอที่จะมีวิธีอื่นในการกู้คืน