Servidor Ubuntu, tabela de partição gpt, mdadm, falha de inicialização do grub


9

Detalhes básicos do sistema de trabalho:

Eu usei o CD do servidor Ubuntu 12.04 para instalar um servidor.

Eu tenho 4 discos. Em todos os discos, fiz o seguinte, semelhante a este howto :

  • criou uma partição de troca de 2 GB
  • criou uma partição de 256 GB / inicialização
  • criou uma partição RAID10 de 64 GB (para raiz)
  • criou uma grande partição RAID10 ocupando o resto do espaço

Formatei a inicialização como ext3. Eu configurei o RAID10 na raiz e nas grandes partições. Eu formatei a raiz ext4. Criei um grande volume lógico e o formatei ext4.

O sistema resultante funciona bem e inicializa bem.

Detalhes do problema:

Então decidi documentar um procedimento de falha. Como o primeiro passo, decidi reinstalar o grub.

# grub-install /dev/sda
warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!.
error: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
# grub-install /dev/sdb
warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!.
error: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..

Parece que falhou, mas também parece que desistiu e não fez alterações. Então eu reiniciei. A inicialização falhou. Apenas trava com uma tela preta com um cursor piscando cerca de 4 linhas abaixo. Se eu inicializar pressionando "Shift", recebo a palavra "GRUB" à esquerda do cursor, mas nenhum prompt interativo.

Neste ponto, usei o boot-repair-disk para gerar este relatório: http://paste.ubuntu.com/966531/

Observe no relatório acima, que o gerenciador de inicialização não aponta para o setor correto para core.img. (sda é o cd virtual; sdb é o disco de inicialização; sdc é um espelho do sdb, mas a inicialização não é espelhada, apenas uma partição independente relacionada está lá e formatada ext3; sdd e sde têm espaço para inicialização, mas não está formatado)

Então eu inicializei a partir do CD do servidor Ubuntu, iniciei o sistema de recuperação e emiti os seguintes comandos, que foram concluídos sem erro (onde sda ​​é o CD virtual eb, c, d, e são os discos que eram a, b, c , d nos comandos grub anteriores):

# parted /dev/sdb set 2 bios_grub on
# parted /dev/sdc set 2 bios_grub on
# grub-install /dev/sdb
# grub-install /dev/sdc

Neste ponto, usei o boot-repair-disk para gerar este relatório: http://paste.ubuntu.com/966561/

Observe que no relatório acima, o problema do core.img desapareceu. Parece apontar para o setor correto.

Agora, se eu tentar inicializar, recebo um prompt do grub. Se eu executar "set", vejo que a raiz foi encontrada e configurada. Se eu executar "ls /", vejo meu diretório raiz a partir do volume raid, incluindo o arquivo do kernel vmlinuz. Se eu digitar "ls / vmlinuz", ele diz "error: file not found". Diz o mesmo erro se eu usar o comando "linux" para tentar carregar o kernel. O arquivo vmlinuz não está listado se eu usar "ls -l /".

Detalhes excessivamente detalhados, caso você queira seguir:

Notei que também não há /boot/grub/grub.cfg, então eu corri

# grub-mkconfig -o /boot/grub/grub.cfg

Mas o problema permanece.

Se eu usar a ferramenta "gptsync", não há alterações nesse comportamento.

O disco de reparo de inicialização não repara o sistema, porque deseja que eu inicialize com uma BIOS ativada para EFI. Eu olhei brevemente para isso, mas não sei como isso funciona. Encontrei um shell UEFI em minhas opções de inicialização, mas não sei nada sobre ele e não vejo como alterar a inicialização a partir daí (por exemplo, para inicializar o CD a partir desse shell EFI).

Também li esta página , mas o Ubuntu não vem com o comando "grub", então não posso segui-lo exatamente. Eu poderia simplesmente instalar esse comando, mas estou mais curioso para descobrir como o instalador do Ubuntu conseguiu instalá-lo, em vez de ter uma configuração diferente. Usou listas de bloqueio?

