Movendo /boot, como atualizar o grub para encontrar um novo local /boot/grub2/i386-pc/{core,boot}.img

Você está misturando a terminologia GRUB Legacy e GRUB2. O termo "stage2" é apenas para GRUB Legacy (ou seja, versões 0.9x). Mas acho que entendo o que você quer dizer.

Quando i386-pca versão do GRUB é instalada no MBR e no espaço entre o MBR e a primeira partição ou na partição de inicialização do BIOS, os /boot/grub2/i386-pc/{core,boot}.imgarquivos são usados ​​apenas pelo grub2-install, não pelo processo de inicialização real.

Como o sistema operacional na i386-pcarquitetura GRUB não tem uma maneira confiável de obter informações sobre como o BIOS viu pela última vez a ordem do disco no momento da inicialização, grub-installbasicamente tem duas opções disponíveis no momento da instalação, se configurado para contar com suporte de disco do BIOS (como é o modo usual):

• se um /boot/grub[2]/device.maparquivo tiver sido fornecido, use as informações nele contidas para mapear os dispositivos do sistema operacional para nomes de dispositivos GRUB (que corresponderão diretamente aos números de disco do BIOS)
• se o device.maparquivo não estiver disponível, adivinhe que a ordem atual dos discos do sistema operacional é a mesma que a ordem de detecção dos discos do BIOS. Essa suposição pode ou não estar correta.

(Especificamente, ao executar um instalador ou mídia ao vivo a partir de USB, é comum que o dispositivo de armazenamento USB seja detectado como o primeiro "disco"; isso pode confundir o palpite grub-install, porque uma vez que o sistema operacional instalado inicializa sozinho, o A emulação de disco no nível do BIOS para armazenamento USB não estará mais disponível, pois o BIOS não inicializará a partir da mídia USB nesse ponto.)

O código de inicialização do GRUB incorporado no bloco MBR real contém duas informações gravadas nele de grub-installcada vez: o número da unidade de inicialização e o número do bloco LBA que o GRUB deve ler a seguir. Nas versões modernas do GRUB, o número da unidade geralmente é codificado como 0xff, significando "use o mesmo disco BIOS usado para ler o MBR".

Quando estiver em um disco particionado por MBR, o número do bloco LBA normalmente será 0x0000000000000001, apontando para a lacuna entre o MBR e a primeira partição. Em um disco particionado por MBR, é onde o restante da imagem principal do GRUB, os módulos essenciais e a string de prefixo (que apontará para o local do /boot/grubdiretório) serão incorporados. Em discos particionados por GPT, tudo isso será gravado na bios-bootpartição, e o número do bloco LBA incorporado no código de inicialização MBR real será maior, pois apontará para o início da bios-bootpartição.

O primeiro bloco do código incorporado inclui uma lista de blocos que identifica quais blocos serão lidos em seguida: quando incorporado a um disco particionado por MBR, será uma série contígua de blocos começando no bloco LBA nº 2. A duração desta série dependerá principalmente do número e tipo de módulos essenciais incorporados junto com a imagem principal do GRUB. A maior parte desse código incorporado será compactado LZMA e depois protegido com códigos de correção de erros Reed-Solomon, portanto, modificá-lo geralmente forçará você a reescrever tudo. Infelizmente, a string de prefixo que identifica a localização do /boot/grub[2]diretório estará definitivamente dentro da parte compactada.

Em sistemas modernos, a lacuna entre o MBR e o início da primeira partição é geralmente de exatamente 2.047 blocos, para alinhar a primeira partição para iniciar exatamente 1 MiB no disco. Mas os sistemas mais antigos podem ter sido particionados com uma versão que fdisknão se importava com o alinhamento dos dados, mas em vez disso tentava manter a compatibilidade do DOS, posicionando o início da partição no início de uma trilha de disco (embora a geometria clássica do disco C/H/S tenha há muito tempo é apenas uma ficção mantida pelo firmware do disco). Nestes casos, a diferença entre o MBR e o início da primeira partição pode ser muito menor. Então, para maximizar a compatibilidade, ogrub-installprecisará incorporar o número mínimo absoluto de módulos GRUB essenciais junto com a imagem principal, para minimizar o tamanho do código incorporado. Para outros limites relevantes resultantes do hardware do PC e da implementação do BIOS, consulte a documentação do GRUB : i386-pcé considerada uma "plataforma altamente limitada" nesse aspecto.

