Local do gerenciador de inicialização

Um pequeno descuido, falta de atenção e falta de comunicação por partes dos youtubers no mundo linux é a causa dos maiores problemas para aqueles que estão migrando para o linux.

Boa tarde a todos, esse final de semana pesquisei 4 distros novas para meu setup que são: Vanilla OS, KDE neon plasma 6 , openKylin 2.0 e o lingmo OS

Testei as 4 o dia inteiro e me surpreendi com o KDE neon e o Lingmo OS.
Lingmo OS baseado no debian usando o kernel 6.10-AMD64 resolvi instalar na máquina já que achei ele uma gracinha (no bom sentido, peppermint não fique com ciúmes tá?) pois bem, vamos instalar lado a lado no SSD do windows 11, escolhi o tanto de espaço para o lingmo OS e me deparo com esse recurso “Local de gerenciador de inicialização” que resolvi instalar no SSD onde está o win11, já que o SSD que está meu LM e PmosOS é outro SSD que já tem o grub já configurado.

O sistema foi instalado com êxito vamos reiniciar pra curtir, redirecionei o boot do SSD do windows11 onde foi instalado o lingmoOS e me deparo com isso “Missing Operation System” galera aonde foi que errei, o que fiz de errado ?
Entrei no LM, abri o terminal e executei o comando “sudo update-grub2” reiniciei a máquina e o grub identificou o LingmosOS no meio das minhas distros e selecionei para executar e me deparo com essa mensagem " kernel não encontrado, você tem que escolher o Kernel primeiro" lembrando que esse kernel é visto na raíz mas o grub não o inicia, não aparece outro kernel pra testar como o 5.15 ou o 6.1

Voltei ao linux mint, abri o “discos” exclui a partição do lingmoOS, abri o terminal com o comando “sudo update-grub2” para não usar o boot-repair, voltei o win11 para espandir o espaço não alocado e pronto.

Instalei o KDE neon no mesmo processo só que desta vez no "local de gerenciador de inicialização, eu decidi colocar no SSD onde está o grub do LM e o KDE neon funcionou perfeitamente, lembrando que o KDE neon foi instalado num SSD e o local do gerenciador de inicialização foi em outro SSD onde está o grub.

Agora eu pergunto aos senhores, por que ninguém falou ou explicou sobre isso em vídeos e tutoriais ?
Eles não explicaram sobre o “local de gerenciador de inicialização” em canto nenhum e passaram batido. Como que uma pessoa dessa pode ser chamado de influenciador ?

1 curtida

Tudo deu errado quando vc deixou de seguir o que estava pré-definido e agiu por conta própria.

A maioria dos vídeos de tutoriais tendem a ser o mais simples possível, para que se possa alcançar o máximo de pessoas possível. Um vídeo simples e direto ao ponto, sem muita explicação dos pormenores, irá atender tanto uma pessoa sem conhecimento nenhum, pois ela vai só seguir exatamente o que lhe for dito, e também servirá a um usuário avançado, pois ele já tem noção de que pode fazer certas coisas diferentes e estará mais disposto e preparado para caso algo dê errado.

No seu caso, vc já tinha um grub instalado e o instalador sabia disso, quando vc trocou o “local do gerenciador” para o ssd atual, onde o grub não estava, o instalador não colocou outro grub nesse ssd e não criou a entrada desse sistema no grub já instalado.

Um YTber geralmente não vai levar em consideração um setup de dualboot +1 sistema em um drive separado, ele sempre faz o vídeo focando a realidade da maioria, que no caso não tem um setup assim.

4 curtidas

Veja isso, eu desinstalei o kde neon, fiz o mesmo processo só que o local do gerenciador de inicialização foi posto no SSD onde estava o grub já instalado. Instalei o Lingmo OS, na inicialização o grub não encontrou o novo sistema.


Entrei no linux mint, executei o comando “sudo update-grub2” e o grub não encontrou o novo sistema.

Decidi então reiniciar o PC e redirecionar o boot manualmente por cada SSD, nenhum dos dois SSD tinha o novo sistema, daí fiz o boot pelo os HDs e só no HD de 320GB apareceu o novo sistema já com o novo grub instalado.

Ele instalou o grub HD de 320GB e não no SSD que já tinha o grub com todos os meus outros sistemas.

