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:
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:
$ 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
Observe (acima) que:
-
A Bios tinha dado boot pelo “003D” – que não existe nesse seu 2º SSD
-
Neste segundo SSD, o efibootmgr detectou “0000,0001,2001”
-
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.
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
Não sei se eu tankei o que significa tankar,
E um termo pra significar “não consegui segurar a risada” e meio como rir alto em plena madrugada
Após instalar alguns apps em formato .deb no meu Void Linux, usando o xdeb (entre eles o Google Chrome do site oficial, e o módulo de segurança da Caixa Econômica), em algum momento (não me recordo o que estava instalando, acho que compilando o Google Chrome do xbps-src), a partição raiz do meu Void lotou e deu erro na compilação.
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/
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.
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.
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