Placa-mãe em modo BIOS Legacy trava teclado no grub (mas UEFI funciona normal)

[Shakmatton]

Olá pessoal. Não sabia onde exatamente criar o tópico, pois não tinha certeza se o problema é de software, firmware ou hardware.

O fato é que, de uns tempos pra cá, não tenho conseguido mais usar o menu do meu grub (tenho um Windows 7 + 3 outros Linux nele).

 

Sempre os usei normalmente aqui, em modo BIOS MBR Legacy, sem problemas.

Mas agora percebi que o travamento ocorre quando seleciono um OS da lista de sistemas instalados.

 

No caso, o teclado pára de funcionar durante a tela do grub (funciona normal antes e depois dele, mas não durante). Também percebi que o problema ocorre com um pendrive inicializável. Tanto apertando F12 para escolher o dispositivo de boot, como usando Ventoy instalado no USB (que, no caso, também te dá uma tela de opções de sistemas e demais coisas por lá também).

 

A minha placa-mãe é da Gigabyte (GA-F2A55M-HD2), bem antiga, de 2014. Aliás, todo o meu setup é dessa época (à exceção da fonte de alimentação, que foi trocada por uma nova recentemente).

Por ser antiga, a placa é DualBIOS, admitindo tanto o modo UEFI, o modo UEFI CSM e o modo MBR Legacy.

 

==============================

 

Não sei se essas informações são relevantes, mas tenho todos os meus sistemas instalados em modo MBR Legacy. Tenho uma partição separada só para Dados, e outras para OSes e Swap.

Sobre os OSes, uso o Windows 7 totalmente offline, exclusivamente como videogame. Os demais Linux são o BigLinux, o Linux Mint e o Elive OS (que uso com parcimônia).

 

Mas, como sempre fui um distrohopper, já instalei muitos outros sistemas Linux (nunca precisei mexer no Windows, embora ultimamente ele também estivesse fazendo verificações de espaço em disco sempre que inicializa, a não ser que eu intervisse apertando ESC). Um deles foi um que testei há muito tempo (o Antergos Linux, uma finada distro derivada do Arch), e que por algum motivo, permanece aparecendo quando aperto F12 para entrar na tela de escolha de boot. Será que isso teria a ver com o problema?

 

==============================

 

Enfim... fiquei pensando aqui se haveria a chance de que a "porção BIOS Legacy" da minha placa-mãe tivesse morrido, só sobrando a "parte UEFI "da placa-mãe...

 

 

Tentei mexer em todas as configurações possíveis recomendadas nos diversos fórums de informática pela web (Secure Boot, Fast Boot, CSM, etc), mas nada resolve.

O problema permanece: aguardo os 5 segundos de boot e consigo usar a primeira opção de sistemas do grub (o BigLinux no caso).

Mas como o teclado não funciona durante esses segundos, não tenho mais acesso ao meu Win 7 e demais OS Linux...

 

Então é isso. Vou deixar aqui algumas imagens de apoio, caso ajudem (quais outras informações extras eu poderia colocar aqui que poderiam ajudar na questão?).

 

(O mais louco é que, muito, muuuito raramente, em condições específicas, eu consigo de fato usar o teclado e escolher o SO do meu grub.

Por exemplo, quando atualizei o meu BigLinux, reiniciei e conseguir escolher outros sistema... mas quando desliguei a máquina da energia e liguei novamente algumas horas depois, o problema permaneceu. Creio que uma situação similar ocorreu após testar uma ISO live de outro Linux, pois quando reiniciei e tirei o pendrive, pude acessar o teclado... mas novamente, o problema voltou quando reiniciei a máquina).

 

Bom, é isso. Alguém teria alguma luz sobre a questão?

