Meu Void Linux LXQt parou de carregar o DE

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.

A então volto a carregar?

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