Meu Void Linux LXQt parou de carregar o DE

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.

$ efibootmgr
BootCurrent: 003D
Timeout: 0 seconds
BootOrder: 0000,0001,2001
Boot0000* Ubuntu	HD(1,GPT,864668e2-719a-4070-adfd-0b38c9c2a39f,0x800,0x12c000)/File(\EFI\ubuntu\grubx64.efi)RC
Boot0001* opensuse-secureboot	HD(1,GPT,864668e2-719a-4070-adfd-0b38c9c2a39f,0x800,0x12c000)/File(\EFI\opensuse\shim.efi)
Boot2001* EFI USB Device	RC

$ efibootmgr -o 0001,0000,2001
BootCurrent: 003D
Timeout: 0 seconds
BootOrder: 0001,0000,2001
Boot0000* Ubuntu	HD(1,GPT,864668e2-719a-4070-adfd-0b38c9c2a39f,0x800,0x12c000)/File(\EFI\ubuntu\grubx64.efi)RC
Boot0001* opensuse-secureboot	HD(1,GPT,864668e2-719a-4070-adfd-0b38c9c2a39f,0x800,0x12c000)/File(\EFI\opensuse\shim.efi)
Boot2001* EFI USB Device	RC

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?

Isso não tava previsto no roteiro:

Manobras radicais:

O que mais você pensou que ele iria encontrar?

Manobras radicais ahsudhaushdhua, não tankei.

Não sei se eu tankei o que significa tankar, mas se for o que eu estou pensando… ninguém tá mais tankando nada do que o OP anda fazendo.

Recomendo isso, para que a gente consiga tankar direito:

1 curtida

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.

Prezado @Rommulo_Peixoto

Me parece que identificou, sim, e você não percebeu.

Mas do jeito como você escreve, é quase impossível ter certeza de que a gente entendeu o que você queria dizer.

Tente mostrar 1 foto de cada afirmação – e nunca faça 2 afirmações seguidas, sem 1 foto de cada uma.

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.

Você não precisa “provar” nada.

O que precisamos, é de “informação” (a foto do fato) – e não de “afirmação” (descrição verbal sujeita a mal-entendidos).

Aqui, por exemplo, eu estou vendo o Grub do openSUSE detectar o openSUSE – mas você diz que só detectou o Bodhi-Buntu:

Como vê, você dizia uma coisa, mas a foto estava dizendo outra coisa.

O openSUSE que foi detectado, seria esse do “Found theme”?
De todo jeito, eu declarei que ao reiniciar, aparecia um cursor na tela, e o que iniciava era o Bodhi ao teclar Enter. Gostaria que vc interpretasse isso como informação e não como afirmação, ok?

Pra tentar simpificar, eu desejo que no SSD do Void quebrado, o menu do segundo SO (Devuan) tome o lugar do menu do Void ao ligar o note, coisa que até agora não consegui fazer.

Peço desculpas pela expressão mais afirmativa que informativa.
No meu segundo SSD (com Bodhi e openSUSE), o comando apresentou "Found Ubuntu 22.04 LTS on /dev/sda3 (Bodhi), e não apresentou em seguida algo do tipo “Found openSUSE on /dev/sda2”

Isso… daí em diante… até o Aviso (Warning) do os-prober – que é quando começa a detecção de outras distros:

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.

Qualquer coisa que a gente “afirme”, é uma “afirmação” – sujeita a erros (seus, ou nossos, de interpretação).

Toda “afirmação” também está sujeita a “omitir” alguma coisa, cuja importância você ainda não percebeu – e a “imagem” permitirá que a gente perceba aquilo que você não tinha notado.

Daí, aquela recomendação básica, para tentarmos ajudá-lo no Fórum:

Em resumo: – Precisamos ver aquilo que você não está vendo – caso contrário, ficaremos tão perdidos quanto você.

Outra coisa… Seria melhor plugar os 2 SSDs ao mesmo tempo, para que o Grub e o efibootmgr não se confundam com essas manobras radicais:

Observe (acima) que:

  1. A Bios tinha dado boot pelo “003D” – que não existe nesse seu 2º SSD

  2. Neste segundo SSD, o efibootmgr detectou “0000,0001,2001”

  3. Você alterou a ordem para “0001,0000,2001”

… mas é provável que a Bios esteja confusa, pois considera que o boot foi feito pelo “003D”… que não existe nesse SSD.

A verdade é que nenhuma das suas “afirmações” inclui esse pequeno detalhe – porque você ainda não se deu conta dessas coisas – portanto, ficaríamos todos nós, presos em uma “falta de informação”.