Aqui está a saída do parted, enquanto inicializado no disco de reparo de inicialização (onde aqui o sdb é o primeiro disco rígido, o sda quando inicializado a partir do disco e "boot" muda para "bios_grub" no segundo link de colagem):

Model: ATA Hitachi HUA72303 (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name   Flags
1      17.4kB  2000MB  2000MB  linux-swap(v1)  swap1
2      2000MB  2256MB  256MB   ext3            boot1  boot (this says bios_grub in 2nd link)
3      2256MB  66.3GB  64.0GB                  root1  raid
4      66.3GB  3001GB  2934GB                  data1  raid

Aqui está uma máquina virtual super antiga e não relacionada para comparação (para qualquer pessoa que não esteja familiarizada com o boot-repair-disk ): http://paste.ubuntu.com/966799/

Aqui está a última pasta do sistema com problemas, depois de executar o grub-mkconfig acima, e também definir "bios_grub" de volta para "boot". http://paste.ubuntu.com/966808/

Comparando os dois, isso parece interessante:

sdb2: __________________________________________________________________________

File system:       
Boot sector type:  Grub2's core.img
Boot sector info: 
Mounting failed:   mount: unknown filesystem type ''

md/bcserver8:0: ________________________________________________________________

File system:       ext4
Boot sector type:  -
Boot sector info: 
Operating System:  Ubuntu 12.04 LTS
Boot files:        /boot/grub/grub.cfg /etc/fstab /boot/grub/core.img

Parece que o ataque tem os arquivos de inicialização e o sdb2 não está formatado. (apesar disso, o sistema inicializou antes de executar o grub-install). No CD de resgate, "mount -t ext3 / dev / sdb2 / boot" falha. Mas faz sentido que isso confunda as coisas, uma vez que o grub usa a partição 2 explicitamente (os 2 no comando parted que ativou o bios_grub).

Então eu fiz algo parecido com isto:

# mkfs.ext3 -L boot1 /dev/sdb2
# mv boot boot_on_root
# mkdir boot
# mount /dev/sdb2 boot
# rsync -avHP boot_on_root/ boot/
# parted /dev/sdb set 2 bios_grub on
# parted /dev/sdc set 2 bios_grub on
# grub-install /dev/sdb
# grub-install /dev/sdc

Em seguida, reiniciei e tenho a tela preta novamente, sem aviso. http://paste.ubuntu.com/966848/

Então, neste ponto, meu palpite é que, quando o bios_grub está definido, o grub não está sendo instalado no MBR, e não no sistema de arquivos ext3 no ext3, mas na própria partição, como se fosse EFI ... o que obviamente iria atrapalhar o sistema de arquivos ext3 lá. E, da minha breve leitura sobre EFI, parecia que a EFI assume que a primeira partição é a inicialização, mas no meu caso a primeira é swap, e também deve ser FAT em vez de algo desmontável ... então, como isso faz pouco / não sentido, eu ainda estou completamente perdido sem uma pista. [EDIT: agora eu tenho uma pista ... pule um pouco para atualização]

E agora, quando clico em Reparar no Disco de Inicialização , ele pergunta outra coisa. Na última vez em que o erro foi oculto sob a janela, tive que arrastar o outro para vê-lo. Desta vez, a janela principal se foi e a nova janela diz:

GPT detected.       You may want to retry after creating a
BIOS-Boot partition (>1Mo, flag). Do you want to continue?

Então eu cliquei em sim, e ele disse que foi reparado com sucesso e criou outra pasta: http://paste.ubuntu.com/966862/

Mas ainda tenho uma tela preta com um cursor piscando.

Agora, minha teoria é que a inicialização foi substituída por uma coisa não-gorda e não-EFI, que é apenas um código grub que, de outra forma, estaria nos setores 0 a 63 antes. Felizmente, encontrei uma declaração muito clara nesta página, que provavelmente completou minha compreensão do que tudo isso significa. E depois que descobri isso, Jeremy postou uma resposta que, se verdadeira, confirma que esse é o conceito-chave que faltava. http://blog.psych0tik.net/2011/08/grub-embedding-blocklists-and-bios_grub-partitions/

Questões:

O que está acontecendo? Por que o grub falha ao inicializar? Por que diz "arquivo não encontrado"?

Por que o grub não deseja instalar sem essa configuração que defini com parted (que não foi definida pelo instalador do Ubuntu)? Eu pensei que tudo que eu precisava para instalar era um boot / separado que não esteja no LVM nem no RAID de software, pois minha raiz está no RAID e a tabela de partição é GPT.

Como o instalador do CD do Ubuntu o instala sem esse problema e sem a configuração bios_grub?

Eu também consideraria usar o EFI. Se essa é uma boa ideia e existe uma maneira padrão de configurá-la, estou sempre pronto para aprender coisas novas.

A resposta mais rápida que me faria feliz, mesmo sem responder a todas as minhas perguntas, seria um conjunto de comandos que eu poderia executar no CD de resgate para corrigir o gerenciador de inicialização da mesma maneira que o CD de instalação o fez. Também seria interessante se eu pudesse executá-los com o sistema inicializado, em vez do CD.


Você poderia adicionar a saída de impressão da parted?
Jeremy

Você pode ver que nos 2 links para colar da linha 993, mas por solicitação, anexarei à minha pergunta.
Peter

Respostas:


8

A solução é usar uma partição bios_grub, que não é a mesma que a partição / boot.

Por padrão, a partição bios_grub é 1MiB e deve ser sinalizada como bios_grub. A minha é a primeira partição do meu disco. Se sua partição 2 for realmente / boot como parted sugere, isso não estaria correto e você deverá criar outra partição 1MiB.

Com GPT e GRUB2, o sistema de arquivos mínimo possui três partições: bios_grub, root, swap. (não é perfeitamente seguro trocar)

Por que o grub falha ao inicializar após simplesmente executar "grub-install"?

Desconhecido ... Você pensaria que isso não modificaria nada se disser claramente que não pode incorporar e não pode funcionar.

Por que diz "arquivo não encontrado"?

/ vmlinuz é um link simbólico que usa a partição de inicialização e a partição de inicialização está corrompida. O código bios_grub foi escrito sobre sua estrutura ext3. Provavelmente, isso significava que o / boot não estava montado e os arquivos grub vistos lá estavam realmente no sistema raiz, que não continha o kernel.

Por que o grub não deseja instalar sem essa configuração que defini com o parted

Uma tabela de partição GPT não tem espaço para um carregador de inicialização, ao contrário do MBR. Portanto, uma partição específica deve ser criada para conter o código de inicialização. Antes de executar "grub-install", especifique esta partição com o comando:

    parted /dev/sda set 1 bios_grub on

Eu pensei que tudo que eu precisava era um boot / separado. Como o instalador do CD do Ubuntu o instala sem a configuração bios_grub?

Esse requisito parece ser tudo o que é necessário para o instalador do Ubuntu, mas cria um sistema incomum que é quebrado facilmente.

Quando o GRUB diz "Este rótulo de partição GPT não possui partição de inicialização do BIOS ", significa a partição bios_grub, não / boot.


Obrigado. Na verdade, isso está muito próximo do que estou trabalhando agora. Veja o meu "eu ainda estou completamente perdido sem uma pista." seção acima. Agora, minha teoria é que a inicialização foi substituída por uma coisa não-gorda e não-EFI, que é apenas um código grub que, de outra forma, estaria nos setores 0 a 63 antes. Estou trabalhando em um experimento e, em seguida, informarei como será.
Peter

Você está usando o Ubuntu? Existe uma maneira de o instalador do Ubuntu poder instalar corretamente usando a partição bios_grub?
Peter

@ Peter Eu uso o Ubuntu e, se você fizer um particionamento guiado, o instalador deve configurá-lo corretamente. Eu sei que isso aconteceu comigo com o instalador 11.10.
Jeremy

Muito obrigado. Essa é a resposta. Em seguida, tentarei configurações mais complexas (raid e lvm na inicialização) e depois editarei sua resposta com detalhes.
Peter
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.