(Por favor, não me peçam para converter o disco para GPT/UEFI. Pelo que pesquisei nos últimos dias, a experiência de instalar o Win 7 no HD (não uso SSD) em UEFI é totalmente infernal...

 

Muito obrigado pelo apoio, mais uma vez!

Shak.

 

 

 

 

 

 

 

 

[Marcos FRM]

BIOS UEFI está no modo híbrido, suportando ambos os tipos de sistemas: CSM e UEFI. O "antergos_grub" é uma variável de inicialização UEFI, que foi gravada com a mídia de instalação em questão tendo sido iniciada nesse modo. Você remove-a com:

 

efibootmgr
efibootmgr -b X -B

 

Tem que substituir "X" do segundo comando pelo número retornado no primeiro em BootXXX relativo à linha que tiver "antergos_grub". Ambos os comandos apenas funcionarão com um Linux iniciado em UEFI. Não sei se tem algum aí. Ao usar mídia removível, no menu de inicialização via F12, suas entradas são prefixadas com "UEFI:" para diferenciar.

 

Já testou "Boot Mode Selection" em "Legacy Only" e "Storage Boot Option Control" em "Legacy Only"? Isso mais ou menos desativa as funções UEFI.

[Shakmatton]

@Marcos FRM Oi Marcos!

Muito obrigado pelo apoio!

 

Olha, no caso, não tenho nenhum Linux iniciado em UEFI. Porém, não tinha pensado na ideia de usar um Linux em pendrive, em modo Live, a partir da entrada UEFI... vou tentar aqui e depois retorno com a resposta...

 

Esse comando do efibootmgr me foi sugerido anteriormente em outro fórum, mas até então eu não tinha percebido a possibilidade de usá-lo em um pendrive em modo Live. Fico pensando se a remoção do "antergos_grub" resolveria o problema do teclado...

 

Eu já tentei mudar (e combinar) várias vezes as opções da placa-mãe que tinham Legacy, mas nada adiantou.

Bom, vou tentar essa sua combinação, e, mais uma vez, retorno em breve com o resultado.

 

 

 

 

 

[Marcos FRM]

Hmmm, geralmente BIOS UEFI descartam variáveis UEFI cujo binário não exista. Para essa variável aparecer, existe uma boa possibilidade de você ter uma partição EFI no disco. Note que partição EFI pode existir no particionamento MBR também; o identificador é 0xEF.

[Shakmatton]

44 minutos atrás, Marcos FRM disse:

Hmmm, geralmente BIOS UEFI descartam variáveis UEFI cujo binário não exista. Para essa variável aparecer, existe uma boa possibilidade de você ter uma partição EFI no disco. Note que partição EFI pode existir no particionamento MBR também; o identificador é 0xEF.

Olha, abri o terminal do Linux em que estou agora, e com o comando fdisk -l pude ver as partições aqui. Em nenhuma delas está escrito a palavra EFI (exceto a que aparece na ISO Linux que acabei de gravar aqui no pendrive) ou o código identificador que você mencionou.

 

Aqui vai um print da tela:

 

 

 

Não sei se são úteis, mas adiciono aqui mais algumas observações extras ao tópico:

 

Observando a imagem, porém, me veio uma coisa aqui à mente: o pendrive com a imagem ISO recém gravada aparece com o rótulo DOS, mas a imagem tem no dispositivo /dev/sdb2 do pendrive uma partição do tipo EFI. Será que estaria havendo um conflito entre o rótulo e o tipo de sistema a se instalar (no caso, aquele EFI da imagem lá)? Eu pensava que o Linux fosse mais flexível e adaptável à essas questões, enquanto o Windows seria algo mais estrito nesse quesito.

 

Sobre gravadores de imagem de USB: geralmente uso Popsicle ou Ventoy como gravadores padrão, mas recentemente vi que existe um outro chamado Rufus, que te possibilita escolher logo de início se o sistema será GPT ou MBR. Será que isso teria alguma influência na questão também?

 

"Partições lógicas fora da ordem do disco": me pergunto se várias instalações (e remoções) de OS ao longo dos anos possam ter criado/deixado algum problema ou vácuo que poderia eventualmente resultar nessa situação também.

 

Reparei que em nenhum dos OS Linux instalados existe aquela pasta /boot/EFI. Já no Windows, pude acessar, via Linux, a pasta C:\Windows\Panther. Ali dentro, no arquivo setupact.log, há uma linha chamada "Callback_BootEnvironmentDetect: Detected boot environment: BIOS". Então, aparentemente, não há sinal de EFI em lugar algum... (por isso mesmo que desconfiei do antergos_grub... me pergunto se esse antigo sistema chegou a ser instalado em modo EFI na época)...

 

Sobre a placa-mãe, uma ideia que tive foi a de atualizar a BIOS. Há uma versão beta disponível no site da fabricante, mas como vejo muita gente desencorajando o uso de versões beta sob o risco de "bricar" a placa, fiquei só com a última versão estável. Por outro lado, me pergunto se seria interessante reinstalar essa mesma versão estável da BIOS, caso nada mais dê certo (a outra opção seria migrar para o Windows 8, mais próxima do Win 7, e que (dizem) não exigiria tanto do setup de uma máquina antiga como essa)...

20 horas atrás, Marcos FRM disse:

Já testou "Boot Mode Selection" em "Legacy Only" e "Storage Boot Option Control" em "Legacy Only"? Isso mais ou menos desativa as funções UEFI.

Esqueci de responder: tentei isso e também não deu certo...

20 horas atrás, Marcos FRM disse:

BIOS UEFI está no modo híbrido, suportando ambos os tipos de sistemas: CSM e UEFI. O "antergos_grub" é uma variável de inicialização UEFI, que foi gravada com a mídia de instalação em questão tendo sido iniciada nesse modo. Você remove-a com:

 

efibootmgr
efibootmgr -b X -B

 

Tem que substituir "X" do segundo comando pelo número retornado no primeiro em BootXXX relativo à linha que tiver "antergos_grub". Ambos os comandos apenas funcionarão com um Linux iniciado em UEFI. Não sei se tem algum aí. Ao usar mídia removível, no menu de inicialização via F12, suas entradas são prefixadas com "UEFI:" para diferenciar.

 

Já testou "Boot Mode Selection" em "Legacy Only" e "Storage Boot Option Control" em "Legacy Only"? Isso mais ou menos desativa as funções UEFI.

 

Olha, acabei de testar um Linux em live mode aqui. No terminal, digitei efibootmgr, e veio um resultado que me fez ter a sensação de que o problema poderia ser resolvido mudando alguns parâmetros aqui. Segue a imagem (com alguns apontamentos meus):

 

 

Separei por cores pra facilitar a leitura. A sigla MBR aparece no boot0000 (antergos_grub), mas, como você havia desconfiado, há um arquivo grubx64.efi coexistindo na máquina com os demais parâmetros/entradas dela.

 

Fiquei meio inseguro de tentar mexer ali. Você acha que haveria algum problema, dado que as entradas parecem um pouco bagunçadas em algum grau? Quer dizer, a entrada 0005 não está listada no "BootOrder" ali em cima. Além disso, seria normal as entradas em verde e as em rosa aparecerem de maneira duplicada/redundante (especialmente as entradas 0004 e 0006, que tratam do mesmo HD, mas com nomes distintos)?

 

Em suma, considerando a imagem acima, seria seguro remover o antergos_grub?

Ou haveria o risco de que, com essa remoção, a MBR também fosse removida e perdida para sempre também?

 

 

 

 

[Marcos FRM]

O tipo de partição é a coluna "Id" da saída do fdisk: apareceria "ef" ali, sem o prefixo "0x". Então, não. Não tem partição EFI em /dev/sda. O pendrive (/dev/sdb) ter uma partição EFI não importa. Programas como o Ventoy fazem uma bruxaria danada... o Rufus, em algumas circunstâncias, cria uma partição EFI no pendrive.

 

1 hora atrás, Shakmatton disse:

Em suma, considerando a imagem acima, seria seguro remover o antergos_grub?

 

Sim. Sem partição EFI em /dev/sda, essa entrada é inútil. Ainda mais a árvore de diretórios "EFI/antergos_grub/" não existindo no sistema de arquivos de nenhuma partição -- repetindo, teria que ser numa partição do tipo "ef".

 

"antergos_grub" é a entrada 0 (zero). Portanto: efibootmgr -b 0 -B

 

As demais entradas são geradas automaticamente pelo BIOS e não devem ser removidas, inclusive a 7, do pendrive usado para iniciar.

 

Curioso que "antergos_grub" aponta para /dev/sda mesmo; veja a assinatura de disco (0x1835), que o fdisk chama de "identificador de disco".

 

1 hora atrás, Shakmatton disse:

"Partições lógicas fora da ordem do disco"

 

Não causa problema. Se não me engano, é indolor corrigir. As ferramentas *fdisk possuem recurso para isso (o cfdisk é mais amigável).

 

1 hora atrás, Shakmatton disse:

Ou haveria o risco de que, com essa remoção, a MBR também fosse removida e perdida para sempre também?

 

Não mexe no disco.

[Shakmatton]

Ok, vou fazer um backup aqui e vou seguir sua recomendação então.

Fiquei com uma boa sensação de que o problema do teclado pode ser resolvido exatamente aqui, neste ponto.

 

36 minutos atrás, Marcos FRM disse:

Programas como o Ventoy fazem uma bruxaria danada...

Isso significa que não seria recomendável seguir usando o Ventoy de agora em diante?

(O único programa do tipo que vi muita gente falando mal sobre foi o Balena Etcher, que diziam que havia o risco de até "bricar" o pendrive...)

2 horas atrás, Shakmatton disse:

Olha, acabei de testar um Linux em live mode aqui. No terminal, digitei efibootmgr, e veio um resultado que me fez ter a sensação de que o problema poderia ser resolvido mudando alguns parâmetros aqui. Segue a imagem (com alguns apontamentos meus):

Esqueci completamente de grifar a parte que mostra "Disco /dev/zram0: 3,03 GB"...

Você acha que isso poderia ser normal, ou poderia ter a ver com o problema também?

[Marcos FRM]

Não gosto do Ventoy pois ele quebra Secure Boot em UEFI: a mídia deixa de ser compatível, a menos que adicione-se um certificado (ou hash nas versões recentes, parece: link1, link2) no MOK -- o que eu nunca farei. Para mim, o melhor programa para a tarefa é o Rufus, mas tem um escopo diferente: apenas uma mídia por dispositivo.

 

"Bricar" é improvável. Não tem nada no protocolo USB Mass Storage que permita a um aplicativo fazer um estrago assim.

 

15 minutos atrás, Shakmatton disse:

Esqueci completamente de grifar a parte que mostra "Disco /dev/zram0: 3,03 GB"...

Você acha que isso poderia ser normal, ou poderia ter a ver com o problema também?

 

Não tem ligação. Usa-se para swap:

 

https://docs.kernel.org/admin-guide/blockdev/zram.html

[Shakmatton]

48 minutos atrás, Marcos FRM disse:

Curioso que "antergos_grub" aponta para /dev/sda mesmo; veja a assinatura de disco (0x1835), que o fdisk chama de "identificador de disco".

Essa parte técnica não deve ser difícil de pesquisar na web com calma depois, mas só pra saber:

Se eu entendi bem, onde o print mostra: antergos_grub HD(9, MBR, 0x1835, 0x0, 0x0) .....

 

Então, tudo que está entre parêntesis são apontadores para partições ou para a MBR (imagino que o número 9 seria um outro id de partição, não?), seria isso? Pergunto porque, se o antergos_grub for removido dessa lista, qual outro dispositivo assumiria/apontaria para o endereço da MBR?

 

Ou isso seria automaticamente gerido pelo "BootOrder"?

Nesse caso, não haveria com o que se preocupar, certo?

[Marcos FRM]

Isso só teria importância caso existisse uma partição EFI no disco. Se você iniciar através da opção "antergos_grub" no menu F12 acontece o quê?

[Shakmatton]

6 minutos atrás, Marcos FRM disse:

Não gosto do Ventoy pois ele quebra Secure Boot em UEFI: a mídia deixa de ser compatível, a menos que adicione-se um certificado (ou hash nas versões recentes, parece: link1, link2) no MOK -- o que eu nunca farei. Para mim, o melhor programa para a tarefa é o Rufus, mas tem um escopo diferente: apenas uma mídia por dispositivo.

Entendo. Na época que conheci o Ventoy, o que me chamou a atenção foi a capacidade de colocar múltiplas mídias em um pendrive grande (imaginei que isso poderia "economizar" um pouco o desgaste natural do pendrive, ao desacalerar o ciclo de formata/instala).

 

Mas no caso da minha máquina (com sistemas instalados 100% não-UEFI, ou seja, em MBR Legacy), isso não seria uma preocupação, não?

3 minutos atrás, Marcos FRM disse:

Isso só teria importância caso existisse uma partição EFI no disco. Se você iniciar através da opção "antergos_grub" no menu F12 acontece o quê?

Nesse caso, o boot ocorre normalmente. O problema do teclado travado ocorre, e eu tenho que esperar a contagem regressiva acabar para que o grub escolhe e entre na primeira opção de sistema listado nele (no caso, este Linux em que estou escrevendo essa mensagem agora).

[Marcos FRM]

Acredito que o BIOS tente achar o tal binário, não ache, desista e passe para a próxima entrada, que possivelmente seja o bootloader não-UEFI do MBR do disco. Remova a tal entrada, afinal o binário por ela referenciado não existe.

 

5 minutos atrás, Shakmatton disse:

Mas no caso da minha máquina (com sistemas instalados 100% não-UEFI, ou seja, em MBR Legacy), isso não seria uma preocupação, não?

 

Acho que não. Não conheço o Ventoy em detalhes.

[Shakmatton]

1 hora atrás, Marcos FRM disse:

Não causa problema. Se não me engano, é indolor corrigir. As ferramentas *fdisk possuem recurso para isso (o cfdisk é mais amigável).

Ok, localizei o programa e vou dar uma verificada com calma nele em breve.

 

Uma coisa que esqueci de comentar no início do tópico é que eu sempre usei uma ferramenta do Linux chamada "Grub-customizer".

Embora sempre a tenha usado com parcimônia, fico pensando se isso também teve algum impacto no problema/questão atual.

 

Também esqueci de mencionar outra coisa:

antes da manifestação do problema do teclado travado, era possível selecionar tranquilamente o Windows 7 na lista do grub.

 

Porém, já há algum tempo também, o Windows 7 mostrava uma tela em que ele ficava detectando e verificando os volumes instalados (isso demorava algum tempo, e lembro que mostrava uma porcentagem, como "56% da verificação concluída", por exemplo, e seguia assim). Isso acontecia em toda a inicialização dele, mas era fácil de interromper a verificação pressionando ESC. E aí eu conseguia começar a usar o Windows normal também. Mas fora esse pequeno incômodo, não havia nenhum sinal de problema mais sério...

1 hora atrás, Marcos FRM disse:

Não mexe no disco.

Perdão, mas só pra confirmar se entendi com certeza: quando você diz isso, você se refere a não tentar realizar mais nenhum outro procedimento além daquele já explicado sobre a remoção do antergos_grub, certo?

[Marcos FRM]

2 minutos atrás, Shakmatton disse:

Perdão, mas só pra confirmar se entendi com certeza: quando você diz isso, você se refere a não tentar realizar mais nenhum outro procedimento além daquele já explicado sobre a remoção do antergos_grub, certo?

 

efibootmgr não mexe no disco. Não tem risco de apagar nada.

[Shakmatton]

4 minutos atrás, Marcos FRM disse:

 

efibootmgr não mexe no disco. Não tem risco de apagar nada.

Ah, percebi. Bom, se a operação é totalmente segura, então nesse caso eu entendo que nem é preciso fazer backup de nada.

 

[Shakmatton]

Bom, voltei aqui para dar um feedback.

 

Sobre a remoção do "antergos_grub" usando o efibootmgr: deu certo!

Foi bem simples mesmo, como mencionado... e fiquei com a impressão de que o meu SO ficou um pouco mais rápido também...

 

Sobre a questão das partições desordenadas usando o cfdisk: deu certo também!

Tudo ordenado e ok aqui.

 

Aí chegou a hora do teste final: saber se o teclado travava na tela do grub ou não...

 

Bom, Após sair do modo Live do pendrive linux, retornei a BIOS da placa-mãe para as configurações de fábrica.

E após reiniciar, consegui usar o teclado para selecionar outro SO que não fosse o primeiro da lista!

 

Porém... quando saí dele e reiniciei a máquina novamente para escolher mais um outro SO, o problema do teclado travado voltou novamente...

Tentei novamente mexer nas configurações de Legacy da placa-mãe, mas nada adiantou... o problema teima em permanecer...

 

Bom... o teclado tinha funcionado na tela do grub após a ejeção do pendrive (cujo Linux em modo Live estava em UEFI) - e acho que não é a primeira vez que, sem querer, consigo usar as setas do teclado no grub dessa forma...

 

Estou desconfiado de que a placa-mãe esteja desregulando alguma opção após os meus boots/reboots... Bom, não sei se vem ao caso, mas a pilha foi recentemente trocada. Então está nova e ok (embora tenha percebido que, nas opções de Data e Hora da BIOS, o horário do dia está errado, marcando algumas horas de diferença para o horário real).

 

Também percebi que houve uma mudança na última vez que estive observando o setup da ordem de boot na BIOS. Antes detectava as unidades de HD e de CD. Agora, a unidade de HD não é mais detectada: em seu lugar, é detectada mais uma unidade de CD (ou seja, há duas linhas repetidas e redundantes na listagem de dispositivos detectados). Envio foto para maior esclarecimento:

 

 

Me pergunto se essa confusão teria a ver com aquelas entradas duplicadas que sublinhei (em cores verde e rosa). Na verdade, estou ficando desconfiado que haja algum problema adicional ali que esteja provocando o travamento do teclado durante a tela de grub...

 

[Marcos FRM]

Qual a diferença entre "Boot Option #1" e "#2"?

 

Em qual partição o "stage 2" do GRUB está? Na /dev/sda5, a partição ativa do disco? (onde /boot/grub/grub.cfg usado por ele está)

[Shakmatton]

6 horas atrás, Marcos FRM disse:

Em qual partição o "stage 2" do GRUB está? Na /dev/sda5, a partição ativa do disco? (onde /boot/grub/grub.cfg usado por ele está)

Olha, não tenho certeza se entendi bem a pergunta, mas se você se refere à partição na qual está instalada o grub atual, então sim, o grub está abrigado na partição /dev/sda5 (Biglinux). Reparei também que esse caminho e arquivo (o do /boot/grub/grub.cfg) existe em todos os 3 OS Linux (sda5 - Biglinux, sda6 - EliveOS, e sda7 - Linux Mint).

 

Vou enviar abaixo algumas imagens para maior esclarecimento:

 

1) Screenshots do Gparted, com zoom, para facilitar a leitura (ignore a partição chamada "Windows 10"... eu desisti de instalá-lo, e ainda não apaguei essa partição vazia...):

 

 

 

 

 

 

