RAID6 mdraid - LVM - EXT4 raiz com o GRUB2?

Question

2012-03-31 O Debian Wheezy constrói diariamente no VirtualBox 4.1.2, 6 dispositivos de disco.

Meus passos para reproduzir até agora:

1. Configure uma partição, usando o disco inteiro, como um volume físico para RAID, por disco
2. Configure um único array RAID6 mdraid de todos esses
3. Use o md0 resultante como o único volume físico para o grupo de volumes
4. Configure seus volumes lógicos, sistemas de arquivos e pontos de montagem como desejar
5. Instale seu sistema

Ambos / e / boot estarão nesta pilha. Eu escolhi o EXT4 como meu sistema de arquivos para esta configuração.

Eu posso chegar até o console de resgate do GRUB2, que pode ver o mdraid, o grupo de volumes e os volumes lógicos do LVM (todos nomeados apropriadamente em todos os níveis) nele, mas não consigo o conteúdo do sistema de arquivos de nenhum deles. Não consigo arrancar deles.

Tanto quanto eu posso ver na documentação, a versão do GRUB2 deve lidar com tudo isso graciosamente.

link (1.99-17 no momento da escrita)

Ele está carregando o ext2, raid, raid6rec, dosmbr (este está na lista de módulos uma vez por disco) e módulos lvm de acordo com o arquivo grub.cfg gerado. Também está definindo a lista de módulos a serem carregados duas vezes no arquivo grub.cfg gerado e, de acordo com o Quick Googling, parece ser a norma e OK para o GRUB2.

Como ir mais longe fazendo com que o GRUB2 consiga realmente ler o conteúdo dos sistemas de arquivos e inicializar o sistema?

O que estou errado em minhas suposições de funcionalidade aqui?

EDIT (2012-04-01) Meu grub.cfg gerado:

link

Parece que primeiro torna o meu volume / usr lógico a raiz e isso pode ser a fonte da falha? Um bug no grub-mkconfig? Ou é suposto ter acesso a coisas do / usr antes / e / boot? / boot está ligado / para mim - não há volume lógico de inicialização separado.

    

Answer 1

Afinal de contas, foi um bug / problema do Grub2 com uma invasão de software degradada array .

O Grub2 1.9x tem problemas com a inicialização de um array degradado. Inicializar no modo de recuperação no sistema e permitir que o ataque se recupere corrigiu o problema para a configuração original em questão.

A propósito, a configuração funciona (no momento: 2012-06-26) diretamente no Fedora 17, Arch (estável) e Gentoo (estável + mais recente grub2 bzr via Portage): Grub2 2.0+ corrigiu o problema . Com o congelamento do Wheezy chegando, espero que o problema seja resolvido com o salto para a versão 2.0 ou com o backport da correção.

Para mim, isso ainda afeta o Debian 6, 7; Ubuntu 8.04, 10.04, 12.04.

Permitir que a invasão sincronize em uma configuração de recuperação de modo de usuário único é uma solução aceitável para um sistema doméstico, mas ter um possível engate extra para reinicializar um servidor de produção (mesmo um servidor de arquivos de pequeno porte) faz com que se pense duas vezes.

    

Answer 2

Muito bom post, muito obrigado, isso me ajudou muito a instalar um LVM - over - RAID no Debian Wheezy. Aqui estão os passos que tomei para superar o problema.

Atualize o Grub2 para a V2 +

Adicione estas linhas ao /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 instala o grub2

    

Answer 3

Talvez você tenha tornado a única partição muito grande e não tenha deixado espaço suficiente para a instalação do GRUB2 e tenha sobrescrito partes do espaço do LVM. Algo de um longo caminho. Tente suas etapas para recriar seu problema, exceto que desta vez use um único disco (pule o RAID), crie a partição única exatamente como antes e depois o resto. Se eu estiver certo, então você deve ter o mesmo comportamento.

UPDATE: Então, esta resposta está errada. Eu estava procurando no manual do GRUB2 e encontrei esta seção que afirma:

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.