Nota: Tem coisas na informática que não se explica. Tenho o win11 mas o grub enxerga como 10

1 curtida

Instalei o Lingmo OS pois ele é baseado no debian, ele vai se dá bem o peppermintOS ambos são a base do debian.

Seria interessante vc testar se o grub do LingmoOS acha todos os outros sistemas, daí poderia deixar esse HD como padrão e entrar sempre por ele.

Em todo caso, eu nunca deixo de recomendar que cada instalação esteja separada em seu drive, principalmente se for windows. Agora quando são 2 linux até que vai.

Dependendo da placa mãe, vc pode deixar sem boot padrão e aí sempre que o PC ligar vc escolhe o drive com o sistema desejado, é o que eu faço.

1 curtida

Sim, sim, ele fez isso.
Mas a minha alegria durou pouco tempo quando vi o lingmo OS dando falhas, travamentos na área de trabalho e aplicativos parando de funcionar e crasher total do sistema. Sem problemas, hoje vou testar o deepin.

Outra coisa rapaz, testar o sistema na LiveUSB, VM é uma coisa mas no PC físico é outra. O tio Dio já tinha alertado sobre o lingmo OS já que ele tá em versão beta então provavelmente erros podem ser notados como de praxe.

1 curtida

Só para titulo de curiosidade:
Seu grub enxerga como Win10 porque a compilação do Windows 11 é a versão 10. Isso foi feito pensando em compatibilidade, para que muitos programas não deixassem de funcionar pensando que o Windows 11 é um S.O sem suporte e as software houses teriam que recompilar todos seus programas antigos para que funcionassem também no Windows 11.
image

6 curtidas

Mais um tópico resolvido, agradeço o “help” pelo menos futuramente quando o usuário básico for instalar o linux ele vai saber como fazer.

Bom dia,
É que eu tenho o win11 e a galera pode achar estranho dizendo “se ele tem o win11 porque lá tá win10” entendeu?

Isso aí resolve usando o “grub customizer” e renomear o 10 por 11 só que eu quero evitar a fadiga kkkkkk
Uma boa semana pra você rapaz!!!

Olá @Rimana21

Nosso mundo é formado por 10³¹ zilhões de “falhas de comunicação”.

É o que torna tudo mais simples, fácil, rápido – e evitamos confundir o iniciante com mil detalhes desanimadores:

Mas quando surge um problema específico, precisamos encontrar uma visão mais “correta”, mais exata, para tentar entender e resolver.

Por exemplo: – Procurei “parti” (partição, particionamento), nesse tópico, e só aparece 1 vez – quando você diz que deletou a partição do LingmoOS. – Seria terrível, se você apagasse o SSD inteiro, mas felizmente você está atento para não cometer esse erro.

(a outra ocorrência de “parti” é o botão “Compartilhar”, no rodapé do tópico):

Mas, sempre que você tenta pensar no “Grub”, em “boot”, ou “bootloader”, você fala “SSD” – ou “HDD”, como último recurso. – Em nenhum momento você associou “bootloader” a uma “partição”:

Esse erro não é seu. – Ele facilitou sua vida, até aqui. – Agora, você tem um motivo para se livrar dele, e se aprofundar mais um pouco, caso tenha interesse.

Vou mostrar alguns exemplos de 2020, quando migrei do meu antigo hardware “BIOS (Legacy) + MBR” – para um novo hardware “UEFI + GPT”. – Isso era novidade para mim, então tive o cuidado de fazer tudo do modo mais simples (sem partições /home ou Swap), dar só 1 passo de cada vez, e registrar todos os detalhes:

Escolhi uma partição para instalar o PCLinuxOS, ponto-de-montagem “/”, sistema de arquivos ext4 etc.

