O comando que você precisa para criar uma nova “entrada” para o KDE Neon no “efi” é, mesmo, o grub-install – porém é preciso descobrir os parâmetros corretos. – Infelizmente, só fiz isso com o Arch (exemplo adiante).
Digo “criar uma nova entrada”, porque me parece a solução mais simples. – Resista à tentação de deletar a “entrada” antiga. – Deixe ela quietinha, que não faz mal a ninguém (rs).
Como não tenho uma “solução pronta”, só posso falar da minha própria experiência.
Vamos, primeiro, “simplificar” as coisas – o que talvez ajude a formar uma ideia mais clara:
São 2 coisas bem diferentes, e bem separadas:
-
seleção de boot da UEFI do notebook
-
sudo grub-update
A “seleção de boot da UEFI do notebook” é o que você mostrou nesta imagem:
Isso varia conforme a marca & modelo da placa-mãe, pois cada uma tem seu próprio “firmware”.
No meu PC, aparece já na tela inicial do “UEFI Bios Utility” – quando aperto DEL durante o boot, para alterar alguma configuração do hardware:
Observe que em cima (à direita) são listadas 4 opções – openSUSE, Mageia, Debian, PCLinuxOS. – É uma lista de “Prioridade de Boot”. – Se eu arrastar uma opção de baixo para o topo da lista, essa opção passará a ter a “prioridade de boot”.
Logo embaixo, há uma indicação de “F8 Boot Menu”, que me apresenta a “lista completa” – pois tenho várias outras “opções” – Slackware, Fedora, Arch, Redcore etc:
De onde “vieram” essas “opções”? – Elas estão na partição “efi” – aquela partição pequena, Fat32, também indicada como “vfat”:
# lsblk -o name,mountpoint,label,fstype,size,fsavail,fsused,FSUSE%
NAME MOUNTPOINT LABEL FSTYPE SIZE FSAVAIL FSUSED FSUSE%
sda 447.1G
├─sda1 /boot/efi EFI vfat 2G 2G 35.6M 2%
├─sda2 /run/media/flavio/Linux1 Linux1 btrfs 50G 17.1G 29.9G 60%
├─sda3 / Linux2 ext4 30G 12.6G 15.3G 52%
├─sda4 /run/media/flavio/Linux3 Linux3 ext4 30G 14.7G 13.2G 45%
├─sda5 /run/media/flavio/Linux4 Linux4 ext4 30G 12.2G 15.6G 53%
├─sda6 /run/media/flavio/Linux5 Linux5 ext4 30G 13.6G 14.2G 48%
├─sda7 /run/media/flavio/Linux6 Linux6 ext4 30G 18.5G 9.3G 32%
├─sda8 /run/media/flavio/Home1 Home1 xfs 15G 6.3G 8.7G 58%
(...)
Tempos atrás, iniciei uma sessão Live, montei a partição “efi” em /mnt, e salvei seu conteúdo, para documentar como era, naquele momento:
$ tree mnt
mnt
├── EFI
│ ├── boot
│ │ ├── BOOTIA32.EFI
│ │ ├── bootx64.efi
│ │ ├── fallback.efi
│ │ ├── fbia32.efi
│ │ └── fbx64.efi
│ ├── fedora
│ │ ├── BOOTIA32.CSV
│ │ ├── BOOTX64.CSV
│ │ ├── fonts
│ │ │ └── unicode.pf2
│ │ ├── gcdia32.efi
│ │ ├── gcdx64.efi
│ │ ├── grub.cfg
│ │ ├── grubenv
│ │ ├── grubia32.efi
│ │ ├── grubx64.efi
│ │ ├── mmia32.efi
│ │ ├── mmx64.efi
│ │ ├── shim.efi
│ │ ├── shimia32.efi
│ │ ├── shimia32-fedora.efi
│ │ ├── shimx64.efi
│ │ └── shimx64-fedora.efi
│ ├── neon
│ │ ├── BOOTX64.CSV
│ │ ├── grub.cfg
│ │ ├── grubx64.efi
│ │ ├── mmx64.efi
│ │ └── shimx64.efi
│ ├── opensuse
│ │ ├── boot.csv
│ │ ├── fw
│ │ ├── fwupdx64.efi
│ │ ├── grub.cfg
│ │ ├── grub.efi
│ │ ├── grubx64.efi
│ │ ├── MokManager.efi
│ │ └── shim.efi
│ ├── pclinuxos
│ │ └── grubx64.efi
│ └── ubuntu
│ ├── fw
│ ├── fwupx64.efi
│ └── grub.cfg
├── mach_kernel
└── System
└── Library
└── CoreServices
└── SystemVersion.plist
13 directories, 38 files
Até aquele momento, eu tinha instalado apenas 4 distros – openSUSE, Fedora, KDE Neon e PCLinuxOS – em um SSD “limpo”, zero-km, que nunca tinha sido sequer formatado. Nenhuma “herança” anterior.
No entanto, veja que aparece 1 subdiretório “neon” e 1 subdiretório “ubuntu”. – Pelos registros da época, verifico que ambos tinham sido criados na mesma data e hora: “2020 Jan 12, às 16:43”. – Só posso concluir que aquelas 2 pastas pertenciam ao KDE Neon.
Quando você inicializa uma distro Linux instalada, ela monta essa partição “efi” em algum lugar do diretório /boot – como se fosse uma sub-pasta ou sub-diretório daquela distro. – Hoje, por exemplo, está assim (visto “dentro” do Arch):
# tree /boot
/boot
├── efi
│ ├── EFI
│ │ ├── arch_grub
│ │ │ └── grubx64.efi
│ │ ├── arch_grub2
│ │ │ └── grubx64.efi
│ │ ├── boot
│ │ │ ├── BOOTIA32.EFI
│ │ │ ├── bootx64.efi
│ │ │ ├── fallback.efi
│ │ │ ├── fbia32.efi
│ │ │ ├── fbx64.efi
│ │ │ └── mmx64.efi
│ │ ├── Debian
│ │ │ ├── BOOTX64.CSV
│ │ │ ├── fbx64.efi
│ │ │ ├── grub.cfg
│ │ │ ├── grubx64.efi
│ │ │ ├── mmx64.efi
│ │ │ └── shimx64.efi
│ │ ├── fedora
│ │ │ ├── BOOTIA32.CSV
│ │ │ ├── BOOTX64.CSV
│ │ │ ├── gcdia32.efi
│ │ │ ├── gcdx64.efi
│ │ │ ├── grub.cfg
│ │ │ ├── grub.cfg.rpmsave
│ │ │ ├── grubenv.rpmsave
│ │ │ ├── grubia32.efi
│ │ │ ├── grubx64.efi
│ │ │ ├── mmia32.efi
│ │ │ ├── mmx64.efi
│ │ │ ├── shim.efi
│ │ │ ├── shimia32.efi
│ │ │ └── shimx64.efi
│ │ ├── mageia
│ │ │ └── grubx64.efi
│ │ ├── MX
│ │ │ └── grubx64.efi
│ │ ├── MX21
│ │ │ └── grubx64.efi
│ │ ├── neon
│ │ │ ├── BOOTX64.CSV
│ │ │ ├── grub.cfg
│ │ │ ├── grubx64.efi
│ │ │ ├── mmx64.efi
│ │ │ └── shimx64.efi
│ │ ├── opensuse
│ │ │ ├── boot.csv
│ │ │ ├── fw
│ │ │ ├── fwupdx64.efi
│ │ │ ├── grub.cfg
│ │ │ ├── grub.efi
│ │ │ ├── grubx64.efi
│ │ │ ├── MokManager.efi
│ │ │ └── shim.efi
│ │ ├── pclinuxos
│ │ │ └── grubx64.efi
│ │ ├── Redcore
│ │ │ └── grubx64.efi
│ │ ├── slackware-14.2+
│ │ │ └── grubx64.efi
│ │ └── ubuntu
│ │ └── grub.cfg
│ ├── mach_kernel
│ └── System
│ └── Library
│ └── CoreServices
│ └── SystemVersion.plist
(...)
Observe que continua existindo 1 pasta “neon” e 1 pasta “ubuntu” – embora hoje eu tenha 2 instalações do KDE Neon (em dualboot ou multiboot). – Duvido que isso “funcione”, para 1 dos 2 KDE Neon. Felizmente, não uso, nem dependo deles, pois uso o Grub do openSUSE.
No Arch, o caminho (PATH) é /boot/efi/EFI – mas pode acontecer que alguma distro use “efi” em minúsculas. – Só consigo acesso, como root, ou usando sudo:
Note que existem 2 opções, ou “entradas”: /arch_grub e /arch_grub2 – porque aconteceu algum problema, que eu não consegui consertar, então apenas criei uma nova entrada – usando o comando grub-install que é familiar a quem já instalou o Arch “na unha”:
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub2 --recheck
Observe a quantidade de “parâmetros” utilizados com o comando!
“Peguei” esse comando, já “pronto”, ao ler a Wiki do Arch para aprender como “instalar na unha”. – Não sei o que cada “letrinha” faz, e não sei quais alterações teria de fazer, no caso do KDE Neon. – O importante, é descobrir quais alterações precisaria fazer (ou não) para usá-lo no KDE Neon.
Imagino (apenas imagino!) que o parâmetro --target=x86_64-efi seja +/- comum a todas as distros – mas não posso afirmar.
Me parece que o parâmetro --efi-directory=/boot/efi indica o “caminho” (PATH), pois esse comando é para usar “dentro” do Arch Linux instalado – e nele, a partição “efi” está montada em /boot/efi. – Talvez seja assim em outras distros, mas nunca verifiquei.
Acho que o parâmetro --bootloader-id=arch_grub2 diz o nome da pasta (subdiretório) que eu estava criando – e neste caso o “2” em arch_grub2 foi uma opção pessoal minha, para diferenciar da outra “entrada”, que não estava mais funcionando.
Enfim, “imagino” que o parâmetro --recheck manda re-checar alguma coisa (não me pergunte o quê!).
Existem “versões” diferentes desse comando + parâmetros, na Wiki do Arch. – Escolhi o que me pareceu “mais completo” – pois minha ignorância não me permitia fazer coisa melhor. Felizmente, deu certo.
Essa foi a 3ª vez que usei esse comando. – Eu já tinha usado quando fiz minha 1ª instalação do Arch “na unha” (antigo PC, sem UEFI) – e a 2ª vez, quando instalei o Arch no meu PC atual (UEFI).
Bom, deixei lá a “entrada” anterior /arch_grub – que não funciona mais. – Meu conselho é: “deixe quieto!” (rs).
Eu já deletei “entradas” – seja pelo comando efibootmgr, e também deletando “fisicamente” algum subdiretório que não queria mais. – Cometi erros, deletei alguma coisa que não devia (felizmente, não me prejudicou), e hoje meu conselho é: “deixa quieto!”.
(Existe um tópico, aqui no Fórum, onde descrevi o que andei fazendo – inclusive os erros que cometi).
Apesar de ter um “grub” nesse comando – repito: – “EFI” e “grub” são coisas bem distintas, separadas.
Esse comando apenas “ensina” ao “efi”, onde deverá procurar o Grub.
O comando ´update-grub´ não terá nenhum efeito sobre o “efi”.
Hoje em dia, não uso mais “arrastar e soltar” na tela do UEFI Bios Utility. – Quando alguma distro “se apossa” da prioridade de boot, prefiro usar o comando efibootmgr para recolocar o openSUSE no topo das prioridades:
KDE Neon (user) -- após PCLinuxOS se apossar da prioridade na "efi"
$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0004,0000,0001,0003,000A,0002,0005,000E,0006,0007,000B,000F
Boot0000* opensuse
Boot0001* debian
Boot0002* Fedora
Boot0003* mageia
Boot0004* pclinuxos
Boot0005* arch_grub
Boot0006* arch_grub2
Boot0007* MX Linux
Boot000A* slackware-14.2+
Boot000B* neon
Boot000E* Redcore
Boot000F* debian
$ date; sudo efibootmgr -o 0000,0001,0003,000A,0002,0005,000E,0006,0007,000B,000F,0004
Tue 13 Feb 11:59:12 -03 2024
[sudo] password for flavio:
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0003,000A,0002,0005,000E,0006,0007,000B,000F,0004
Boot0000* opensuse
Boot0001* debian
Boot0002* Fedora
Boot0003* mageia
Boot0004* pclinuxos
Boot0005* arch_grub
Boot0006* arch_grub2
Boot0007* MX Linux
Boot000A* slackware-14.2+
Boot000B* neon
Boot000E* Redcore
Boot000F* debian
Quando o PCLinuxOS “se apossou da prioridade”, apareceu o Grub do PCLinuxOS:
(Sim, configurei o Grub do PCLinuxOS para detectar apenas ele mesmo – para não perder tempo detectando outras distros).
Quando o Mageia “se apossou da prioridade de boot” na EFI, apareceu o Grub do Mageia:
(O Grub do Mageia é meu “Grub de reserva”, por isso, deixo ele detectar as outras distros).
Meu Grub preferido é o do openSUSE – o único que consegue detectar e carregar qualquer uma das outras 25 ou 30 distros que já tive:
Então, é isso: – Ao configurar a “prioridade de boot” no “efi”, estamos apenas dizendo “onde” procurar o Grub – em qual partição, em qual distro.
P.S.: - Esqueça os links que postei antes. – O que pode ser útil é este.