Acredite na dica do Fórum! – Precisamos lidar com “fatos” – que você pode não estar vendo – e que por isso, não inclui nas suas “afirmações”.

Quero agradecer-lhe por sua paciência, e orientações sobre a composição de tópicos esclarecedores.

No 2º SSD, vou mover o dir “ubuntu” (.efi’s do Bodhi) de volta para /boot/efi/EFI/, e conectar essa unidade ao SATA-1 do note.
O 1º SSD (Void/Devuan e minha /home), vou inserir na entrada de DVD do note, usando um caddy.

Após isso, vou executar o grub2-… e o efibootmgr, e lhe darei retorno.

1 curtida

Eu recomendaria colocar seu SSD “principal” no Sata nº 1 – caso seu objetivo seja mantê-lo como “principal” no final de tudo isso.

Além disso, insista por algum tempo, pois a Bios pode demorar um pouco para entender a nova situação. – Tenho essa impressão, de que pode demorar um pouco.

Faça vários boot – entrando na Bios várias vezes – e execute o efibootmgr várias vezes.

Faça anotações das respostas aos comandos… Faça capturas de tela desses comandos todos… Fotografe cada entrada na Bios (antes e depois de fazer alterações)… Enfim, documente tudo, ao máximo.

Quanto estiver com os 2 SSDs plugados, execute também esses comandos:

$ lsblk -o name,mountpoint,label,fstype,size,fsavail,fsused,FSUSE%,uuid
NAME    MOUNTPOINT                  LABEL     FSTYPE   SIZE FSAVAIL FSUSED FSUSE% UUID
sda                                                  447.1G
├─sda1  /boot/efi                   EFI       vfat       2G      2G    33M     2% 7A0B-66EE
├─sda2  /var                        Linux1    btrfs     50G   16.4G  32.7G    65% e93c93ad-8397-4e94-bb26-26c769b1ee1d
├─sda3  /run/media/flavio/Linux2    Linux2    ext4      30G   12.5G  15.4G    52% 54f072c0-5b1c-43e2-b42a-232debf1ef4d
├─sda4  /run/media/flavio/Linux3    Linux3    ext4      30G   12.5G  15.3G    52% fc576ba0-2fd4-483b-b090-55d295f1dccf
├─sda5  /run/media/flavio/Linux4    Linux4    ext4      30G   13.3G  14.5G    50% ff537725-6716-4c2b-adcb-4d6fc7363955
├─sda6  /run/media/flavio/Linux5    Linux5    ext4      30G   13.4G  14.5G    49% e9bc1bdf-7e87-4822-a5e7-3b15cb9e3fd1
├─sda7  /run/media/flavio/Linux6    Linux6    ext4      30G   18.9G     9G    31% c5382186-c61b-487f-9646-f0e5960f8fa1
├─sda8  /home                       Home1     xfs       15G    6.7G   8.3G    55% ffd244bc-8c22-47a6-bfc6-df30408504c8
├─sda9  /run/media/flavio/Home2     Home2     ext4      15G    3.3G  10.7G    73% 5737d3f8-269f-4c28-a203-3c86f6fae670
├─sda10 /run/media/flavio/Home3     Home3     ext4      15G    8.1G   5.9G    40% 1eb92b4b-f8d8-4620-8aaf-df815197143a
├─sda11 /run/media/flavio/Home4     Home4     ext4      15G    6.4G   7.6G    51% 727546b6-57a8-46be-997e-ba1f8b21ba54
├─sda12 /run/media/flavio/Home5     Home5     ext4      15G    6.6G   7.3G    50% 93cfce0e-eee4-4972-a6d7-680c7e57a554
├─sda13 [SWAP]                      Swap      swap      11G                       a6bc03e6-ae71-4504-a8f5-c7bc79021e96
├─sda14 /run/media/flavio/Home6     Home6     ext4      15G    9.2G   4.7G    32% c82ea2d1-e58a-4fd3-a476-995d9d03b6c7
├─sda15 /run/media/flavio/Sites     Sites     ext4       2G    1.8G    24K     0% aa76e322-4144-4829-b270-7e0f226c87ad
└─sda16 /run/media/flavio/Works     Works     ext4       2G    1.8G    24K     0% fb187fcb-85b8-4e30-9066-956a44cda841
sdb                                                  447.1G
├─sdb1  /run/media/flavio/Linux7    Linux7    ext4      30G   15.9G  11.9G    41% 78220386-df94-4790-a3d6-1e2f626471f8
├─sdb2  /run/media/flavio/Linux8    Linux8    ext4      30G   11.9G    16G    54% be6a47ed-5268-4b29-be8e-19f04c6faee3
├─sdb3  /run/media/flavio/Linux9    Linux9    ext4      30G   16.7G  11.2G    38% 77670fae-2960-4fb1-9eab-461f14faadc8
├─sdb4  /run/media/flavio/Linux10   Linux10   ext4      30G      8G  19.8G    67% d95f77d3-511d-401c-93a7-09b6c10d2cd6
├─sdb5  /run/media/flavio/Linux11   Linux11   ext4      60G   32.5G  23.6G    40% 58f196fa-afdd-48a8-a586-4e3ee6ef550b
├─sdb6  /run/media/flavio/Linux12   Linux12   ext4      30G   19.2G   8.6G    29% 81d7d31c-8c58-4747-8222-bef171ce7e01
├─sdb7  /run/media/flavio/Home7     Home7     ext4      15G   10.2G   4.4G    30% 54151423-b3f7-4599-b2b0-da81727eaa1a
├─sdb8  /run/media/flavio/Home8     Home8     ext4      15G    9.8G   4.1G    28% 9c985f7f-662a-48c2-9b13-f5445bde7813
├─sdb9  /run/media/flavio/Home9     Home9     ext4      15G    7.5G   6.4G    43% 3a41a158-d201-4bd0-b442-f3715058d04f
├─sdb10 /run/media/flavio/Home10    Home10    ext4      15G    7.3G   6.6G    45% 0324be6b-12b3-4f4d-b20f-ff6af5a46bf7
├─sdb11 /run/media/flavio/Home11    Home11    ext4      15G      8G   5.9G    40% 49387323-c703-40e1-8afc-6b9728423166
├─sdb12 /run/media/flavio/Home12    Home12    ext4      15G    8.2G   5.7G    39% 73f1fe8c-5617-4666-9b3c-ff28f9a2ce17
└─sdb13 /run/media/flavio/Warehouse Warehouse ext4   147.1G  108.9G  27.5G    19% a192c2f3-d44a-48f4-9800-40578d52aeaf
sr0                                                   1024M