Em hardware UEFI + GPT, imagino que todo instalador “exige” definir uma “partição EFI”, para seguir adiante. – Pelo menos, é o que tenho visto nesses 4 anos.

  • Eu não tinha Windows. – o PC estava “em branco”, componentes inalterados, de fábrica: – UEFI Bios não-mexida, SSD não-mexido etc.
  • Criei manualmente a tabela GPT do SSD – e as partições para várias distros Linux
  • Criei manualmente a partição EFI, sistema de arquivos Fat32 (vfat), apliquei as flags boot, esp
  • Pode-se ter só 1 partição EFI – mesmo que instale várias distros em vários SSDs, HDDs etc.
  • Pode-se ter 2+ partições EFI
  • Parece que é bom ter uma partição EFI para as distros Linux, separada da EFI do Windows – mas não sei, pois continuo sem Windows até hoje
  • Ainda não sei nada sobre o que acontece quando temos várias EFI, como elas se comportam, como lidar com essa multiplicidade – porque ainda não experimentei – e não adianta falar do que leio, escuto etc., enquanto eu mesmo não tiver testado
  • Quero ter pelo menos uma 2ª partição EFI (no meu 2º SSD, por segurança!), como backup da 1ª, mas ainda não experimentei, para ver o que acontece

O instalador do PCLinuxOS propôs montá-la como sub-pasta /boot/EFI – ou seja, dentro da pasta “/boot”, na partição escolhida para “/”:

Logo depois, o “Draklive Install” apresentou mais algumas opções: – Eu escolhi o “bootloader Grub2 com Menu gráfico”. – O “dispositivo de Boot” é a “Partição EFI” (não o SSD onde ela está!). Neste caso, eu sei que era a partição sda1 (dentro do SSD indicado como sda):

  • Note que o instalador do PCLinuxOS chama de “bootloader” o “Grub2 com Menu gráfico”. – Para evitar confusão, eu prefiro reservar a palavra “bootloader” para as entradas existentes na partição EFI – e que são detectadas pelo “UEFI Bios”, ao ligar a energia do PC.

Antes de mostrar outros exemplos, vale observar que “usamos” muitos “erros de linguagem”, todos os dias, quando pensamos:

  • Onde está o Grub? – Está em vários lugares! – Aliás, existem várias coisas diferentes, que chamamos por 1 nome genérico, de “grub”.
  • Onde está o “boot”? – Ora… O que é “o boot”, exatamente…??
  • Onde está o bootloader? – Entendo que está na partição EFI (ou em várias partições EFI)

Sigamos com os exemplos concretos:

No instalador do openSUSE (um módulo do YaST2), as coisas são mil vezes mais detalhadas, permitindo 1 quintilhão de micro-opções.-- Eu já conhecia, pois já tinha instalado 3 anos antes, mas mesmo assim gastei um tempão batendo cabeça para um lado e para o outro, até que cheguei a este ponto: – A definição final de usar a partição EFI (a mesma) e uma partição-raiz com sistema de arquivos BtrFS:

O resumo do particionamento: – Formatar a partição-raiz “/” (de ext4 para BtrFS); e não formatar a partição EFI:

  • É normal os instaladores não proporem a formatação da partição EFI – pois é comum ela conter o “bootloader” de outras distros; e a formatação seria um pequeno desastre. – Mas procuro sempre me certificar de que não vai mesmo formatar.
  • Quanto à partição-raiz, é normal os instaladores marcarem para formatar – para garantir que não tenha lixo de alguma instalação anterior. – Neste caso, estava vazia, mas eu ainda precisava mudá-la para BtrFS.

Em qualquer instalador, é preciso ter muito cuidado, antes de clicar em “Toca a Bagaça!” – Esta é a última oportunidade para revisar todas as opções feitas até ali. – Depois do Ok, não tem mais volta:

Antes que eu me esqueça:

  • Eu sempre crio as partições, antes de abrir o Instalador. – Prefiro fazer isso com GParted ou KDE Partition Manager, que já sei como funcionam, e sei o que posso esperar deles. – Cada distro tem um Instalador diferente, e eu nunca me sinto seguro do quê, exatamente, cada instalador pode achar que deve fazer.
  • Já perdi um KDE Neon totalmente configurado e funcional, só porque cometi 1 errinho no Instalador / Particionador do Mageia.
  • Em qualquer Instalador, sempre escolho a opção de “Particionamento Manual”, ou “Particionamento Avançado”, ou “Personalizado” (ou algo assim), para que eu possa escolher as partições que planejei usar, e ter a certeza de que ele não irá inventar nenhuma gracinha.
  • Nunca uso opções de particionamento “Automático”, “Guiado”, “Usar o disco todo”, “Instalar ao lado”, “Instalar em cima”, “Instalar embaixo” etc.
  • Tudo bem, um “iniciante” talvez não queira, talvez ache que “não consegue”, ou tenha preguiça etc. – Mas logo que tenha instalado e experimentado 2 ou 3 distros, meu conselho é: – Pare um pouco, e dedique um tempo para particionar.
  • Por sorte, comprei muitas “revistinhas sobre Linux”, li tudo que consegui entender, e reinstalei meu antigo Windows (reinstalar Windows era comum, na época), já deixando o espaço para as partições “/”, “/home” e Swap do Linux.

