Escolhendo Grub entre vários Linux

Grub do Mageia, com seleção automática da última distro Linux escolhida

A instalação de vários sistemas em paralelo (dualboot, ou multiboot) criou uma situação em que já não basta eu usar o Grub para escolher qual Linux rodar. — Agora, eu também preciso escolher qual distro deve controlar o Grub, — e quais não devem interferir.

Isso, porque existem particularidades no Grub de algumas distros que o impedem de gerar as entradas corretas, no Menu de inicialização, para algumas das outras distros.

Havendo vários HDDs em hardware Bios (legacy) / MBR, também é uma boa precaução ter mais de um Grub, — controlados por diferentes distros Linux. — Em caso de emergência, basta configurar a Bios para dar Boot por outro HDD.

2020 - Estas anotações continuam válidas para meu novo hardware UEFI / GPT, com alguns detalhes adicionais.

Índice

• Infância dos fatos
• Fatos espinhosos

• Caso 1 - Arch (intel-ucode)

• Caso 2 - BtrFS sem “/boot” separado

• Caso 3 - Slackware

• A escolha de um Grub

• Tema do Grub2 (gráfico)

• Mini-catástrofes

• Reorganização do Grub

• Reconfiguração do Grub

• Midnight Commander (mc)

• Grub enlouquecido com 12 distros em multiboot
• Novo hardware UEFI / GPT (2020)

Infância dos fatos

Longo confinamento a 3 distros — de um mesmo “tronco”, — Debian, Kubuntu e Linux Mint

Enquanto me restringi ao Kubuntu (sistema “principal”), e Debian ou Linux Mint (como “alternativo”), o Grub não apresentou dificuldades. — Ubuntu baseia-se no Debian; Linux Mint baseia-se no Ubuntu — e todos se entendem.

A transição do Lilo para o antigo Grub (atual “legacy”) se fez sem grandes sustos, — e a passagem para o “Grub2” foi suavizada pela descoberta do Grub-customizer — que hoje eu não recomendo.

Representação esquemática das partes que compõem o Grub e sua localização no HDD

Lembrando que o Grub se divide em 2 partes bem distintas, em hardware Bios (legacy) / MBR:

1) Uma “chamada” minúscula no Master Boot Record (MBR), — a trilha inicial do HDD de Boot, — com o mínimo de informações para dar prosseguimento ao processo.

Ou seja, indicar em qual partição buscar o resto. — Cada Linux grava a “chamada” para sua pasta /boot.

2) Um conjunto de arquivos, configurações etc., dentro da partição (ou partições) de sistema de cada Linux, — em especial, na sua pasta (ou partição) /boot.

Durante anos, achei que a “chamada” do Grub tinha de ser gravada no MBR do primeiro HDD. — Enquanto eu tinha apenas Kubuntu, Mint e Debian, isso não causava problemas, — era até divertido, ver uma distro tomar da outra o controle do Grub.

Nesse caso, bastava escolher minha distro “principal”, e executar o comando “sudo grub-install /dev/sda”. — Ela retomava o controle do Grub, e tudo voltava ao normal.

Fatos espinhosos

Uma deficiência na última linha do Grub do Mint impede o carregamento do Manjaro

Em 2017, com a instalação de várias distros “não-Debian”, surgiram casos ou situações em que o Grub de alguns sistemas não consegue gerar entradas capazes de carregar alguma outra distro.

A priori, nada a ver com o Grub, em si, — mas com a estrutura de umas e outras distros. — Quem sabe, por falta de alguns pacotes aqui e ali.

Caso 1 - Arch (intel-ucode)

Falha ao carregar o Manjaro a partir do Grub gerado pelo Linux Mint

Um caso bastante discutido é o do Arch e alguns de seus “derivados” (como o Manjaro).

O Grub de outros Linux costumava gerar entradas com uma linha assim:

initrd /boot/intel-ucode.img

