2012-03-31 Debian Wheezy บิลด์รายวันใน VirtualBox 4.1.2, อุปกรณ์ดิสก์ 6 ตัว

ขั้นตอนของฉันในการทำซ้ำ:

  1. ตั้งค่าหนึ่งพาร์ติชัน โดยใช้ทั้งดิสก์เป็นฟิสิคัลวอลุ่มสำหรับ RAID ต่อดิสก์
  2. ตั้งค่าอาร์เรย์ mdraid RAID6 เดียวจากทั้งหมด
  3. ใช้ md0 ที่เป็นผลลัพธ์เป็นฟิสิคัลวอลุ่มเดียวสำหรับกลุ่มวอลุ่ม
  4. ตั้งค่าโลจิคัลวอลุ่ม ระบบไฟล์ และจุดเชื่อมต่อตามที่คุณต้องการ
  5. ติดตั้งระบบของคุณ

ทั้ง / และ /boot จะอยู่ในสแต็กนี้ ฉันเลือก EXT4 เป็นระบบไฟล์สำหรับการตั้งค่านี้

ฉันสามารถไปถึงคอนโซลช่วยเหลือของ GRUB2 ซึ่งสามารถมองเห็น mdraid กลุ่มวอลุ่มและโลจิคัลวอลุ่ม LVM (ทั้งหมดตั้งชื่ออย่างเหมาะสมในทุกระดับ) แต่ฉันไม่สามารถ ls เนื้อหาของระบบไฟล์เหล่านั้นและฉันไม่สามารถบูตได้ จากพวกเขา.

เท่าที่ฉันเห็นจากเอกสารเวอร์ชันของ GRUB2 ที่จัดส่งมานั้นควรจัดการทั้งหมดนี้อย่างสง่างาม

http://packages.debian.org/wheezy/grub-pc (1.99-17 ณ เวลาที่เขียน)

กำลังโหลด ext2, raid, raid6rec, dosmbr (อันนี้อยู่ในรายการโมดูลหนึ่งครั้งต่อดิสก์) และโมดูล lvm ตามไฟล์ grub.cfg ที่สร้างขึ้น นอกจากนี้ยังกำหนดรายการของโมดูลที่จะโหลดสองครั้งในไฟล์ grub.cfg ที่สร้างขึ้นและตาม Googling อย่างรวดเร็วเกี่ยวกับสิ่งนี้ดูเหมือนจะเป็นบรรทัดฐานและตกลงสำหรับ GRUB2

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

ฉันผิดอะไรในสมมติฐานการใช้งานของฉันที่นี่

แก้ไข (2012-04-01) grub.cfg ที่สร้างขึ้นของฉัน:

http://pastie.org/3708436

ดูเหมือนว่าก่อนอื่นจะทำให้ /usr โลจิคัลวอลุ่มของฉันเป็นรูทและนั่นอาจเป็นสาเหตุของความล้มเหลว? ข้อผิดพลาด grub-mkconfig? หรือควรจะเข้าถึงสิ่งต่าง ๆ จาก /usr ก่อน / และ /boot? /boot เปิดอยู่ / สำหรับฉัน - ไม่มีโลจิคัลวอลุ่มสำหรับบูตแยกต่างหาก

answer

หลังจากที่ทุกคนมันเป็นข้อผิดพลาด Grub2 / ปัญหากับอาร์เรย์โจมตีซอฟต์แวร์เสื่อมโทรม

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

บังเอิญการติดตั้งใช้งานได้ (ในขณะนี้: 2012-06-26) ทันทีที่ออกจากกล่องใน Fedora 17, Arch (เสถียร) และ Gentoo (เสถียร + grub2 bzr ล่าสุดผ่าน Portage): Grub2 2.0+ ได้แก้ไขปัญหาแล้ว ด้วยการหยุดทำงานของ Wheezy ในไม่ช้า ฉันหวังว่าปัญหาจะได้รับการแก้ไขผ่านการข้ามไปที่ 2.0 หรือแบ็คพอร์ตการแก้ไข

สำหรับฉันสิ่งนี้ยังคงมีผลกับ Debian 6, 7; อูบุนตู 8.04, 10.04, 12.04.

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

โพสต์ที่ดีมาก ขอบคุณมาก สิ่งนี้ช่วยฉันได้มากในการติดตั้ง LVM - over - RAID บน Debian Wheezy นี่คือขั้นตอนที่ฉันใช้เพื่อเอาชนะปัญหา

อัปเดต Grub2 เป็น V2+

เพิ่มบรรทัดเหล่านี้ใน /etc/apt/sources.list

deb http://http.debian.net/debian unstable main
deb-src http://http.debian.net/debian unstable main

apt-get update

apt-get ติดตั้ง grub2

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

อัปเดต: ดังนั้น คำตอบนี้ผิด ฉันกำลังดูคู่มือ GRUB2 และพบส่วนนี้ซึ่งระบุว่า:

If, instead, you only get a rescue shell, this usually means that GRUB failed to load the ‘normal’ module for some reason. It may be possible to work around this temporarily: for instance, if the reason for the failure is that ‘prefix’ is wrong (perhaps it refers to the wrong device, or perhaps the path to /boot/grub was not correctly made relative to the device), then you can correct this and enter normal mode manually:

 # Inspect the current prefix (and other preset variables):
 set
 # Find out which devices are available:
 ls
 # Set to the correct value, which might be something like this:
 set prefix=(hd0,1)/grub
 set root=(hd0,1)
 insmod normal
 normal

However, any problem that leaves you in the rescue shell probably means that GRUB was not correctly installed. It may be more useful to try to reinstall it properly using grub-install device (see Invoking grub-install). When doing this, there are a few things to remember:

  1. Drive ordering in your operating system may not be the same as the boot drive ordering used by your firmware. Do not assume that your first hard drive (e.g. ‘/dev/sda’) is the one that your firmware will boot from. device.map (see Device map) can be used to override this, but it is usually better to use UUIDs or file system labels and avoid depending on drive ordering entirely.
  2. At least on BIOS systems, if you tell grub-install to install GRUB to a partition but GRUB has already been installed in the master boot record, then the GRUB installation in the partition will be ignored.
  3. If possible, it is generally best to avoid installing GRUB to a partition (unless it is a special partition for the use of GRUB alone, such as the BIOS Boot Partition used on GPT). Doing this means that GRUB may stop being able to read its core image due to a file system moving blocks around, such as while defragmenting, running checks, or even during normal operation. Installing to the whole disk device is normally more robust.
  4. Check that GRUB actually knows how to read from the device and file system containing /boot/grub. It will not be able to read from encrypted devices, nor from file systems for which support has not yet been added to GRUB.