No Instalador do Fedora – “Particionamento Personalizado” – para escolher manualmente as partições que eu já tinha criado:

O Instalador do Fedora agrupou as partições existentes, conforme pertencessem ao openSUSE, ao PCLinuxOS ou ao KDE Neon (instalados antes) – ou num grupo “Desconhecido” (ainda não usadas). – Isso facilita, caso você queira substituir uma das distros anteriores

  • Note que vários “subvolumes” (BtrFS) do openSUSE ficaram no grupo “Desconhecido”. – Isso é uma das coisas que me desanimam de ter mais do que 1 distro em partição BtrFS: – É muito chato tentar entender essa bagaça, olhando “de fora” (a partir de outra distro):

A partição EFI estava nos 3 grupos (repetida). – Selecionei, atribuí o ponto de montagem – e me certifiquei de que não seria formatada:

O alerta do Instalador do Fedora avisa que sua partição-raiz será formatada. – Não fala nada da partição EFI. – Voltei à tela anterior, só para ter certeza de que não seria formatada.

É preciso ter tanto cuidado?

  • Se eu tiver qualquer dúvida – e a tela seguinte do Instalador não me der um feedback das opções que fiz – eu volto para me certificar. – É rápido, e não custa nada.

Aqui começam minhas incertezas:

  • KDE Neon usa o instalador Calamares – aquele cuja “barra de progresso” está sempre errada.
  • Debian usava um instalador próprio, antigão, só dele. – Acho que mudou para o Calamares.
  • Manjaro, acho que também usa o Calamares.
  • Mint, Kubuntu? – Faz tempo que não instalo. – Tenho só uma vaga lembrança de quando usavam Ubiquity – se é que não estou confundindo.

Em um artigo de 2015, encontrei esse registro:

O Ubuntu (e o Mint) encontrarão e usarão uma partição de inicialização EFI existente, mas não informarão nem mostrarão nada sobre isso, e ainda exibirão a caixa de diálogo antiga que diz que o GRUB será instalado no /dev/sda. Bem, acho que isso é tecnicamente correto, ele será instalado em algum lugar desse disco, mas dar uma dica de que realmente vai para a partição de inicialização EFI, e não para o antigo local do MBR, geraria menos incerteza e preocupação durante a instalação.

Transcrevo essa citação, porque ao examinar as capturas de tela da instalação do KDE Neon, em 2020, não consegui ter certeza do quê eu tinha feito.

Na área principal da janela do Calamares, escolhi a partição-raiz – e recebi o feedback de “/” – mas um botão lá embaixo indicava que o bootloader seria instalado em “sda”:

Cliquei no botão lá embaixo, alterei para “sda1” – minha partição EFI – e não recebi nenhum feedback na janela principal:

Para tirar essa dúvida, simulei uma nova instalação, só para examinar aquele comportamento.

Pela janela principal >> Selecionar partição sda1 >> Clicar em “Change” (Editar) >> Usar como… – consegui definir sda1 como “EFI System Partition” – porém os campos “Formatar” e “Ponto de montagem” permaneciam inabilitados (grayed), e vazios. – Não era possível editar essas opções:

Ótimo, não poder formatar! – Crianças não podem meter o dedo na tomada de eletricidade.

Portanto, o ponto-de-montagem só podia ser alterado pelo botão lá embaixo, fora da janela principal. – Talvez por isso, a janela principal não dava nenhum feedback, depois de fazer essa alteração.

Me pareceu uma gambiarra improvisada – em cima de um “botão de seleção” originalmente planejado para escolher o MBR de um “disco” (embora já permitisse escolher uma partição dentro dele) – em vez de tratar a partição EFI como uma partição como as outras, na janela principal do Instalador / seletor de partições.