E este:

$ inxi -D
Drives:
  Local Storage: total: 894.26 GiB used: 269.91 GiB (30.2%)
  ID-1: /dev/sda vendor: Kingston model: SA400S37480G size: 447.13 GiB
  ID-2: /dev/sdb vendor: Western Digital model: WD Green 2.5 480GB
    size: 447.13 GiB

E um termo pra significar “não consegui segurar a risada” e meio como rir alto em plena madrugada

2 curtidas

Boa tarde meus chanceleres @Rommulo_Peixoto e @frc_kde. Acredito que o problema ocorreu por causa do xdeb, andei pesquisando e achei alguns posts da comunidade do void dizendo que quebrou o sistema usando o xdeb, kernel não carregava e etc. Como o @over.clk disse acima, onde ele é bem perigoso, não sei dizer se o xbps-src teve sua parte nisso, mas fica o aviso para o pessoal que quer usar o xdeb :D.

Fontes

Rapaz que teve um problema com xdeb:
https://www.reddit.com/r/voidlinux/comments/tafhsy/after_install_a_deb_via_xdeb_app_my_computer_nota/

Um rapaz que tentou instalar o glibc via pacote .deb:
https://www.reddit.com/r/voidlinux/comments/ve78ms/i_accidentally_broke_glibc_package_how_can_i_fix/

Aviso de um membro do VoidLinux

https://www.reddit.com/r/voidlinux/comments/tbd7xp/please_stop_using_xdeb_use_flatpak_instead/

1 curtida

Só lembrando que algumas firmwares travam a ordem de boot, sendo que vc precisa entrar nela para permitir a alteração ou então mudar a ordem por lá mesmo. O fato de dar boot pela 3D e não haver isso na saída do efibootmgr é um sinal de firmware que trava a ordem, bem como pedir a alteração, retornar sucesso, mas após o boot não ter sido alterada.

Também já me aconteceu de firmware quebrado (bug) que não trocava a ordem de firmware. Fiquei com ele daquele jeito até que um dia tirei o sistema antigo e não iniciou mais o computador até eu fazer o Clear CMOS. Mas nesse caso apresentava um erro maluco quando eu tentava adicionar uma nova entrada efi.

1 curtida

Olá Flamezito.

Minha partição Void lotou, justamente quando eu tentava instalar o Google Chrome oficial em formato .deb via xdeb. Então desconfio das duas causas: uso do xdeb e o fato de ter lotado uma partição BTRFS.