Em uma instalação simples do RedHat/Debian em um disco baseado em MBR, tendo /bootcomo partição separada a primeira partição do disco, o conjunto típico de módulos incorporados seria:

• biosdisk.modusar funções do BIOS para acesso ao disco
• part_msdos.modpara entender a tabela de partição MBR
• quaisquer módulos necessários para suportar o sistema de arquivos da /bootpartição

No mínimo (se a /bootpartição for inicializada como um sistema de arquivos ext2), os módulos GRUB necessários para suporte ao sistema de arquivos ext2 serão ext2.mode fshelp.mod. Esta é uma configuração prática que provavelmente produzirá um dos menores tamanhos de código incorporado alcançáveis ​​com i386-pca arquitetura moderna do GRUB.

Se o diretório GRUB for nomeado /grubem um /bootsistema de arquivos separado e /bootfor a primeira partição no disco, a string de prefixo incorporada normalmente será (,msdos1)/grub. Observe que o identificador do disco GRUB está faltando: isso significa "usar o mesmo disco do qual o BIOS lê o MBR". Indica msdos1a primeira partição estilo MBR no disco e /grubé simplesmente o caminho do /boot/grubdiretório começando na raiz do /bootsistema de arquivos.

E assim, usando apenas o código incorporado na lacuna do MBR ou na partição de inicialização do BIOS, o GRUB terá a capacidade de ler normal.modusando (,msdos1)/grub/i386-pc/normal.modo BIOS para suporte de disco e os metadados do sistema de arquivos para encontrar os blocos corretos. Depois disso, o arquivo de configuração será lido (,msdos1)/grub/grub.cfgrespectivamente.

Também é possível incorporar, por exemplo, ahci.mode search_fs_uuid.modjunto com a imagem principal do GRUB para dar ao GRUB a capacidade de acessar controladores SATA AHCI diretamente e identificar a partição/sistema de arquivos correto por UUID, mas ahci.modé mais de 3x o tamanho de biosdisk.mod, o que faz com que o limites de tamanho da imagem ainda mais prováveis.

Qual é a maneira correta de atualizar o código do bootloader na partição mbr/bios-boot quando a localização de/boot muda"?

A única resposta prática é "reescrever o código do bootloader incorporado executando grub[2]-installnovamente". Ao fazer isso, certifique-se de ter o novo /bootmontado como /boote, se necessário, forneça ao /boot/grub/device.maparquivo o conteúdo apropriado para a configuração do sistema na próxima inicialização.

No Debian e derivados como Ubuntu e Mint, o sistema de gerenciamento de pacotes lembra o dispositivo alvo de instalação da i386-pcversão do GRUB. Você pode visualizar essas informações sudo debconf-show grub-pce atualizá-las com sudo dpkg-reconfigure grub-pc.

RedHat não parece ter um recurso semelhante em sua embalagem.

RedHat e derivados não atualizam o código de inicialização incorporado.

Para efeito de comparação, na x86_64-efiarquitetura GRUB, geralmente não há restrições de tamanho para impedir que você incorpore todos os módulos GRUB disponíveis no grubx64.efiarquivo, resultando em um único binário UEFI que pode ser assinado para inicialização segura e nunca precisará carregar nenhum código executável para extra. funcionalidade. Na prática, isso garante que, enquanto o sistema puder ler grubx64.efi, todas as funcionalidades da linha de comando do modo normal do GRUB estarão disponíveis, mesmo se o /boot/grub[2]diretório for completamente destruído.