mas, para funcionar, tais linhas deveriam indicar a localização do initramfs:

initrd /boot/intel-ucode.img /boot/initramfs-XXXXXX.img

onde “XXXXXX” pode ser “linux”, “linux-lts”, “linux-zen” etc. — Se houver apenas um, basta uma busca-e-troca global, com esse acréscimo.

No Manjaro, — com 2 Kernel diferentes (opção minha), — “XXXXXX” exigia substituição manual (caso-a-caso), nas entradas do /boot/grub/grub.cfg — e na época achei mais simples eliminar o Manjaro, para agilizar a edição do arquivo, após cada atualização do Grub do Mageia:

initrd /boot/intel-ucode.img /boot/initramfs-4.9-x86_64.img

initrd /boot/intel-ucode.img /boot/initramfs-4.4-x86_64.img

Correção manual do Grub, por Busca & substituição global

No Arch (instalado pelo Revenge Installer), “XXXXXX” nunca apresenta variação, o que permite busca-e-troca global no /boot/grub/grub.cfg do Mageia:

initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img

Se esta fosse a única dificuldade, o Grub do próprio Arch (ou do Manjaro) seria o candidato natural, para ser o meu Menu de inicialização, — dispensando correções manuais.

Há várias sugestões para automatizar essa “correção”, em outras distros, — incorporando-a no processo de atualização do Grub, — mas não encontrei nenhum indício de que alguma dessas “receitas” tenha alcançado ampla aceitação.

Enfim, o Arch instalado pelo Anywhere não apresentou esse problema. — Carregava pelo Grub de qualquer outra distro, sem a menor dificuldade. — Mas eu preferi manter o Arch instalado pelo Revenge (atual Zen Installer).

Edit (2020) - Desde meados de 2019 (pelo menos), o Grub do openSUSE Tumbleweed se mostrou capaz de gerar as entradas completas para o Arch.

Caso 2 - BtrFS sem “/boot” separado

Falha do Grub do openSUSE em gravar a opção escolhida, para repetir no próximo Boot

Carregar o openSUSE, — instalado em uma partição BtrFS, — parecia fora do alcance do Grub de (quase) todas as outras distros que já instalei.

A exceção era o Grub do Mageia, — único que conseguia carregar o openSUSE, — e isso mostra que não se trata de “missão impossível”, desde que eu descubra o segredo.

Esse problema foi causado por uma decisão minha — de não criar uma partição /boot (ext4 “tradicional”) separada da partição-raiz (BtrFS).

É claro que o Menu de inicialização gerado pelo Grub do próprio openSUSE consegue carregá-lo, — e se esta fosse a única questão, bastaria eu adotá-lo.

Porém, na época, não encontrei meio de ele “lembrar” a escolha feita no Boot anterior, — mesmo com a configuração necessária no /etc/default/grub:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT="true"

O motivo era o mesmo: — Por eu não ter criado uma partição /boot (ext4 “tradicional”), separada da partição de sistema (BtrFS).

É que o Grub não gravava em partição BtrFS (*), — até o openSUSE ser carregado. — Portanto, durante o Boot, não podia salvar a opção escolhida, para lembrar na próxima inicialização.

(*) Isso mudou. Tempos depois, o Grub passou a lidar com BtrFS.

Usá-lo no dia-a-dia significaria ficar parado (e atento), na frente do computador, — ou carregaria sempre openSUSE, ao final da contagem regressiva.

Edit (2020) - No novo hardware UEFI / GPT, adotei o Grub do openSUSE como meu Menu de inicialização, pois agora, ele salva e “lembra” a última distro que escolhi. — Porém, a resposta do Grub (setas para cima e para baixo) sempre foi lenta, no openSUSE — até que movi o Tema do Grub para a partição /home (em XFS).

Caso 3 - Slackware

“Panic” e “End trace” no Boot do Slackware a partir do Grub controlado por outra distro

