Shakmatton

Estou de volta pra encerrar o tópico e relatar a solução encontrada. Um dos problemas foi resolvido via efibootmgr (ver solução no post #6). O outro (e principal problema), infelizmente, não foi resolvido. Aparentemente, a capacidade de detecção da placa-mãe usando MBR DualBIOS "morreu". Logo, foi necessário recorrer à reinstalação de todas as partições e sistemas operacionais do zero, usando um "inédito" modo UEFI. Essa outra solução, portanto, envolve formatação geral da máquina (ver solução #29). Ao final de todas as reinstalações, o teclado voltou a funcionar no Grub normalmente. Agradeço ao Marcos e ao Clube do Hardware pela possibilidade de ter conseguido resolver este problema.

Eu baixei o Rufus semana passada, se não me engano. A minha versão é a 4.1.2045 (estou usando-o em um Windows 10 de um notebook emprestado aqui pra mim). Por coincidência, abri ele aqui agora e apareceu uma mensagem de update liberado para download da versão 4.2. Vou baixá-lo para tentar novamente o procedimento de instalação com ele. (A minha insistência com a abordagem "não-Rufus" é devido a eu já ter tentado o procedimento com ele anteriormente, testando a instalação do pendrive primeiramente em máquinas virtuais. Porém, tanto no VBox como no Boxes a instalação ou não dava certo ou dava erro de driver "faltante" (perdi um bom tempo assistindo diversos tutoriais que prometiam resolver isso, mas não tive sucesso). Claro, como agora a situação é diferente (terei que formatar a máquina de qualquer forma), e de posse das novas informações (como as do post #29), acho que posso tentar tudo novamente do zero, mas dessa vez, diretamente na máquina real. E, se nada mais der jeito na situação, o jeito seria migrar pro Windows 8.1, que bem ou mal, está mais próximo do Windows 7 e do setup mais antigo da minha máquina.

Opa, só uma atualização aqui de última hora: atualizei a BIOS pra uma versão mais nova, mas acabou que isso não surtiu efeito algum sobre o problema do teclado, que ainda continua travado. Bom, pelo menos valeu a tentativa. Pelo que vejo, a solução é realmente reinstalar tudo do zero, criando um disco em formato UEFI-GPT. Vou me organizar aqui para isso agora.

Entendi. Nas opções de setup da BIOS, deixar marcada a opção "Other OS", para ficar em conformidade com a natureza CSM intrínseca ao Win 7. Já no gravador Rufus, o procedimento é tratar a ISO do Win 7 como se ela fosse gravada no USB como UEFI puro. Embora eu esteja mais inclinado a testar um update de BIOS, ainda sigo acompanhando uma discussão sobre as particularidades da instalação de uma ISO Win 7 x64 para USB. Algumas coisas que estão por lá você até já mencionou (o que me dá mais segurança e tranquilidade, para o caso de tentar o procedimento de instalação sem Rufus). Agora, o que me chamou a atenção ali foram os seguintes pontos: - A possibilidade de usar qualquer versão Win 7 (a que eu uso atualmente é versão MBR do tipo "All-in-One"); - A questão do tamanho do arquivo "\sources\install.wim" (se entendi bem, ela teria que ser dividida em pedaços menores, caso esse arquivo ficasse maior que 4G, excedendo a capacidade do Fat32); e - Um comando do Diskpart chamado "Active" (que dizem que só pode ser usado em discos MBR, ou que a partição se tornaria bootável em um disco MBR, enquanto que em um disco GPT isso não poderia ser feito). Isso significaria simplesmente dar um F12 na tela inicial de BIOS e ver na lista de dispositivos uma entrada "UEFI" e outra "Generic"...?

Obrigado pelo encorajamento! É sempre saudável para um novato quando alguns "tabus" são desmistificados, como o da atualização da BIOS...

Opa, muito obrigado pelo retorno e também pela paciência para descrever o procedimento! Vou responder aqui em partes então. Pois é, eu acabei lendo sobre isso também ontem. Vi que essa tal tecnologia AGESA teria a ver com os tais processadores Ryzen que tá todo mundo falando sobre... isso me fez pensar que um upgrade de BIOS para o meu processador de 2014 realmente não me seria de muita serventia, tal como você falou aí também. Por outro lado, eu fiquei na dúvida se um upgrade não poderia ser uma solução para o caso mesmo assim. ======================== Explico: em junho eu criei um tópico nesse site sobre a possibilidade de uma troca de fonte de energia do cpu, já que ela tinha uns 10 anos, era genérica e já não estava mais ligando direito a máquina (acabei não tirando nenhuma foto na época, mas lembro que, às vezes, quando ligava, aparecia uma mensagem na tela da BIOS falando sobre reset, algo assim... é uma lembrança um pouco mais vaga, mas acho que era algo sobre isso). (Sem mencionar que aqui na cidade onde estou, há uma taxa considerável de quedas de energia. Mesmo com as proteções adequadas, além de usar iClamper e bom senso durante tempestades, não sei até que ponto isso poderia "esculhambar" alguma coisa lá na BIOS da placa-mãe também...) Felizmente, de lá pra cá, pude trocar a fonte por uma nova, e também adquiri uma nova bateria para a placa-mãe. Nesse sentido, tudo funciona perfeitamente. ======================== Mas eu, como leigo, fiquei pensando aqui se tudo o que aconteceu poderia ter mexido com alguma coisa lá na memória/configuração da BIOS... e se porventura um "simples" upgrade de BIOS poderia restabelecer as funções básicas da placa de volta (incluindo aí a habilidade de voltar a detectar as portas USB ou o modo que funciona em conformidade com a tecnologia MBR Legacy). Olha, não sabia disso! Eu até tinha lido/separado para leitura várias postagens na internet sobre instalação do Win 7 em UEFI, mas estranhamente, pouca gente volta lá e diz algo como "Consegui! Basta fazer tal passo X e etc...". Imagino que esse novo detalhe que você mencionou faça a diferença. Vou realizar algumas novas tentativas com algumas máquinas virtuais pra ver o que acontece.

Entendo. Eu percebi que ela funciona normalmente no modo UEFI, com todos os meus OSes sendo detectados (seja em tempo de boot do HD ou direto por algum grub de live ISO ou de Ventoy) e com o teclado funcionando normalmente nele. Por outro lado, o problema do teclado travado só ocorre no modo BIOS MBR Legacy. Porém, o esforço que faço é justamente para tentar reaver a funcionalidade da MBR como antigamente, sem teclado travando. Tudo para poder manter o Win 7 em modo MBR. Do contrário, teria que encarar um processo e tentar uma reinstalação do Win 7 em modo UEFI (e pela internet afora, vejo muito mais gente apanhando com isso do que conseguindo realizar uma instalação no modo UEFI)... Estou pesquisando agora tudo o que posso aqui sobre instalação manual, Q-Flash e termos relacionados ao update de BIOS, mas fiquei bem receoso quando vi aquela BIOS em letras vermelhas. Considerando tudo o que já foi tentado, você acha que, ao contrário do que dizem por aí, realmente não haveria perigo de baixar uma versão "Beta" (com "letras vermelhas ameaçadoras" e tudo)?

Ei Marcos! Desculpe ressucitar esse tópico, mas é que só agora percebi uma coisa sobre a placa-mãe que queria compartilhar aqui, só para desencargo de consciência. Bem, tentei 1 milhão de outras coisas envolvendo grub, instalação de outros OS, inserir e remover pendrive, mas não pude obter uma solução final. Então, quando já estava entregando os pontos pra formatar e instalar tudo do zero, reparei uma coisa: No BIOS da placa-mãe, o "System Information" acusa que a versão é FFa, e a data dela é de 18 de março de 2014. Bom, eu estava dando uma olhada no site da Gigabyte, e vi que me escapou completamente um fato: a última BIOS estável (não-beta) é de 29 de Maio de 2014. Dois meses de diferença, portanto. Não sei se o "a" do "FFa" significaria "alfa", isto é, uma versão anterior à disponível no site deles (a "FF"). Pensei em realizar um salto de fé, baixando e instalando essa nova versão FF de Maio disponível na lista de BIOS... Porém, não vejo a minha atual versão "FFa", de Março, na lista deles. Isso significaria que, qualquer problema que houver com a BIOS nova = Game Over, certo? Ou haveria uma forma de fazer uma cópia de backup da BIOS antiga instalada, para alguma eventualidade de dar problema? Aqui o link da foto com a versão atualmente instalada. E aqui, outro link, mostrando a lista de BIOS disponíveis para download no site da Gigabye.

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!

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.

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...

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.

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.

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...

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