2) Boot Options: por agora, o conteúdo das entradas atuais é esse:

 

 

 

 

 

O Boot Option #1 está assim:

 

Essa lista de lista de dispositivos que aparece no Boot Options #1 também aparece da mesma forma no #2 e #3, só que com os dispositivos SATA PS: [...] e CD/DVD Drive selecionados, respectivamente.

 

 

3) CD/DVD Rom Drive BBS Priorities: aqui há 2 entradas com esse mesmo nome (como mostrado na foto anterior). Enquanto a primeira mostra uma tela vazia (sem opções), a segunda já mostra o Boot Option #1, selecionado como SATA PS: [...]:

 

 

 

4) Outras opções envolvendo "Legacy": aqui deixo umas imagens extras de apoio, mostrando com mais detalhes as opções das listas que envolvem o termo Legacy. A configuração que você vê foi testada algumas vezes em combinação com outras, mas isso foi antes de resolver a questão do "antergos_grub" e das partições desordenadas... então não sei se seria interessante refazer os testes, ou se não adiantaria muito nesse caso... :

 

 

 

 

 

 

5) Extras: não sei se são úteis ou não, mas, por via das dúvidas, aqui envio alguns prints sobre possíveis desconfianças que porventura poderiam estar desencadeando o problema original do tópico (por exemplo, ouvi falar sobre "XHCI", sobre gente ativando/desativando USB 3.0 - todas as minhas portas USB na minha máquina são 2.0 -, mas, novamente, não sei se isso influenciaria em alguma coisa...).

 

 

