![]() |
Grub do Mageia, com seleção e carregamento automático da última distro Linux escolhida |
A instalação de vários sistemas em paralelo (dualboot) criou uma situação em que já não basta usar o Grub para escolher qual Linux rodar. — Agora, também é preciso escolher qual distro deve controlar o Grub, — e quais não devem interferir.
Isso, porque existem particularidades em algumas distros que dificultam o Grub de um Linux gerar as entradas corretas, no Menu de inicialização, capazes de carregar todos os outros.
Havendo vários HDDs, também é uma boa precaução ter vários Grub, — controlados por diferentes Linux. — Em caso de emergência, basta configurar a Bios para dar Boot por outro HDD.
Edit (2020) - Estas anotações continuam válidas para meu novo hardware UEFI / GPT, exceto por 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
- Um por todos vs. Todos por um
- Midnight Commander (mc)
- mc + nano
Infância dos fatos
![]() |
Longo confinamento a 3 distros — de um mesmo “tronco”, — Debian, Kubuntu e Linux Mint |
Enquanto permaneci restrito ao Kubuntu (como sistema “principal”), e Debian ou Linux Mint (como “alternativo”), o Grub nunca apresentou maiores dificuldades, durante 7 anos (2009-2016). — Ubuntu baseia-se no Debian, Linux Mint baseia-se no Ubuntu — e todos se entendem razoavelmente.
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.
Nada, naquela época de moleza, exigiu rever 1 velha “crença” e 1 mau-hábito.
A “crença” errônea de que o Windows precisava ser instalado sempre “na primeira partição do primeiro HDD”, — e de que o Boot precisava estar sempre “no primeiro HDD”.
Talvez de fato fosse assim, em um computador mais antigo (último upgrade em 2002), — onde precisava alterar a “pinagem” (jumpers), intercambiar os cabos de conexão etc., para inverter os HDDs. — E afinal, hoje eu nem tenho mais Windows.
Seja como for, o velho & mau hábito de sempre instalar a “chamada” do Boot na trilha inicial (MBR) do “primeiro HDD” (sda) acabou sobrevivendo por inércia.
![]() |
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:
1) Uma “chamada” minúscula no 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.
Esse mau-hábito parecia reforçado pelos instaladores do Kubuntu, do Linux Mint e do Debian, — de sempre sugerir a instalação da “chamada” do Grub no MBR do sda.
Ouço dizer que, ao instalar o Kubuntu usando “particionamento automático”, ele instala a “chamada” sempre no sda, sem mais perguntas. — Não sei. Como sempre usei “particionamento manual”, sempre pude escolher o HDD em cujo MBR seria gravada a “chamada” do Grub. E eu sempre escolhia o MBR do sda.
Desse modo, entre crenças, mal-entendidos, tradições e quiproquós, até o mês passado — depois de 1 ano sem Windows, e 6 meses usando minhas primeiras distros não-Debian, — quase todos os Linux instalados continuavam com o Grub configurado para gravar sua “chamada” na trilha inicial do sda.
Enquanto havia apenas Kubuntu, Mint e Debian, isso não causava maiores problemas, — era até divertido, ver uma distro tomar da outra o controle do Grub. — Na pior das hipóteses, aparecia algum Menu de inicialização com opções estranhas, ou meio embaralhadas (mas não tanto que inviabilizasse o Boot).
Desde 2016, parecem existir alguma interferência ou duplicidade, envolvendo Kubuntu e KDE Neon, e que resulta em entradas adicionais, com mistura de ambos (com indicação simultânea de ambas partições), mas sem deixar de oferecer também as entradas corretas. O problema pode ter sido ocultado pelo Grub-customizer (escrevendo instruções para não exibir as entradas ambíguas), e esta “varrida para baixo do tapete” persiste até hoje, de modo que, tais entradas nunca mais foram produzidas, mesmo usando “sudo update-grub”, no Neon, Kubuntu e Mint. No entanto, ainda aparecem no Menu gerado pelo Debian. — Essas entradas estranhas não aparecem nos Menus de inicialização gerados pelo Grub das distros “não-Debian”. É verdade que em algumas foi instalado o Grub-customizer (sendo possível ter corrigido através dele), porém não em outras. — Também é possível uma hipótese de que esse tipo de erro se tenha originado de antigos erros, usando Grub-customizer, e persista por sobrevivência em algum arquivo de configuração sobrevivente na /home do Kubuntu e do Mint. Porém, a /home do Neon e do Debian não contém “heranças” anteriores a 2016.
Nesse caso, bastava escolher outra distro, reinstalar seu Grub pelo Synaptic; — ou rodar o Grub-customizer; ou disparar um “sudo grub-install /dev/sda”. — Ele retomava o controle do Grub, e tudo voltava ao normal.
Até aí, as anotações, — com eventuais erros e enganos, — estão resumidas no relato de 2012 (revisado em 2016).
Fatos espinhosos
![]() |
Uma deficiência na última linha do Grub do Mint impede o carregamento do Manjaro |
Este ano, com a instalação de várias distros “não-Debian”, — e com um problema ainda não-resolvido, ao reinstalar o KDE Neon, — surgiram casos ou situações em que o Grub de alguns sistemas (ou de todos) não consegue gerar entradas capazes de carregar uma ou outra distro.
A priori, nada a ver com o Grub, em si, — mas com a estrutura de uma ou outra distro. — Talvez, por falta de alguns pacotes, facilmente instaláveis.
Já me ocorreu descobrir que faltava instalar syslinux, extlinux ou os-prober, — para realizar alguma tarefa em uma distro. — Falta ver se ainda falta mais algum pacote.
Em tese, “basta” descobrir quais pacotes estão fazendo falta. — Depois disso, tudo terá sido óbvio desde o inícpio.
Caso 1 - Arch (intel-ucode)
![]() |
Falha ao carregar o Manjaro a partir do Grub gerado pelo Linux Mint |
Um caso bastante discutido, — e para o qual ainda não encontrei solução “definitiva”, — é o do Arch e alguns de seus “derivados” (como o Manjaro).
Até hoje, o Grub de todos os outros Linux testados gerou 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 variar, em alguns casos.
No Manjaro, — com 2 Kernel diferentes, após um upgrade deliberado, — “XXXXXX” variava, exigindo substituição caso-a-caso, nas entradas do /boot/grub/grub.cfg. Foi um motivo (entre outros) para eliminá-lo, depois de instalar o Arch:
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, — devido a opções pessoais, — “XXXXXX” nunca apresenta variação, o que permite busca-e-troca global no /boot/grub/grub.cfg.
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 ter o controle do 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.
Edit (2020) - Desde meados de 2019 (pelo menos), o Grub do openSUSE Tumbleweed se mostrou capaz de gerar as entradas completas para o Arch, sem necessidade de edição manual para acrescentar o caminho (path) do initramfs.
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, — parece fora do alcance do Menu de inicialização gerado pelo Grub de (quase) todas as outras distros que já instalei.
A exceção é o Grub do Mageia, — único que consegue carregar o openSUSE, — e isto sinaliza que não se trata de “missão impossível”, desde que se descubra o segredo.
Este problema é de origem “personalizada”. — Foi gerado por uma decisão pessoal, minha — de não criar uma partição /boot (ext4 “tradicional”) separada da partição-raiz (BtrFS).
É verdade que o Menu de inicialização gerado pelo seu próprio Grub consegue carregá-lo, — e se este fosse o único problema, bastava eu adotá-lo.
Porém, (ainda) não encontrei meio dele “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 é o mesmo: — Por não ter criado uma partição /boot (ext4 “tradicional”), separada da partição de sistema (BtrFS).
É que o Grub não grava em partição BtrFS (*), — enquanto o openSUSE não for carregado. — Portanto, durante o Boot, não pode salvar a opção escolhida, para lembrar na próxima inicialização.
(*) Isso mudou, mais tarde. O Grub passou a lidar bem com BtrFS.
Usá-lo no dia-a-dia significa 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 Menu de inicialização, pois com a partição /boot/efi (Fat32) separada, ele salva e “lembra” a última distro que escolhi.
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 a existência de mais um caso espinhoso.
Nas linhas onde o Grub do Mageia, — entre outros, — gera estes parâmetros:
linux /boot/vmlinuz-generic-4.4.75 root=/dev/sdc2
é necessário substituir “generic” por “huge”:
linux /boot/vmlinuz-huge-4.4.75 root=/dev/sdc2
Na forma original, o Boot do Slackware emite 2 mensagens de “panic” e termina em uma mensagem de “end trace”, — palavras-chaves que me levaram a encontrar esta solução.
Mais tarde, percebi que bastava instalar o Grub no Slackware — e gerar o /boot/grub/grub.cfg, para ser lido pelo Grub das outras distros.
Desse conjunto de obstáculos, — e de 2 ou 3 “desastres” mais ou menos chatos, — escolhi o Grub do Mageia como o mais indicado, para esse conjunto de 7 distros instaladas (e mais algumas, que já removi).
Os principais motivos:
O resto, — ter de corrigir “manualmente” as entradas do Arch e do KDE Neon, — também aconteceria com o Grub de qualquer outra distro.
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 o tema do Grub do openSUSE, cuja personalização já ia bem avançada.
Fiz as edições em 2 arquivos e 1 pasta, — destacados nestas seções da árvore do sistema, — nos dias 20 e 21 Maio:
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”.
e foi o quanto bastou para re-gravar sua “chamada” no MBR do 1º HDD (sda), — em lugar da “chamada” para o Grub do Mageia.
Pior. Parece ter implantado um /boot/grub/grub.cfg “de fábrica”, — sem tomar a iniciativa de detectar outros sistemas existentes no computador. — O resultado foi um Menu de inicialização contendo apenas o próprio Kubuntu.
Lembrasse eu o essencial do que já sabia, — resumido acima, — e não gastaria 10 minutos para restabelecer o controle pelo Grub do Mageia:
Mas minhas ideias, fatos, motivos etc. estavam fragmentados, — e passava da meia-noite, quando todos os gatos parecem cachorros pardos, rosnando.
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 de 2 ou 3 “desastres” mais ou menos chatos, — escolhi o Grub do Mageia como o mais indicado, para esse conjunto de 7 distros instaladas (e mais algumas, que já removi).
Os principais motivos:
1) Era o único que conseguia carregar o openSUSE, — exceto o Grub do próprio openSUSE
2) Se sua “chamada” no MBR for apagada, o Mageia pode ser carregado pelo Grub de qualquer outra distro, — e em 1 minuto, gravar novamente sua “chamada” no MBR.
Se dependesse do Grub do openSUSE para carregá-lo, cada apagamento de sua “chamada” no MBR teria representado uma boa perda de tempo.
3) “Lembra” perfeitamente qual o último sistema escolhido, — e o carrega automaticamente, ao final da contagem regressiva, — o que é muito prático, para usar uma mesma distro Linux durante vários dias seguidos.
Alternar entre várias distros, várias vezes por dia, não traz qualquer vantagem ao trabalho — exceto quando preciso verificar alguma coisa em todas elas.
O resto, — ter de corrigir “manualmente” as entradas do Arch e do KDE Neon, — 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 o tema do Grub do openSUSE, cuja personalização já ia bem avançada.
Fiz as edições em 2 arquivos e 1 pasta, — destacados nestas seções da árvore do sistema, — nos dias 20 e 21 Maio:
|-boot |---grub2 custom.cfg grub.cfg grubenv |-----fonts |-----i386-pc |-----locale |-----themes |-------dolphy |-------maggy |-------openSUSE |-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
Dois pequenos sustos, nos dias 16 e 28 Jun. 2017, me levaram a reavaliar velhos hábitos, — bem como, a corrigir ideias erradas (ou superadas), — e finalmente sistematizar soluções que, até então, eu vinha improvisando aqui e ali, de modo disperso.
E mais do que apenas sistematizar as soluções adotadas, eu precisava sistematizar as ideias, — os motivos, e até o conjunto dos fatos observados, — pois já ia esquecendo alguns.
No dia 16, o Kubuntu recebeu um prosaico upgrade do Grub:
E mais do que apenas sistematizar as soluções adotadas, eu precisava sistematizar as ideias, — os motivos, e até o conjunto dos fatos observados, — pois já ia esquecendo alguns.
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 quanto bastou para re-gravar sua “chamada” no MBR do 1º HDD (sda), — em lugar da “chamada” para o Grub do Mageia.
Pior. Parece ter implantado um /boot/grub/grub.cfg “de fábrica”, — sem tomar a iniciativa de detectar outros sistemas existentes no computador. — O resultado foi um Menu de inicialização contendo apenas o próprio 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”
- Carregar o Mageia pelo Menu de inicialização (atualizado) do Kubuntu
- Re-gravar a “chamada” para o Grub do Mageia em sda
- Aproveitar para atualizar o Menu de inicialização gerado pelo Grub do Mageia
Mas minhas ideias, fatos, motivos etc. estavam fragmentados, — 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), Centro de Controle do 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 gravasse no sdb, — mas faltava descobrir como. — O comando “grub-install /dev/sdc” (que imaginava alterar essa configuração), na verdade faz apenas uma gravação isolada, sem evitar que continuem gravando em sda, no futuro.
Isso ficou claro, — e o assunto, mais urgente, — em 28 Junho, quando chegou a vez do upgrade de Grub no Debian:
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.
Como havia 7 sistemas instalados, — e apenas 3 HDDs, — era preciso 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:
Associar o Grub do Mageia e do openSUSE ao MBR dos respectivos HDDs torna cada um deles “à prova de falhas” no outro HDD.
Os demais 5 sistemas se revezam 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 eu não usasse aquela distro com frequência, — ao passo que 5 distros em “corrida de revezamento” garantiriam atualizações mais frequentes.
Finalmente, encontrei o caminho para fazer isso, — no Debian & derivados, — depois de várias buscas sem resultados:
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.
Em um forum, alguém sugere gravar na partição, quando se deseja que o Grub não grave no MBR de nenhum HDD.
Parece mais lógico apenas desmarcar todas as opções, — e isso pode ser revertido, se necessário.
É interessante a sugestão dada no último quadro do “dpkg-configure grub-pc”, de instalar a “chamada” do Grub, — na verdade, de “um único Grub”, — em todos os HDDs.
No entanto, a experiência sugere que isso pode ser uma péssima ideia, — basta imaginar como fica, se você “perder” a partição da única distro, para cuja pasta /boot todas as “chamadas” apontam.
Mas, se você tem 2+ Linux instalados em HDDs diferentes, — e mantém cada MBR apontando para o Grub de uma distro diferente, — bastará entrar na BIOS e configurar o Boot para outro HDD.
Em 1 minuto, você estará rodando o Linux sobrevivente, — ao invés de ficar um longo tempo procurando (e tentando pôr em prática) um modo de sair da enrascada.
Aliás, esse era um dos meus objetivos, ao sempre ter 2 Linux instalados “lado a lado” (dualboot), de 2009 a 2016. Um Linux “alternativo” oferece comodidade, em caso de pane no Linux “principal”. — Além, claro, de não precisar submeter seu “ambiente de produção” a experiências malucas, — tendo outro, que pode ser usado como “campo de provas”.
Apenas, — naquele período de 2009 a 2016, — eu não percebia a vantagem de ter 2 Menus de inicialização, chamados a partir de 2 HDDs. Pelo contrário, vivia sob a “crença” de que o Boot tivesse de ser feito sempre a partir do 1º HDD.
Com os crescentes obstáculos ao uso de Dolphin / Krusader / Kate / KWrite em modo Superusuário (Root), — e cada distro oferecendo (ou não) diferentes alternativas para contorná-los, — resolver problemas estava se tornando mais um problema; e justo nas horas mais inconvenientes.
Alguns comportamentos e soluções diferentes são inevitáveis, aqui e ali, quando se tentam usar 7 distros, alternadamente, no dia-a-dia, — mas, para lembrar essas poucas diferenças e seguir adiante sem perder tempo, convém que a maioria dos demais procedimentos sejam tão padronizados quanto possível, para não criar uma confusão dos diabos.
Daí a escolha do Midnight Commander (mc), — isento das ameaças à segurança que pairam contra o uso de aplicativos com interface gráfica em modo Root.
É 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. — A menos que você precise provar que faz tudo na unha.
Byteria é uma espécie de “caderno de anotações” das descobertas de um leigo, — um problema de cada vez, conforme as necessidades, sem nenhum “plano de estudos”, — e sem nenhuma pretensão de “ensinar” (muito menos, “ensinar tudo”).
Aceitei o sistema de arquivos BtrFS, ao instalar o openSUSE, como a maneira mais prática de tomar conhecimento “concreto” do que é, para que serve, como funciona, consequências e implicações, — pois estava claro que 200 horas de leitura teórica não iam me levar a nada. — LVM fica para o futuro (se e quando interessar, coisa que no momento acho improvável).
Por que o Grub do Mageia consegue gerar uma entrada capaz de carregar o openSUSE, — e o Debian & derivados não conseguem? — As experiências vão sendo feitas no KDE Neon (sujeito a reinstalação), e só quando a solução for encontrada (e compreendida), será aplicada também no Debian, Kubuntu, Linux Mint.
Também falta descobrir comandos, — no Mageia, no openSUSE e no Arch, — equivalentes ao “dpkg-reconfigure grub-pc” do Debian & derivados. Porém isso não é urgente, uma vez que parecem já estar configurados para gravar a “chamada” de Boot em sda, sdb e sdc, respectivamente, — desde quando foram instalados (Arch e Mageia); ou agora, pelos «Control Center» que cada um oferece para isso (Mageia e openSUSE).
_________
Originalmente publicado em 29 Jun. 2017, e desenvolvido até 2 Jul. 2017.
••• Adicionadas notas sobre o Slackware em 15 Jul. 2017.
— … ≠ • ≠ … —
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 gravasse no sdb, — mas faltava descobrir como. — O comando “grub-install /dev/sdc” (que imaginava alterar essa configuração), na verdade faz apenas uma gravação isolada, sem evitar que continuem gravando em sda, no futuro.
Isso ficou claro, — e o assunto, 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, — era preciso 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 torna cada um deles “à prova de falhas” no outro HDD.
Os demais 5 sistemas se revezam 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 eu não usasse aquela distro com frequência, — ao passo que 5 distros em “corrida de revezamento” garantiriam atualizações mais frequentes.
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.
![]() |
É possível configurar o Grub para não gravar “chamada” em parte alguma |
Em um forum, alguém sugere gravar na partição, quando se deseja que o Grub não grave no MBR de nenhum HDD.
Parece mais lógico apenas desmarcar todas as opções, — e isso pode ser revertido, se necessário.
Um por todos vs. Todos por um
É interessante a sugestão dada no último quadro do “dpkg-configure grub-pc”, de instalar a “chamada” do Grub, — na verdade, de “um único Grub”, — em todos os HDDs.
No entanto, a experiência sugere que isso pode ser uma péssima ideia, — basta imaginar como fica, se você “perder” a partição da única distro, para cuja pasta /boot todas as “chamadas” apontam.
Mas, se você tem 2+ Linux instalados em HDDs diferentes, — e mantém cada MBR apontando para o Grub de uma distro diferente, — bastará entrar na BIOS e configurar o Boot para outro HDD.
Em 1 minuto, você estará rodando o Linux sobrevivente, — ao invés de ficar um longo tempo procurando (e tentando pôr em prática) um modo de sair da enrascada.
Aliás, esse era um dos meus objetivos, ao sempre ter 2 Linux instalados “lado a lado” (dualboot), de 2009 a 2016. Um Linux “alternativo” oferece comodidade, em caso de pane no Linux “principal”. — Além, claro, de não precisar submeter seu “ambiente de produção” a experiências malucas, — tendo outro, que pode ser usado como “campo de provas”.
Apenas, — naquele período de 2009 a 2016, — eu não percebia a vantagem de ter 2 Menus de inicialização, chamados a partir de 2 HDDs. Pelo contrário, vivia sob a “crença” de que o Boot tivesse de ser feito sempre a partir do 1º HDD.
Midnight Commander (mc)
![]() |
Verificação do /boot/grub2/grub.cfg (data, hora) e edição pelo mcedit do Midnight Commander |
Com os crescentes obstáculos ao uso de Dolphin / Krusader / Kate / KWrite em modo Superusuário (Root), — e cada distro oferecendo (ou não) diferentes alternativas para contorná-los, — resolver problemas estava se tornando mais um problema; e justo nas horas mais inconvenientes.
![]() |
Ctrl-Shift-V para colar nos campos de busca e troca global do Editor do Midnight Commander |
Alguns comportamentos e soluções diferentes são inevitáveis, aqui e ali, quando se tentam usar 7 distros, alternadamente, no dia-a-dia, — mas, para lembrar essas poucas diferenças e seguir adiante sem perder tempo, convém que a maioria dos demais procedimentos sejam tão padronizados quanto possível, para não criar uma confusão dos diabos.
![]() |
Busca e troca global no editor de textos do Midnight Commander, com confirmação do número de ocorrências |
Daí a escolha do Midnight Commander (mc), — isento das ameaças à segurança que pairam contra o uso de aplicativos com interface gráfica em modo Root.
É 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. — A menos que você precise provar que faz tudo na unha.
mc + nano
![]() |
Testes com Midnight Commander + Nano, — em tty e no Konsole |
Depois de algumas péssimas experiências vividas com o editor “vi”, — para desativar linhas catastróficas no /etc/fstab, quando impedem o Boot e levam a um “Emergency mode”, — aproveitei para testar o Midnight Commander também em tty (Ctrl-Alt-F1 / Ctrl-Alt-F7, no KDE Neon, no openSUSE).
Ficou claro que o nano, — recomendado pelo próprio mc como “o mais fácil”, — é muito mais prático do que o editor interno (mcedit).
Em tty (no KDE Neon), a escolha é oferecida quando se chama o editor (F4) pela primeira vez, — mas pode ser mudada pelo comando “select-editor”.
Para alternar entre o editor interno (mcedit) e o editor externo escolhido, chame o Menu dropdown (F9) para ir em Options → Configure e marque / desmarque “Use internal edit”.
Skins - Persiste certa dificuldade para encontrar skins (temas) que funcionem em todas as distros, e também no tty.
Temas de 256 cores são aceitos em algumas distros, — mas, não em outras, — e nunca no tty.
Resta procurar novos skins, — e suponho que devem ser colocados na partição do sistema, para ficarem disponíveis tanto para o Usuário quanto para o Superusuário (Root):
![]() |
Comando select-editor para mudar o editor de textos chamado pelo Midnight Commander (F4) |
Ficou claro que o nano, — recomendado pelo próprio mc como “o mais fácil”, — é muito mais prático do que o editor interno (mcedit).
Em tty (no KDE Neon), a escolha é oferecida quando se chama o editor (F4) pela primeira vez, — mas pode ser mudada pelo comando “select-editor”.
No Arch instalado pelo Revenge, isso não aconteceu. — Em tty, o Midnight Commander não perguntou qual editor deveria usar, — e desconheceu o comando “select-editor”.
Para alternar entre o editor interno (mcedit) e o editor externo escolhido, chame o Menu dropdown (F9) para ir em Options → Configure e marque / desmarque “Use internal edit”.
No Konsole, a tradução desta opção em português aparece como “Conteúdo:” (sic, com dois-pontos).
Skins - Persiste certa dificuldade para encontrar skins (temas) que funcionem em todas as distros, e também no tty.
Temas de 256 cores são aceitos em algumas distros, — mas, não em outras, — e nunca no tty.
Resta procurar novos skins, — e suponho que devem ser colocados na partição do sistema, para ficarem disponíveis tanto para o Usuário quanto para o Superusuário (Root):
/usr/share/mc/skins/
Edit (2020) - Pouco tempo depois, me convenci de que o editor interno (mcedit) era o mais prático, e passei a usá-lo em todas as distros.
Making of
![]() |
Particionamento adotado para experimentar vários Linux “em paralelo” (dualboot) |
Byteria é uma espécie de “caderno de anotações” das descobertas de um leigo, — um problema de cada vez, conforme as necessidades, sem nenhum “plano de estudos”, — e sem nenhuma pretensão de “ensinar” (muito menos, “ensinar tudo”).
Fica claro que aqui se trata de hardware antigo (anterior a 2009), — daí o uso de “Master Boot Record” (MBR).
Aceitei o sistema de arquivos BtrFS, ao instalar o openSUSE, como a maneira mais prática de tomar conhecimento “concreto” do que é, para que serve, como funciona, consequências e implicações, — pois estava claro que 200 horas de leitura teórica não iam me levar a nada. — LVM fica para o futuro (se e quando interessar, coisa que no momento acho improvável).
Não havia motivo para alterar o particionamento planejado, só para criar uma partição de Boot separada, no openSUSE. — Aliás, nunca teria percebido o problema, — nem teria percebido o aceno do Mageia, de que uma solução é possível.
Por que o Grub do Mageia consegue gerar uma entrada capaz de carregar o openSUSE, — e o Debian & derivados não conseguem? — As experiências vão sendo feitas no KDE Neon (sujeito a reinstalação), e só quando a solução for encontrada (e compreendida), será aplicada também no Debian, Kubuntu, Linux Mint.
Não há motivo para bagunçar todos, com mil experiências e tentativas, até o ponto de (depois) não ter certeza de qual pequeno detalhe, exatamente, resolveu a questão. — Deixando o Debian, o Kubuntu e o Linux Mint “intocados”, servirão mais tarde como “controle”, testando apenas 1 hipótese de cada vez.
Também falta descobrir comandos, — no Mageia, no openSUSE e no Arch, — equivalentes ao “dpkg-reconfigure grub-pc” do Debian & derivados. Porém isso não é urgente, uma vez que parecem já estar configurados para gravar a “chamada” de Boot em sda, sdb e sdc, respectivamente, — desde quando foram instalados (Arch e Mageia); ou agora, pelos «Control Center» que cada um oferece para isso (Mageia e openSUSE).
_________
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
Son muchas distros, deberias reducir y eliminar: mint, ubuntu, neon, y quedarte solo con: debian, arch, suse y mageia aunque yo solo usaria debian y probaria en virtualbox.
ResponderExcluirTener muchas opciones no me molesta. Pero... quieres que yo elimine las mas productivas??
ExcluirMuito bom seu site. Volta e meia estou com problemas parecidos e é ótimo quando encontro as soluções aqui, porque sei que são bem documentadas! Hoje estou com um problema similar entre 3 sistemas: windows10, KaOS e Chakra. O KaOS não bootava depois da instalação (ainda não sei porque) e somente o Chakra conseguiu se instalar com o Windows (que entretanto perdi tentando instalar o KaOS :D) e chamar também o KaOS. Enfim, aprendendo sobre o boot (no meu caso, complicado pelo tal de SYstemD)
ResponderExcluirParabéns pelo excelente trabalho !!
ResponderExcluir