 |
| 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
- Um por todos vs. Todos por um
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.
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.
— … ≠ • ≠ … —
Não-debians