Em "Sata Configuration", por exemplo, minha configuração está em Native IDE. Não me parece que isso teria a ver, mas já ouvi falarem sobre AHCI (que, pelo que vi, é uma tecnologia da Intel, o que não faria diferença para o meu processador AMD)...

 

 

E por fim, a configuração de vídeo. Embora não tenha uma placa gráfica dedicada (a minha possui memória compartilhada), me pergunto se haveria uma chance, ainda que bem pequena, de o problema estar envolvido nesta parte também, de alguma forma...

 

 

 

 

(Desculpe pelo exagero/excesso de detalhamento no tópico.)

 

Ah, estive lendo um outro tópico daqui, sobre atualização de BIOS, e lembrei que não postei isso:

 

https://www.gigabyte.com/Motherboard/GA-F2A55M-HD2-rev-30/support#support-dl-BIOS

 

A minha versão é anterior à da versão Beta.

Se nada mais funcionar, em último caso, o que valeria mais a pena (ou o que seria menos arriscado)?

 

- Formatar tudo e arriscar reinstalar e particionar o HD novamente em modo BIOS Legacy ("vai que a culpa é de algum bad block...").

- Formatar tudo e arriscar reinstalar e particionar o HD em modo GPT/UEFI (e tentar a sorte encontrando uma nova ISO Win7 e fazendo-a funcionar).

