RAID6 mdraid – > LVM – > EXT4 root与GRUB2？

毕竟，这是一个Grub2 bug /问题与降级软件RAIDarrays 。

Grub2 1.9x在从降级arrays启动时遇到问题。 以救援模式启动系统并让RAID自行恢复已经解决了原来的设置问题。

顺便说一下，Fedora 17，Arch（stable）和Gentoo（稳定版+最新的grub2 bzr通过Portage）开箱即可（目前为2012-06-26）：Grub2 2.0+已经解决了这个问题。 随着Wheezy冻结很快，我彻底希望通过跳到2.0或backport修复解决问题。

对我来说，这仍然影响着Debian 6,7; Ubuntu 8.04,10.04,12.04。

让一个用户模式恢复设置的RAID同步是一个家庭系统的可接受的解决方法，但有一个潜在的额外的麻烦重新启动生产服务器（即使是一个小型的办公文件服务器）让人考虑三次。

非常好的post，非常感谢，这在Debian Wheezy上安装了一个LVM – RAID。 以下是我为解决问题所采取的步骤。

将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更新

apt-get install grub2

也许你已经把单个分区做得太大了，没有留出足够的空间用于安装GRUB2，并且已经覆盖了LVM空间的一部分。 一些长远的东西。 尝试你的步骤来重新创build你的问题，除了这次使用一个单一的磁盘（跳过RAID），创build单一的分区完全一样的，然后是其余的。 如果我是对的，那么你应该有同样的行为。

更新：所以，这个答案是错误的。 我正在浏览GRUB2手册，发现这个部分说：

如果您只获得一个救援shell，通常意味着GRUB由于某种原因无法加载“正常”模块。 暂时解决这个问题是可能的：例如，如果失败的原因是“前缀”是错误的（可能是指错误的设备，或者/ boot / grub的path相对于该设备），那么你可以纠正这一点，并手动进入正常模式：

  # 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 

但是，任何将救援shell中的问题都可能意味着GRUB安装不正确。 尝试使用grub-install设备正确地重新安装它可能会更有用（请参阅调用grub-install）。 这样做的时候，有几件事要记住：

1. 您的操作系统中的驱动器订购可能与您的固件使用的引导驱动器订购不同。 不要以为你的第一个硬盘（例如'/ dev / sda'）就是你的固件启动的硬盘。 可以使用device.map（请参见设备映射）来覆盖此设置，但通常使用UUID或文件系统标签会更好，并避免完全取决于驱动器的顺序。
2. 至less在BIOS系统上，如果告诉grub-install将GRUB安装到分区，但GRUB已经安装在主引导logging中，则分区中的GRUB安装将被忽略。
3. 如果可能，通常最好避免将GRUB安装到分区（除非它是单独使用GRUB的特殊分区，例如GPT上使用的BIOS引导分区）。 这样做意味着GRUB可能会由于文件系统移动块（如碎片整理，运行检查或正常操作期间）而无法读取其核心映像。 安装到整个磁盘设备通常更健壮。
4. 检查GRUB是否知道如何从包含/ boot / grub的设备和文件系统读取数据。 它将无法从encryption设备读取，也不能从支持尚未添加到GRUB的文件系统读取。