Voltei a instalar o KDE Neon no final de 2023 e no início de 2024, para experimentar o Plasma 6, sem mexer naquela instalação de 2020.

Em Novembro 2023, as 3 opções de Particionamento vieram desmarcadas. – O usuário precisava tomar a iniciativa de escolher o tipo de Instalação, senão, não pode avançar. – Acho bacana. Ninguém é induzido a aceitar uma escolha-padrão ao clicar “Next” sem pensar:

Em Fevereiro 2024 eram 4 opções – talvez porque agora era um “lançamento” – e não mais um Beta qualquer:

Sumiu o “botão-seletor” lá embaixo. – Agora, você escolhe a partição EFI, como outra qualquer, depois clica em Editar – e pode escolher o ponto-de-montagem /boot/efi na lista oferecida:

  • Note que o Instalador propôs “Manter” (não formatar) – padrão normal de segurança – e informa que a partição tem rótulo “EFI” e flag boot.

Você clica em “Ok”, fecha a sub-janela – e na janela principal recebe o feedback de que a partição EFI foi escolhida, ponto-de-montagem etc. – Agora, o botão “Next” está habilitado para prosseguir na instalação:

Onde está o Grub?

Os arquivos mais “utilizados” do Grub estão em /boot/grub2 (ou /boot/grub) – e em /etc/default. – No caso do Mageia, que usei como meu “Menu de Inicialização” até o final de 2019:

   |-boot
      |---grub2
             custom.cfg
             grub.cfg
             grubenv
         |-----fonts
         |-----i386-pc
         |-----locale
         |-----themes
            |-------dolphy
            |-------maggy
            |-------openSUSE
                theme.txt
   |-etc
      |---default
             grub
      |---grub.d
             00_header
             01_users
             06_grub-customizer_menu_color_helper
             10_linux
             20_linux_xen
             20_ppc_terminfo
             30_os-prober
             40_custom
             41_custom
             README

Digo “mais utilizados”, no sentido de que chegamos a mexer neles em certas circunstâncias:

  • /etc/grub2/grub.cfg – É o “código” da “tela do Grub”, com as distros disponíveis e as opções de Kernel de cada uma. – É atualizado automaticamente, quando a própria distro recebe nova versão de Kernel. – Precisa ser atualizado manualmente (por comando), quando sabemos que uma das outras distros recebeu nova versão de Kernel.

  • /boot/grub2/themes/TEMA/theme.txt – É a configuração do “tema de Grub” – fontes, cores, imagem de fundo, espaçamentos etc.

  • /etc/default/grub – É a configuração de como queremos que o Grub se comporte. – Por exemplo, o tempo de espera, a separação das “Opções Avançadas” etc.

Onde está o “bootloader”?

Tecnicamente, o Grub é um “bootloader” – mas prefiro chamar de “gerenciador de inicialização” (boot manager) – para distinguir dos “bootloaders” existentes na partição EFI:

$ tree /boot/efi
/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

20 directories, 49 files

Esses “bootloaders” existentes na partição EFI permitem escolher “qual Grub” vamos utilizar. – Atualmente eu prefiro usar o Grub do openSUSE, por ser o único que consegue carregar qualquer uma das minhas outras distros.

  • O Grub de outras distros não consegue carregar o openSUSE – ou não consegue carregar o Arch – ou não consegue carregar nenhum dos dois.

Em vários desses “bootloaders” aparecem arquivos grub.cfg – mas são apenas “indicadores” da verdadeira localização dos grub.cfg de cada distro.

Selecionar Boot “por disco”?

Dar boot pelo 1º SSD, pelo 2º SSD, pelo HDD? – No antigo hardware BIOS (Legacy) + MBR, sim! – a BIOS (Legacy) me permitia escolher a “prioridade de boot” entre a MBR do 1º HDD, a MBR do 2º HDD, ou a do 3º HDD, ou a MBR do 4º disco:

Na UEFI Bios, o que sei, é que posso escolher 1 “bootloader” (do openSUSE, do Mageia, ou outro), que no meu caso estão todos na mesma partição EFI:

Posso arrastar esses “bootloaders” para cima ou para baixo, para priorizar o que eu preferir. – Coloquei o do openSUSE no topo; e o do Mageia logo abaixo.

Também posso teclar F8 para acessar o Boot Menu completo, pois tenho vários outros, que não aparecem na página inicial do UEFI Bios Setup:

Nesse Menu de Boot (F8), posso simplesmente escolher um “bootloader” – digamos, de um Pendrive de 8 GB – e teclar Enter, para usá-lo “só desta vez” (sem alterar a configuração).

Algumas distros, quando instalam nova versão do Grub, têm a mania de se apossar da prioridade de boot. – Em vez de reiniciar, apertar DEL, entrar na UEFI Bios Setup, arrastar de novo openSUSE para o topo, F10 para Salvar e sair etc., atualmente prefiro resolver logo pelo efibootmgr:

KDE Neon (6) - 2024-09-22 12:26:51

$ efibootmgr
BootCurrent: 000B
Timeout: 1 seconds
BootOrder: 000B,0000,0003,000A,0002,0005,0006,0007,0008,0004,000C,0001
Boot0000* opensuse
Boot0001* debian
Boot0002* Fedora
Boot0003* mageia
Boot0004* pclinuxos
Boot0005* arch_grub
Boot0006* arch_grub2
Boot0007* MX Linux
Boot0008* Redcore
Boot000A* slackware-14.2+
Boot000B* neon
Boot000C* debian

$ sudo efibootmgr -o 0000,0003,000A,0002,0005,0006,0007,0008,0004,000C,0001,B
[sudo] password for flavio:
BootCurrent: 000B
Timeout: 1 seconds
BootOrder: 0000,0003,000A,0002,0005,0006,0007,0008,0004,000C,0001,000B
Boot0000* opensuse
Boot0001* debian
Boot0002* Fedora
Boot0003* mageia
Boot0004* pclinuxos
Boot0005* arch_grub
Boot0006* arch_grub2
Boot0007* MX Linux
Boot0008* Redcore
Boot000A* slackware-14.2+
Boot000B* neon
Boot000C* debian

Enfim… Não sei se a UEFI Bios me daria opção de priorizar o boot por um SSD, ou por outro SSD, se eu tivesse 2+ partições EFI (iguais ou diferentes, no mesmo SSD ou em outro SSD).

Não posso descartar essa possibilidade, porque ainda não testei na prática. – Apenas, me parece que a UEFI Bios lida com “bootloaders” – e não com SSDs, HDDs etc. (como fazia a BIOS (Legacy).

5 curtidas

@Rimana21 desmarca meu comentário e marca esse aqui! kkkkk Parabéns pela explicação @frc_kde ! :clap:

Tocando no assunto, vejam só, cai nesse golpe hoje, fui instalar o debian e passei batido pelo grub kkkkkk

3 curtidas

Boa noite rapaz, o homem das 12 distros. Sim eu tenho interesse e muito pois o linux para mim é um jogo, quanto mais difícil mas gostoso e divertido é. Você tem muito material explicativo interessante. Desinstalei o kde neon plasma 6 porque depois de uns 4 minutos de inatividade no sistema sem mexer o ícone do configuração de sistema para de funcionar forçando o usuário a fazer logoff ou reiniciar.
Aqui eu uso o LM e Pmos, O linux mint sempre resolve as minhas besteiras com o terminal pois o peppermintOS é travado no “sudo update-grub2” kkkkk
Quando eu faço uma M eu peço ajuda no mint usando o terminal kkkkk
Eu só queria instalar mais uma distro em minha máquina baseada em debian para fazer campanha com o meu peppermint, essa distro eu não troco ela por nada, me casei com ela, ela faz coisas que até linus torvalds duvida.

Uma pergunta rapaz, uma única pergunta que faço a você.
Eu tenho 3 sistemas então eu chamo de Tri-Boot ou Trial-boot, você tem 12 então como você chama o boot ? Twelve-boot?

1 curtida

E veja eu, hoje fui olhar o win11 parado a muitos meses, fui atualizar e desligar e cadê ? o win11 não queria mais desligar. Eu disse “ae né” abri o terminal e digitei “shutdown /s” o sistema desligou sem fazer birra.

Bah… Tri-legal…!

Já que o assunto lhe interessou, fiz um EDIT, com mais um pouco de diversão.

Estamos estudando “Dodeca-boot”, em greglish.

Este tópico foi fechado automaticamente 3 dias depois da última resposta. Novas respostas não são mais permitidas.