- Tentar atualizar a BIOS, realizando um upgrade da última versão estável para uma versão Beta.

 

 

[Marcos FRM]

Então antes de tudo, dentro do BigLinux, reinstale o código no MBR:

 

grub-install /dev/sda

 

 

Assim tem certeza que boot.img e core.img estão sincronizados com os módulos de /boot/grub.

 

2 horas atrás, Shakmatton disse:

AHCI (que, pelo que vi, é uma tecnologia da Intel,

 

AHCI é o modo recomendado. A especificação foi desenvolvida pela Intel e adotada por toda a indústria.

 

2 horas atrás, Shakmatton disse:

Extras: não sei se são úteis ou não

 

Tem algumas sugestões aqui:

 

https://unix.stackexchange.com/questions/72625/why-is-usb-not-working-in-linux-when-it-works-in-uefi-BIOS

[Shakmatton]

3 horas atrás, Marcos FRM disse:

Então antes de tudo, dentro do BigLinux, reinstale o código no MBR:

 

grub-install /dev/sda

 

 

Assim tem certeza que boot.img e core.img estão sincronizados com os módulos de /boot/grub.

 

 

AHCI é o modo recomendado. A especificação foi desenvolvida pela Intel e adotada por toda a indústria.

 

 

Tem algumas sugestões aqui:

 

https://unix.stackexchange.com/questions/72625/why-is-usb-not-working-in-linux-when-it-works-in-uefi-BIOS

 

Hmm, entendo. Vou em breve fazer isso e retorno aqui o resultado do grub-install.

 

Deixo aqui uma outra informação... não lembro se mencionei aqui, mas, antes de criar o tópico, eu tinha tentado fazer a restauração do grub através de uma ferramenta nativa do Biglinux, que te dava algumas opções para que ele fizesse todo o trabalho de restaurar o grub. Não sei se isso pode ter causado o problema das partições desordenadas...

 

Pelo que disseram aqui, aqui e aqui, não sei até que ponto isso poderia ter me afetado anteriormente, mas fiquei com a impressão de que selecionar o AHCI em vez de IDE não é algo recomendado (aparentemente, isso seria algo perigoso para o Windows, e um pouco chato de resolver no Linux também). Inclusive, lá dizem até que mudar de IDE para AHCI passa a ser mais interessante mesmo pra quem tem SSD...

 

Bom, também fiquei pensando se aquelas linhas duplicadas na imagem (a que tem CD/DVD Rom BBS Drive Priorities) teriam aparecido por conta de ter mexido nessa opção...

 

Obrigado pelo link sobre IOMMU, XHCI e EHCI. Peloq que entendi, o primeiro seria útil para quem usar VirtualBox ou similares, não? Mas de acordo com o link (e pelo que entendi), quando ele é usado em conjunto com os outros dois (que controlam a ativação do USB 3.0 e 2.0, respectivamente), aparentemente ele pode resolver problemas de inicialização... vou testar ativá-los todos e observar o que acontece.

[Marcos FRM]

20 minutos atrás, Shakmatton disse:

AHCI em vez de IDE não é algo recomendado

 

Pelo contrário. No Windows, depois de instalado, precisa mexer no registro antes de mudar; é uma alteração simples. [*] No Linux, em geral não precisa fazer nada, pois o driver ahci.ko é tão importante que as distribuições ou compilam embutido dentro da imagem do kernel (Arch, Fedora) ou adicionam o módulo incondicionalmente ao initramfs (Debian, cuja configuração do mkinitramfs é MODULES=most). Ou seja, pode mudar que será indolor. AHCI tem a vantagem de ativar algumas coisas que o carcomido modo IDE não fornece, como NCQ, ALPM.

 

40 minutos atrás, Shakmatton disse:

Bom, também fiquei pensando se aquelas linhas duplicadas na imagem (a que tem CD/DVD Rom BBS Drive Priorities) teriam aparecido por conta de ter mexido nessa opção...

 

Esqueça essa entradas. Todo BIOS UEFI gera esse tipo de coisa. Uns mais, outros menos. Não tem importância.

 

[*] 

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci]    (Windows Vista/7)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\storahci]  (Windows 8 e superiores)