A instalação do Slackware (14 Jul. 2017) mostrou mais um caso espinhoso.

Nas linhas onde o Grub do Mageia, — entre outros, — gerava estes parâmetros:

linux /boot/vmlinuz-generic-4.4.75 root=/dev/sdc2

eu precisava substituir “generic” por “huge”:

linux /boot/vmlinuz-huge-4.4.75 root=/dev/sdc2

Na forma original, o Boot do Slackware emitia 2 mensagens de “panic” e terminava em uma mensagem de “end trace”, — palavras-chaves que me levaram a encontrar esta solução.

Isso, porque o Slackware usava o Lilo, e não gerava o arquivo /boot/grub/grub.cfg, para ser lido pelo Grub do Mageia (ou do openSUSE). — Afinal, percebi que bastava instalar o Grub no Slackware, e gerar o /boot/grub/grub.cfg, para o Grub das outras distros passar a gerar as entradas corretas.

A escolha de um Grub

Grub original do Mageia, com letras grandes, — e metade do Menu fora do retângulo de exibição

Desse conjunto de obstáculos, — e após 2 ou 3 “desastres” meio chatos, — escolhi o Grub do Mageia como o mais indicado, para aquele hardware Bios (Legacy) / MBR, com aquele conjunto de distros em dualboot (ou multiboot).

Os principais motivos:

1) O Grub do Mageia era o único que conseguia carregar o openSUSE, — exceto o Grub do próprio openSUSE

2) Se sua “chamada” no MBR fosse apagada, o Mageia podia ser carregado pelo Grub de qualquer outra distro, — e em 1 minuto, gravar novamente sua “chamada” no MBR.

3) O Grub do Mageia “lembrava” perfeitamente qual o último sistema escolhido, — e o carregava automaticamente, ao final da contagem regressiva, — o que é muito prático, para usar uma mesma distro Linux durante vários dias seguidos.

O resto, — ter de corrigir “manualmente” as entradas do Arch, — também aconteceria com o Grub de qualquer outra distro.

Tema do Grub2 (gráfico)

Edição do tema do Grub para ampliar o retângulo do Menu de inicialização

Como a edição do Grub “gráfico” é trabalhosa, — os arquivos se espalham por várias pastas, e para ver o efeito é necessário gerar (atualizar), reiniciar o computador, — copiei para o Mageia o tema do Grub do openSUSE, cuja personalização já ia bem avançada.

Alterei 2 arquivos e 1 pasta, — destacados nestas seções da árvore do sistema, — nos dias 20 e 21 Maio 2017:

   |-boot
      |---grub2
             custom.cfg
             grub.cfg
             grubenv
         |-----fonts
         |-----i386-pc
         |-----locale
         |-----themes
            |-------dolphy
            |-------maggy
            |-------openSUSE
                theme.txt
   |-etc
      |---default
             grub
      |---grub.d
             00_header
             01_users
             06_grub-customizer_menu_color_helper
             10_linux
             20_linux_xen
             20_ppc_terminfo
             30_os-prober
             40_custom
             41_custom
             README

Uma das principais modificações foi reduzir a fonte de letra e aumentar o retângulo central, — onde se apresentam as opções do Menu de inicialização, — para caberem 8+ distros, teste de memória etc., sem deixar coisas escondidas “abaixo da linha do horizonte”.

Mini-catástrofes

Efeito de um upgrade do Grub, — Menu “de fábrica”

Dois pequenos sustos, nos dias 16 e 28 Jun. 2017, me levaram a reavaliar velhas crenças — e a examinar as observações feitas ao longo dos anos, naquele hardware Bios (Legacy) / MBR.

No dia 16, o Kubuntu recebeu um prosaico upgrade do Grub:

Commit Log for Fri Jun 16 02:25:30 2017

