Sim amigo, foi uns tempos atrás que eu usava 2 sistemas em HD MS-DOS, e BIOS em Legacy, e o GRUB nunca dava problema.
Ao adquirir um SSD, mesmo de 256 GB, decidi mudar para BIOS UEFI e SSD em GPT por conta do particionamento mais eficiente.
Vc perguntou sobre meu /dev/sda. É o mesmo que postei no início desse tópico, porém figurou como /dev/sdb porque eu tinha dado boot com outro SSD e plugado esse (do meu Void danificado) num adaptador de HD externo…
Dispositivo, Início, Fim, Setores, Tamanho, Tipo
/dev/sda1 2048 38911 36864 18M BIOS inicialização (bios,boot) - sem uso!
/dev/sda2 38912 161791 122880 60M /boot/EFI (FAT32)
/dev/sda3 161792 84047871 83886080 40G (Void em BTRFS)
/dev/sda4 84047872 167995391 83947520 40G (Devuan em BTRFS)
/dev/sda5 167995392 483340287 315344896 150,4G Linux sistema de arquivos (/home em ETX4)
/dev/sda7 483340288 500117503 16777216 8G Linux swap
Anteriormente eu tinha o Mint MATE em /dev/sda3 e Lubuntu (ou outro, não lembro mais) em /dev/sda4.
Decidi instalar o KDE Neon no sda4, e ao reiniciar, o Mint MATE foi totalmente ignorado, nem aparecia na tela do GRUB. KDE Neon egoísta!..
Tempos depois, instalei o Void no lugar do Mint (sda3) e ele reconheceu o KDE Neon no sda4.
E por fim, substituí o Neon pelo Devuan Chimaera, mas o menu de inicialização continuou sendo o do Void e exibia o KDE Neon. Chimaera altruísta! (oposto do Neon, pois se instalou e não mexeu nada no GRUB). Por isso tive que editar o grub.cfg “na unha”…
Pelo visto, suas experiências tanto com MBR quanto GPT foram incômodas, quanto ao GRUB.
O único sistema que instalei, e deixou o Grub redondo, foi o Garuda Linux. Aliás, ele cria uma bela tela de inicialização, até com wallpaper. Talvez eu até volte pra ele, já que aceita AUR e flatpaks.
Amigo, perdoe se eu dei canseira. Sou usuário entre iniciante e intermediário, e com certeza não interpretei direito a sua explicação. Mas considere o que eu te perguntei inicialmente: “Qual seria o procedimento pra tentar recompor o FS?”
Localizei o arquivo oculto .Xauthority em minha /home usada pelo Void. Tentei abrir com um editor de textos, mas aparecem apenas caracteres truncados, e em propriedades do arquivo (no menu de contexto do mouse) informa “Tipo: Desconhecido”, tanto esse quanto o que tá na /home do Devuan.
O que poderia ser feito com esse arquivo, pra recuperar o acesso?
Poderia substituir esse arquivo pelo que tá na outra /home?
Vou dar boot numa live-USB e usar o comando e2fsck pra checar a /home. Espero que não dê perda de dados, pois no momento estou sem HD de backup (o que tenho começou a dar problemas no SMART e ainda vou adquirir outro).
Ao instalar uma nova distro, o Grub dela “se apossa do boot”. – Por exemplo, quando fiz upgrade do Mageia, o boot passou a levar direto para o Grub do Mageia:
O Grub do seu KDE Neon deve estar com Os-Prober desativado – por isso, ele não procurou detectar outras distros – e não incluiu o Mint MATE.
Ou seja, o Grub do Void estava com Os-Probe habilitado – e por isso, procurou detectar outras distros instaladas.
Ou seja, o Devuan não instalou seu próprio Grub, ou não se apossou da prioridade no boot – porque você não fez essa escolha, durante a instalação – ou porque o instalador dele não vinha com essa escolha pré-definida.
E o Grub do Void continuou exibindo KDE Neon (em vez do Devuan), porque você não executou o comando para atualizá-lo, depois de instalar o Devuan.
Após instalar uma nova distro, é necessário atualizar o Grub da outra distro, para detectar a novidade.
Editar o “grub.cfg” é trabalho insano. – O mais prático é atualizar o Grub – que vai atualizar o “grub.cfg”, vapt-vupt.
Todo aprendizado é um “incômodo”! – É preciso descobrir a causa do problema… em seguida pesquisar, até descobrir a solução… testar a solução…
Mas ficar com um problema não-resolvido – e não aprender – é muito mais incômodo!
Por isso, aproveito para anotar os problemas, anotar as causas, anotar as soluções. – Observe que naquele link fui anotando várias coisas, durante vários anos… para não esquecer, quando precisar de novo.
“Mas ficar com um problema não-resolvido – e não aprender – é muito mais incômodo!”
Estou tomando nota de tudo o que postaram aqui, inclusive esse lema acima
O comando ‘efibootmgr’ é mais um aprendizado aqui. Antes eu usava os painéis de ajustes manuais do grub-customizer, que também deixaram de produzir os resultados esperados.
Não me recordo se usei ‘update-grub2’ antes de editar o grup manualmente. Mas sim, prefiro usar esse comando.
Dei uma olhada na postagem de “battlestoriesfan”:
“O kernel que a minha distro estava usando está bichado, e fica criando arquivos de log GIGANTESCOS”.
Eu já estava gostando do workflow do Gnome 44 no openSUSE Tumbleweed, mas me deparei com o problema de adicionar conta online do Google, por conta de bugs provocados pelo driver nvidia (pelo menos é o que se relatou em vários fóruns sobre esse problema). E agora tem mais essa questão do kernel.
Vou testar na versão KDE, e tentar adicionar pelo menos o Google Calendar como widget, e o Gdrive pelo Kio-GDrive. O openSUSE lidera o ranking de testes de desempenho aqui do Diolinux.
Esse comando “update-grub” ou “update-grub2” só existe em algumas distros – Debian (e derivados) e “Buntus” (e derivados) – mas também no Manjaro (mas não no Arch).
Reinstalei o Devuan em /dev/sda4, apliquei o update-grub, e curiosamente o menu de inicialização continua sendo o do Void. Estou então recorrendo à BIOS para escolher o Devuan.
Enquanto isso, o Void permanece morto.
Vendo a última resposta de “aguamole”, dei uma olhada no .Xauthority, e por mera curiosidade, decidi renomeá-lo para .bak e copiar o de uma outra /home, mas não resolveu.
Nos tempos do Linux Mint, eu usava o Aptik pra fazer backup de todas as configs do usuário. Vou ver se isso resolve no Devuan, ou sem tem ferramenta melhor.
Não sei como seria um trabalho de recompor o FS, quais passos teria que dar.
Já estou equipando o Devuan daedalus KDE (runit / Wayland) com os apps que usava no Void. Alguns apps que ficam no tray, o Devuan simplesmente os fecha (ex.: Xtreme Donwload Manager, Joplin, Stacer)
O PCManFM-Qt às vezes trava.
O Discover acusa que “não foi possível carregar os aplicativos. Verifique sua conexão com a Internet”. Vários posts no Google relatam o mesmo problema, e acho que no meu caso foi pq usei a mesma /home do Void. Tem gente que criou outro usuário novo, no qual o Discover voltou a funcionar. Mas o synaptic pra mim roda de boa, então estou usando ele e o apt install.
Amigo, ando com uns lapsos de atenção ao que me é dito aqui… Vou tomar uma vitaminas pro cérebro.
Então, usei o efibootmgr -o e reordenou na hora.
Mas ao reiniciar, volta ao que era antes… no gerenciador de boot da BIOS, até mostra a reordenação dos diretórios em /boot/EFI, mas o menu de inicialização continua sendo o do S.O. instalado por último.
Eu me refiro a um outro SSD onde instalei primeiro o openSUSE TB Gnome no /dev/sda2, e por último o Bodhi 7.0 em /dev/sda3.
Quando usei o efibootmgr -o pra ordenar o openSUSE em primeiro lugar, como era meu desejo, o que entrou ao reiniciar foi o menu do Bodhi.
Foi por isso que eu disse “Volta ao que era antes”, ou seja, volta ao menu do Bodhi, e esse nem sequer aparece, fica só um cursor piscando, até eu dar Enter pra iniciar o sistema.
Mas quando reinicio, o boot order volta a ser “0000,0001,2001”
Se funcionasse, eu faria o mesmo no SSD onde está o Void quebrado, pra colocar o Devuan em primeiro, já que esse tá bootando normal.
Acabei de fazer outra manobra:
Entrei em /boot/efi/EFI/ e removi “ubuntu” que era do Bodhi, deixando apenas “boot” e “opensuse”. E deu certo! O menu do openSUSE agora aparece, assim que ligo o note.
Não deletei “ubuntu”, apenas movi para um diretório acima.
Fiz essa manobra sem pensar nas consequências, pois estou usando esse segundo SSD apenas para testar o openSUSE e o Bodhi. De todo jeito, foi uma solução nas coxas, feita na unha mesmo…
Referindo-me ao meu outro SSD, onde instalei o openSUSE em /dev/sda2 e Bodhi em /dev/sda3:
$ grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-6.5.4-1-default
Found initrd image: /boot/initrd-6.5.4-1-default
Found linux image: /boot/vmlinuz-6.4.12-1-default
Found initrd image: /boot/initrd-6.4.12-1-default
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Ubuntu 22.04 LTS on /dev/sda3
Adding boot menu entry for UEFI Firmware Settings ...
done
Não entendo isso. Estou agora usando openSUSE de /dev/sda2, e o grub2-mkconfig só encontrou o Ubuntu 22.04 (meu Bodhi) da /dev/sda3?
Certo, esse meu outro SSD não tava previsto no roteiro. Eu apenas o usei para evitar mexer no SSD onde está o Void quebrado, já que minha partição /home (ainda aguardando um novo HD de backup) também está no mesmo SSD do Void.
Então, caso lograsse o resultado desejado com efibootmgr e grub2-mkconfig, eu iria repetir os mesmos comandos no SSD do Void.
O que mais pensei que o grub2-mkconfig iria encontrar? No meu segundo SSD (com Bodhi e openSUSE), ele só identificou /dev/sda3 (Bodhi), e ignorou /dev/sda2 (openSUSE).
Como era o openSUSE que eu estava usando quando dei esse comando, suponho (na minha ignorância) que o grub2-… deveria identificar também o sda2.
O fato é que, após executar o grub2-…, reiniciei o notebook, aí apareceu apenas um traço branco piscando no canto superior esquerdo da tela, e bastou teclar [Enter] para iniciar o Bodhi, justamente o da sda3 que foi identificada pelo grub2-… o Bodhi não criou adequadamente o menu de inicialização, daí o cursor piscante. Eu imaginava que o grub2-mkconfig poderia criar um menu alternativo, exibindo Bodhi e openSUSE.
Depois que movi o diretório do Bodhi pra fora de /boot/efi/EFI, e mantive aí apenas “boot” e “opensuse”, o menu de inicialização do openSUSE voltou à cena e não precisei mais escolher o S.O. pelo boot-manager da BIOS.
Quando vc postou seu comentário, eu estava reeditando minha mensagem, tentando melhorar a descrição dos fatos. Mas vou postar o print do comando grub2-mkconfig e também do efibootmgr, embora a melhor prova seria uma filmagem sem cortes, desde a execução desses comandos até reiniciar o note.
