Btrfs Partitionless, de repente, inicializando com o GRUB rescue

Question

O problema

Eu tenho uma máquina que inicializa no Arch Linux a partir de um volume Btrfs RAID10 de oito discos. Recentemente, eu reiniciei e aterrei neste prompt de resgate do GRUB:

Não tenho certeza do que exatamente desencadeou isso. Desde a última inicialização, instalei atualizações ( pacman -Syu ) pelo menos duas vezes e fiz outras alterações no sistema, incluindo a reinstalação do GRUB. Eu posso iniciar o sistema se adicionar um disco de inicialização dedicado.

A teoria

Durante a solução de problemas com um membro útil do canal de IRC #archlinux, deparei com esta observação no wiki do Arch :

Partition offset

The offset problem may happen when you try to embed core.img into a partitioned disk. It means that it is OK to embed grub's core.img into a Btrfs pool on a partitionless disk (e.g. /dev/sdX) directly. GRUB can boot Btrfs partitions, however the module may be larger than other file systems. And the core.img file made by grub-install may not fit in the first 63 sectors (31.5KiB) of the drive between the MBR and the first partition. Up-to-date partitioning tools such as fdisk and gdisk avoid this issue by offsetting the first partition by roughly 1MiB or 2MiB.

Isso parece dizer que pode haver problemas com a instalação do GRUB em discos particionados e sem partição que as ferramentas de particionamento mais recentes atenuam (por enquanto), deixando espaço extra no início do disco. / p>

A página wiki do GRUB é mais direta :

Install to partition or partitionless disk

Warning: GRUB strongly discourages installation to a partition boot sector or a partitionless disk as GRUB Legacy or Syslinux does. This setup is prone to breakage, especially during updates, and is not supported by the Arch developers.

Bem, shucks.

Por que vale a pena, grub-install -v inclui essa linha em sua saída:

grub-install: info: the total module size is 0xa07c.

Isso é ~ 41K, solidamente acima do limite de 31,5 KiB mencionado acima, mas eu não conheço o GRUB bem o suficiente para ter certeza de que esta é a causa dos meus problemas.

As perguntas

1. Se este é o problema, como posso provar isso - e por que o grub-install não falha em voz alta em caso afirmativo?

2. Qual é o caminho certo para formatar discos Btrfs inicializáveis daqui para frente? MBR GPT? - um disco de inicialização dedicado é tentador, mas eu gosto de ter um gerenciador de inicialização redundante em todos os dispositivos no volume.

3. Existe uma maneira mais agradável de migrar cada disco para uma tabela de partições do que apagar e executar btrfs replace para cada disco?

Answer 1

De volta ao dia, a criação de uma tabela de partição MBR com, digamos, fdisk, deixaria, por padrão, os primeiros 63 setores intocados. É aí que o GRUB e outros gerenciadores de inicialização podem ser instalados.

Avance rapidamente para os dias modernos e a mesma ferramenta (fdisk) deixa mais espaço não utilizado; o suficiente para o GRUB2 instalar o stage1 com suporte ao BTRFS. Eu acredito que o deslocamento é de cerca de 1MB, por padrão; tudo o que isso significa em setores.

Não sei porque grub-install não falha, mas suponho que não verifique o tamanho do setor de inicialização; e sem partições como poderia.

Não vejo problema em ter carregadores de inicialização redundantes. Você precisa gerenciar isso manualmente, mas o stage1 do GRUB2 não muda com frequência. Mas isso significa que você precisa de partições.

Eu não sei de uma ferramenta que pode migrar o disco para adicionar uma tabela de partição. O problema é que o sistema de arquivos está ligado a setores no disco, e adicionar uma tabela de partição altera esses setores. Se os seus sistemas de arquivos BTRFS estavam no LVM, então sim, você seria capaz de mover as coisas porque o sistema de arquivos seria amarrado a "setores virtuais". Não estou dizendo que você deveria fazer isso, apenas ilustrando qual é o problema.