grub-common (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub-pc (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub-pc-bin (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub2-common (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11

e foi o que bastou para re-gravar sua “chamada” no MBR do 1º HDD (sda), — em lugar da “chamada” para o Grub do Mageia. — Pior. Um Menu de inicialização contendo só Kubuntu.

No entanto, o mesmo upgrade havia sido feito no KDE Neon, meia-hora antes, — sem causar “desastre” algum:

Commit Log for Fri Jun 16 01:53:51 2017

grub-common (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub-pc (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub-pc-bin (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub2-common (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11

Lembrasse eu o essencial do que já sabia, — resumido acima, — e não gastaria 10 minutos para restabelecer o controle pelo Grub do Mageia:

• Carregar o Kubuntu
• Rodar um “sudo update-grub” para re-detectar as outras distros
• Carregar o Mageia pelo Menu de inicialização (atualizado) do Kubuntu
• Re-gravar a “chamada” do Grub do Mageia em sda

Mas minhas ideias, fatos, causas etc. estavam embaralhados, — e passava da meia-noite, quando todos os gatos parecem cachorros pardos, rosnando.

Tentei tudo o que não precisava tentar, — Live Arch Anywhere (como Rescue disk), Live Mageia 6 sta2, Live openSUSE (More → Rescue system), Mageia Classic Installer (Rescue → Re-install Boot Loader), — e só não foi pura perda de tempo, porque me obrigou a revisar o assunto de A a Z, documentar configurações e ferramentas usadas em cada distro etc.

Ficou claro que eu precisava reconfigurar o Grub das outras distros para gravarem no MBR do sdc, — de modo que apenas o do Mageia gravasse em sda (e só o do openSUSE no sdb); — só faltava descobrir como.

O comando “grub-install /dev/sdc”, na verdade faz apenas uma gravação isolada, — sem evitar que continuem gravando em sda, no futuro.

Isso ficou ainda mais urgente em 28 Junho, quando chegou a vez do upgrade de Grub no Debian:

grub-common (2.02~beta3-5) to 2.02-1
grub-pc (2.02~beta3-5) to 2.02-1
grub-pc-bin (2.02~beta3-5) to 2.02-1
grub2-common (2.02~beta3-5) to 2.02-1

Dessa vez, o susto não passou de marolinha, — o resumo já estava claro (e bem anotado). — Só faltava eu acabar com aquela chatice, de uma vez por todas.

Reorganização do Grub

Como havia 7 sistemas instalados, — e apenas 3 HDDs, — eu precisava evitar que outros Linux interferissem no Grub controlado pelo Mageia.

As configurações precisavam ser planejadas de modo racional, para segregar o campo de atuação de cada um:

• MBR do sda ← Grub do Mageia (sda2)

• MBR do sdb ← Grub do openSUSE (sdb2)

• MBR do sdc ← Grub do Debian, Kubuntu, Mint, Neon, Arch

Associar o Grub do Mageia e do openSUSE ao MBR dos respectivos HDDs tornaria cada um deles à prova de “falhas no outro HDD”.

Os demais 5 sistemas se revezariam na “posse” da trilha inicial do sdc, — sem sobregravar as “chamadas” para o Grub do Mageia, em sda, — nem as chamadas para o Grub do openSUSE, em sdb.

Havia uma hipótese de deixar apenas 1 Grub gravando em sdc, — e os outros 4 simplesmente pararem de gravar (ver adiante), — mas isso deixaria meu “último salva-vidas” dependente de apenas 1 distro.

Poderia ficar excessivamente desatualizado, — caso aquela distro não atualizasse seu Kernel com frequência, — ao passo que 5 distros em “corrida de revezamento” garantiriam atualizações mais frequentes do “terceiro Grub”.

Reconfiguração do Grub

Usando “dpkg-reconfigure grub-pc” para redefinir qual MBR será gravada por cada Grub

Finalmente, encontrei o caminho para fazer isso, — no Debian & derivados, — depois de várias buscas sem resultados:

# dpkg-reconfigure grub-pc

Opções oferecidas pelo “sudo dpkg-reconfigure grub-pc”

Em resposta ao comando, o Konsole exibe uma interface “semi-gráfica”, e a primeira questão é sobre uma linha de comando do Grub antigo (legacy: “menu.lst”). — Foi apresentada em branco (esclarece que pode deixar vazia). — Me limitei a usar TAB para chegar ao “Ok” e prosseguir.

A segunda questão apresentada é sobre os parâmetros a serem usados na entrada-padrão do Menu, — “quiet splash”. — Mais uma vez, TAB para chegar ao “Ok”, sem alterar nada.

A terceira questão era a que interessava no momento, — em qual HDD cada Grub deveria gravar sua “chamada”.

Usam-se SETAS (↓↑) para navegar entre as múltiplas escolhas, — ESPAÇO para marcar / desmarcar, — e TAB para chegar ao “Ok”.

Em todos os casos, foram oferecidos os 3 HDDs (o SSD estava desplugado), — além da própria partição onde cada sistema está instalado. — Esta última opção não é recomendada, e nem sei como se usa.

Simplesmente marquei o Kubuntu, o KDE Neon, o Mint KDE e o Debian KDE para gravarem suas “chamadas” do Grub sempre no sdc.

Configuração do Grub no Mageia Control Center

No Mageia, foi ainda mais fácil configurar o “dispositivo de boot” (sda), graças ao Mageia Control Center (MCC).

Infelizmente, não encontro nenhum registro de como consegui configurar o openSUSE para gravar a “chamada” do Grub no MBR do sdb. — Só sei que consegui.

Não descobri como fazer essa reconfiguração no Arch Linux — pois eu ainda não tinha aprendido a instalar o Arch “na unha“.

Midnight Commander (mc)

Verificação do /boot/grub2/grub.cfg (data, hora) e edição pelo Midnight Commander

Com os crescentes obstáculos ao uso de Dolphin / Kate / KWrite em modo Superusuário (Root), resolver problemas estava se tornando mais um problema.

Ctrl-Shift-V para colar nos campos de busca e troca global

Daí a escolha do Midnight Commander (mc).

Busca e troca global no editor de textos do Midnight Commander

É muito prático para localizar e editar arquivos de sistema, sem tropeçar em dúvidas como, — “/boot/grub/grub.cfg” ou “/boot/grub2/grub.cfg”, por exemplo?

_________
Originalmente publicado em 29 Jun. 2017, e desenvolvido até 2 Jul. 2017.
••• Adicionadas notas sobre o Slackware em 15 Jul. 2017.

— … ≠ • ≠ … —

Não-debians

• Mageia 6 - Kernel 4.14
• PCLinuxOS - instalação direta (sem sessão Live)
• PCLinuxOS - instalação e configuração
• Rosa Desktop Fresh R10 - live DVD, instalação e configuração
• openSUSE Tumbleweed - instalação e configuração
• Slackware Plasma 5 KDE - instalação e configuração
• Slackware - instalação e aprendizado (interrompido)
• openSUSE - removendo Snapper, PIM, Baloo e Akonadi
• Escolhendo Grub entre vários Linux
• Escolhendo (e aprendendo) Linux conforme as necessidades
• Arch Linux KDE - Instalação e configuração
• Mageia 6 sta2 - Instalação e configuração
• Montagem de partições no Antergos e no Manjaro
• Transição do Manjaro (rolling-release) para 17.0
• Sabayon 16.11 KDE - Instalação e configuração
• Fedora 25 KDE - Instalação e configuração
• Consertando o Manjaro após erro em atualização
• openSUSE Leap 42.2 - Instalação e configuração
• Instalação do Manjaro KDE 16.10.3 stable
• Mageia 5 KDE Live USB
• Fedora 24 alpha KDE em sessão Live USB