quinta-feira, 29 de junho de 2017

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 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.

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


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

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:

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:

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 sdaGrub do Mageia (sda2)
  • MBR do sdbGrub do openSUSE (sdb2)
  • MBR do sdcGrub 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).

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 OptionsConfigure 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


4 comentários:

  1. 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.

    ResponderExcluir
    Respostas
    1. Tener muchas opciones no me molesta. Pero... quieres que yo elimine las mas productivas??

      Excluir
  2. Muito 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)

    ResponderExcluir
  3. Parabéns pelo excelente trabalho !!

    ResponderExcluir