 |
| 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:
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).
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/
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
- 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
