Byteria: Escolhendo Grub entre vários Linux

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, — afora situações específicas, — 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.

Índice

Infância dos fatos
Fatos espinhosos

Caso 1 - Arch (intel-ucode)

Caso 2 - BtrFS sem “/boot” separado

Caso 3 - Neon com falha

Caso 4 - 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

Making of

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” 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, 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) sobreviveu 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 partição de sistema e, dentro dela, 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 (acho) sugerir a instalação da “chamada” do Grub em 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 escolhia o sda. — No instalador do Debian, dizem que essa escolha é oferecida, mesmo quando se opta pelo “particionamento automático”.

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 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á ocorreu descobrir que faltava instalar syslinux, extlinux ou os-prober, — para realizar alguma tarefa em uma distro. — Falta ver se todas as outras já têm (ou se precisam ter).

Em tese, “basta” descobrir quais pacotes estão fazendo falta. — Depois disso, 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 conter mais uma indicação:

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

onde “XXXXXX” pode variar, em alguns casos, — ou não, em outros.

No Manjaro, — com 2 Kernel, 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, — e talvez devido a opções pessoais, — “XXXXXX” ainda não apresentou 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 Arch (ou do Manjaro) seria o candidato natural, para deter o controle do Menu de inicialização, — sem necessidade de 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 nenhum indício de que alguma dessas “receitas” tenha alcançado ampla aceitação.

Enfim, o Arch instalado pelo Anywhere não tem nada disso, — e carrega pelo Grub de qualquer outra distro, sem a menor dificuldade. — Infelizmente, ainda não consegui, nele, coisas tão básicas como Teclado ABNT2 (configurado durante a instalação!), desativar o Kwallet, y otras cositas más.

Ainda cabe testar a instalação pelo Architect, — e mais adiante, instalar “na unha”, quando tiver aprendido o bastante, para valer a pena uma personalização detalhada.

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) todos os demais Linux.

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, — 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, seria o candidato natural, para deter o controle. — Chegou a ser adotado como padrão (até foi personalizado), e ainda é mantido como “alternativo”.

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.

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

Caso 3 - Neon com falha

Reconfiguração do Grub para tentar automatizar o uso de “nomodeset” para o KDE Neon

Situação bem diversa, — inteiramente ocasional (a solucionar), — vem acontecendo desde a reinstalação do KDE Neon, que agora só carrega se “quiet splash” for substituído por “nomodeset”.

E disso não escapa nem seu próprio Grub, — mesmo reconfigurado para usar o parâmetro “nomodeset”.

Este problema também pode ser corrigido “manualmente”, — tanto em seu próprio /boot/grub/grub.cfg, quanto no de qualquer outro Linux, — por busca-e-substituição global:

Substituir

root=UUID=XXXXXX ro quiet splash $vt_handoff

por

root=UUID=XXXXXX ro nomodeset $vt_handoff

onde o uso do UUID evita afetar as entradas de outras distros instaladas.

Como se trata de um caso anômalo, — e há outros problemas, nas tentativas recentes de reinstalar o KDE Neon, — a prioridade é solucionar a falha existente nas várias tentativas de reinstalação.

Nada a ver com o Grub. — É a instalação do KDE Neon que precisa ser consertada (quando descobrir como).

Caso 4 - 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 levaram à localização imediata da solução, numa postagem onde se relatava o problema no Grub gerado pelo Manjaro.

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, — o Grub do Mageia acabou se destacando como o mais indicado, para esse conjunto de 7 distros instaladas (e mais algumas, já removidas).

Os principais motivos:

1) É o único que consegue 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 num 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, — pelo contrário, torna mais frequentes as atualizações de Kernel, — que obrigam a carregar o Mageia, para atualizar o Grub (e tornar a fazer as correções “manuais”).

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

São fatores “neutros”, portanto, — não influem na escolha do Grub “A” ou “B”. — E de qualquer modo, são correções fáceis e rápidas (principalmente depois que o Manjaro foi trocado pelo Arch).

Numa comparação informal com “tipos de sangue”, diria que se trata de escolher aquele que seja “o mais universal doador & receptor”, — ou seja, aquele que seja carregado pelo Grub de todas as outras distros (ou da maioria delas), — e cujo Grub seja capaz de carregar todas as outras distros (se possível). Após testar umas 20 distros em dualboot (não todas de uma só vez), o Mageia 6 sta2 foi quem levou o Oscar, e ainda segue imbatível. Façanha invejável, para uma comunidade com limitações de recursos e colaboradores.

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, — foi copiado o tema do Grub do openSUSE, cuja personalização já ia bem avançada.

As edições foram feitas 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

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

Dois pequenos sustos, nos dias 16 e 28 Jun. 2017, levaram a reavaliar velhos hábitos, — bem como, a corrigir ideias erradas (ou superadas), — e finalmente sistematizar soluções que, até então, vinham sendo improvisadas aqui e ali, de modo disperso.

E mais do que apenas sistematizar as soluções adotadas, 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, suas próprias Opções avançadas, e Testes de memória.

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 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 as ideias, fatos, motivos etc. estavam fragmentados, — e passava da meia-noite, quando todos os gatos parecem cachorros pardos, rosnando. — Para complicar, os avanços do KDE vêm desabilitando o uso do Krusader, Dolphin, Kate como Superusuário (Root) em várias distros, fazendo velhos hábitos tropeçarem a cada passo.

Quadro das distros atualizadas, após a revisão geral de 28 Jun. 2017

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 serviu para revisar o assunto de A a Z, documentar configurações e ferramentas usadas em cada distro, — além de aproveitar para fazer as atualizações de todas as distros não-utilizadas durante a semana.

Ficou claro que 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 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 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 “independente” 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 o “último salva-vidas” dependente de apenas 1 distro, para se manter atualizado.

Poderia ficar excessivamente desatualizado, — caso não use aquela distro com frequência, — ao passo que 5 distros em “corrida de revezamento” garantem atualizações mais frequentes.

Reconfiguração do Grub

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

O caminho para fazer isso, — no Debian & derivados, — finalmente foi encontrado, 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 deve gravar sua “chamada”, — sendo possível escolher mais de um.

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 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 para a qual 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 objetivos de 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, — 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. Nas horas mais inconvenientes.

Use Ctrl-Shift-V para colar expressões 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, — mas, para lembrar algumas diferenças e seguir adiante sem perder tempo, convém que a maioria dos outros procedimentos seja tão padronizada 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

Diante de 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).

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/

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). — Tecnologias mais recentes, por enquanto, interessam apenas com vistas a um futuro computador. Não são o dia-a-dia.

O sistema de arquivos BtrFS foi aceito, ao instalar o openSUSE, como única maneira de tomar conhecimento “concreto” do que é, para que serve, como funciona, consequências e implicações, — pois estava claro que 200 horas de simples leitura não iam levar a nada. — LVM fica para o futuro (se e quando interessar, coisa que no momento parece improvável).

Não havia motivo para alterar o planejamento, só para criar uma partição de Boot separada, no openSUSE. — Aliás, nunca teria percebido o problema, — nem, consequentemente, 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 apenas 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, pelas interfaces gráficas 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.

— … ≠ • ≠ … —

Byteria

quinta-feira, 29 de junho de 2017

Escolhendo Grub entre vários Linux