Em "Start", altere o valor para 0 (zero).

 

[Shakmatton]

16 minutos atrás, Marcos FRM disse:

No Windows, depois de instalado, precisa mexer no registro antes de mudar;

 

Nossa, por pouco eu não testo isso agora... acontece que, por um acaso, consegui mais uma vez fazer o teclado funcionar durante o grub. Tudo o que fiz foi ativar o IOMMU, e o XHCI e EHCI. Daí, acabei escolhendo o Win7 (que creio que, a essa altura, já deva estar bagunçado, já que um tempo atrás saí pela BIOS testando combinações de opções sem saber dessa questão de ter que mexer no registro dele antes de mudar para AHCI...).

 

Mas quando reiniciei para testar pra saber se conseguiria entrar em outro Linux, o problema do teclado travado voltou a ocorrer novamente...

 

Daí, dentro do BigLinux, tentei o comando do grub-install, conforme você me recomendou aqui.

Infelizmente, o problema continou.

 

Até aqui, esse ciclo "problema-resolvido/problema-existente" que às vezes ocorre me faz pensar que haja uma espécie de conflito ou de sobreposição de configurações ou de diretivas (se é que posso usar tais termos) sobre o que se deve ou não fazer durante o grub. Me parece que o problema reside na (ou também na) placa-mãe...