1 curtida

Olá amigo.
Agradeço pelo palpite sobre firmware.
Se bem que no meu caso, se eu usar meu primeiro SSD, onde estão o Void quebrado e o Devuan 5 KDE, que reinstalei como segundo S.O., meu firmware irá exibir a ordem de boot desse SSD.

Se eu colocar apenas meu 2º SSD onde está o openSUSE TB (Gnome45 e KDE Plasma juntos), o firmware já exibe o openSUSE.

Estou agora com o 1º SSD (do Void) no SATA-1 do notebook, e o 2º no slot do DVD (via caddy) e vou dar um grub2-mkconfig e efibootmgr pra ver se consigo alterar a ordem de boot, incluido o Devuan do 1º SSD e o openSUSE do 2º, assim como tbm inverter essa ordem.

Logo mais posto o resultado, também em resposta ao que me foi orientado pelo @frc_kde

1 curtida

Olá Flávio, olá a todos!

Peço desculpas pelo pouco retorno. Minha internet 4G, de 15 dias pra cá ficou pior que 2G… Coisas da vida na área rural, num lugar desprezado pelas operadoras, onde uma única ERB 4G da Vivo atende uma vasta região, e a esperança da comunidade local é que chegue por aqui algum provedor via rádio.

Praticamente com minhas atividades paradas, desde que o Void crashou e iniciei esse tópico, decidi reinstalar o Void para retomar minha rotina. Vou instalar o Big como segunda distro, por ser nacional e recheado de recursos, como por ex. a instalação simplificada do Waydroid. O site diz “Desempenho impressionante! Leve e rápido, existem computadores fabricados em 2007 utilizando a versão mais recente do BigLinux” (talvez desativando os efeitos visuais).

Com essa reinstalação, não estou de jeito nenhum pondo de lado as dicas postadas por vocês. O que vou fazer é praticá-las com calma, em algum outro HD* vago, nas horas livres, treinando as configs sobre grub em modo Legacy e UEFI. (*vai ser um HD pra por na bancada do Iberê Tenório e ligar nos 1.000V :laughing:)

Instalei primeiro a base (sem DE) do Void “musl”. Peguei um passo-a-passo de como instalar o KDE (que foi o que encontrei), mudando apenas os pacotes para LXQt (+ toda paciência com minha “turtle net”).

Está funcionando, com as limitações próprias do musl. O Xtreme Download Manager não roda de jeito nenhum, mesmo instalando o openjdk17-jre. Desconfio que ele gosta do glibc do meu Void anterior.

Alguns apps que eu usava em Appimage, encontrei em flatpak. Só não gostei do comando flatpak ter baixado de novo seus bancos que passam dos 800 MB, após eu ter demorado mais de 2h entre uma instalação e outra de apps flatpak.

Posso adiantar que fiquei surpreso com o boot em apenas 10 segundos, do Void musl LXQt, e o consumo inicial de meros 320 MB de RAM (htop). O Firefox v.118 e LibreOffice v.7.6.0.3 abrem em menos de 3 segundos.

Agora que acertei instalar o LXQt, vou reinstalar o Void, desta vez com glibc em que tudo funciona bem, inclusive os Appimages. No musl é quase um trabalho de parto fazer os Appimages funcionarem, criando-se links estáticos por meio do “libfuse.so” (li a respeito, mas sinceramente foi como ler algo em grego).
Após instalar, vou fazer nova leitura do tempo de boot, consumo inicial de RAM e tempo de carga dos apps que mais uso.

Reconheço que, ao relatar que reinstalei o sistema, fugi ao foco desse tópico (recuperar o sistema quebrado), sem ajudar outros leitores com problemas semelhantes. Por outro lado, não faz sentido criar um novo tópico, pois trato como “solução” essa mudança de rumo que tomei para sanar a mesma questão aqui debatida.

Para deliberar acerca da próxima distro a instalar, criei outro tópico com o título “Quem sabe um dia se torne realidade (ou já existe?)

Outros leitores com o mesmo problema, que lerem este tópico e conseguirem resolver com base nas dicas aqui postadas, peço que postem aqui suas resoluções.

Olá amigos!

Faço minhas as palavras de Fritzzin postadas num outro tópico criado por ele, que refletem exatamente como lido com este tópico:

Não vou escolher a “melhor resposta”, pois creio que toda esta discussão está sendo um ensinamento para mim e para outras pessoas. Creio que cada resposta aprofundou ainda mais o assunto. Por isso, novamente expresso minha gratidão a todos!