Após tentar dentro do BigLinux o comando grub-install /dev/sda, eu tentei também consertar o grub com a ferramenta nativa da versão Live do Biglinux no pendrive...  escolhi a opção de restauração intermediária (#2, como na figura abaixo), mas também não deu em nada...

 

Bom, antes de jogar a toalha, creio que ainda posso tentar "brincar" um pouco com as novas configurações...

Ou posso tentar instalar um novo SO naquela partição "vazia" do Win 10...

Ou ainda, poderia tentar reaver algum grub de outro SO Linux...

[Shakmatton]

15 horas atrás, Marcos FRM disse:

/boot/grub/grub.cfg usado

Eu fui investigar os 3 arquivos grub.cfg, que encontrei no BigLinux, no Linux Mint e no Elive_OS. Achei curioso que, embora todos sejam mais ou menos parecidos em algum grau, somente o grub.cfg do BigLinux é que possui uma linha chamada "insmod part_gpt".

 

Bom, isso me fez pensar que talvez o problema não estaria na placa-mãe, mas sim em algum (possível) conflito entre as instalações. Não me lembro de ter instalado o BigLinux em modo GPT... será que a resolução da questão passaria simplesmente por uma formatação e reinstalação mais cuidadosa?

 

Aproveito pra complementar o tópico sobre essa questão com esse link aqui.

 

[Marcos FRM]

10 horas atrás, Shakmatton disse:

"insmod part_gpt"

 

Irrelevante. Ele carrega ambos, "part_gpt" e "part_msdos" (MBR). Como o disco está em MBR, o primeiro não é usado.

[Shakmatton]

Ah, entendo. É... vou ver o que eu arrumo aqui então.

Se eu conseguir algum progresso, retorno aqui para relatar como consegui resolver.

 

Marcos, muito obrigado pelo apoio, e principalmente, pela paciência em ajudar!

Valeu!