Notebook: GRUB a partir de Ubuntu em /dev/sdb falta quando é boot em modo tablet

Iniciado por alexandre.mbm, 20 de Setembro de 2015, 16:06

tópico anterior - próximo tópico

alexandre.mbm

Um notebook HP Split x2 tem a tela removível da base, então ele pode funcionar como um tablet gigante, sem teclado/touchpad. São duas unidades de armazenamento. A primeira, /dev/sda, é um SSD com Windows, coisa da configuração original. Antes era Windows 8 e recentemente foi atualizado para Windows 10. Um Ubuntu foi instalado pelo usuário na unidade /dev/sdb. O GRUB aponta para /boot/efi na partição /dev/sda2. A raiz / desse sistema GNU/Linux (Ubuntu) está na partição /dev/sdb2.

O problema é que se ligamos a tela fora da base (desconectada de teclado/touchpad), um GRUB pára em modo linha de comando. Por que? Porque o GRUB fora configurado e gravado a partir de /dev/sdb2, e naquele momento /dev/sdb (HD na base) não está presente; apenas está presente o SSD /dev/sda da unidade de tela (modo tablet).

A correção disso parece óbvia: forçar o GRUB a ser configurado e gravado "a partir de" e "na" unidade /dev/sda, para que não haja falta pelo /dev/sdb estar ausente, e o Windows (/dev/sda3, se não me engano) possa entrar como opção padrão pelo timout. Só que eu tenho testado coisas... sem sucesso, e não faço ideia de como alcançar tal resultado.

Nota: já sei fazer chroot no Ubuntu /dev/sdb2 usando comandos mount --bind.

Anderson_Coelho

Nunca tentei instalar Win/Ubuntu em PC com HD e SSD e também nem sequer já mexi com UEFI. Mas tentando ajudar um pouco, saiba que o Grub só vai funcionar se a partição do Ubuntu estiver presente. Mesmo que você tenha instalado o Grub no SSD, se você tirar o HD não vai de jeito neenhum mesmo. Sempre acho melhor deixar o Ubuntu e o Grub no mesmo HD. Se tem o Windows no SSD, o correto na minha opiniao era deixar o gerenciador de boot do Windows no SSD.

Então, o que eu aconselharia é passar a /dev/sda2 para o HD /dev/sdb. Esse tutorial abaixo me faz acreditar que isso é possível sem precisar reinstalar o sistema, mas nunca tentei fazer algo do tipo também:

http://www.ubuntudicas.com.br/blog/2014/10/como-trocar-hd-sem-reinstalar-o-ubuntu/

Depois, usaria uma mídia de instalação do Windows para recuperar a inicialização dele no SSD. Então, depois teria que configurar a ordem de boot dos dispositivos de acordo com as necessidades aí.

No mais, seria bom que você passasse mais detalhes com as saídas dos comandos executados a partir do Ubuntu:

sudo fdisk -l

df -h

alexandre.mbm

Está me parecendo que em UEFI não tem isso de ordem de boot e essa questão fica embutida na firmware .efi. O que eu tenho a dizer é que provavelmente você está errado, quanto à presença do Ubuntu ser em todos os casos necessária. Meu irmão, dono e usuário da máquina, garante-me que ela já funcionou como queremos que volte a funcionar.

Daqui a pouco farei a tentativa de instalar o GRUB usando um partição totalmente dedicada em /dev/sda2. Ela não será apenas o lugar de /boot/efi, mas também o lugar do próprio /.
Antes eu estou reestudando, no wiki do Arch Linux, como recriarei /boot/efi caso precise.

O sistema aqui é e precisa ser UEFI/GPT. Preciso esquecer MBR completamente.

Update

Será que a configuração deverá necessariamente fazer um chainload para um GRUB em /dev/sdb? Talvez somente nesse caso o GRUB em /dev/sda não reclame a eventual ausência de /dev/sdb. Mas eu ainda devo fazer testes mais simples...

lucianox

Não funciona mesmo porque embora o binário do GRUB esteja na ESP em /boot/efi, o arquivo de configuração ainda vai estar em /boot/grub.
Solução: instalar o GRUB inteiramente na ESP.
Pra fazer isso você vai ter que compilar o GRUB. Se for seguir este caminho, recomendo a leitura https://help.ubuntu.com/community/UEFIBooting#Setting_up_GRUB2_.28U.29EFI e http://www.rodsbooks.com/efi-bootloaders/installation.html

Se quiser seguir por outro caminho mais fácil, instale outro boot manager. Eu iria de rEFInd.
Oldschool

alexandre.mbm

Estou tentando fazer o Windows Boot Manager chamar o GRUB. Até agora, sem sucesso. Ainda falta testar reinstalar o GRUB em /dev/sdb, gerando novo .bin com dd. No SSD tem só o Windows mesmo...

Consegui o Windows Boot Manager aparecer por substituir o bootmgfw.efi com uma versão original.

Update

Parece que para o Windows Boot Manager chamar o GRUB seria necessário fazer imagem contendo stage2, para fazer chainload. Era coisa complicada. Eu não conseguia efetivamente gravar o GRUB 2 no /dev/sdb. O boot-repair como que dizia: "use a partição /boot/efi separada". Uma entrada de "aplicativo de firmware", introduzida na ordem de menu do gerenciador, nunca funcionaria; seria o aplicativo em EFI/ubuntu/shimx64.efi. Então eu ia deixar um boot WIndows simples, e quando quisesse entrar no GRUB, faria F9 para trazê-lo direto do menu do firmware UEFI. Mas foi quando eu me deparei com o contéudo de EFI/ubuntu/grub.cfg:

search.fs_uuid 3020b2c2-bdd1-4d60-a8b7-b29b1e4897e6 root hd1,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg


A partir desse reconhecimento, a solução veio rápido, alterando-o para ficar assim:

set old_root=$root
search.fs_uuid 3020b2c2-bdd1-4d60-a8b7-b29b1e4897e6 root hd1,gpt2
if [ $root != $old_root ]; then
    set prefix=($root)'/boot/grub'
    configfile $prefix/grub.cfg
else
    search --fs-uuid --no-floppy --set=root 746E-44FF
    chainloader (${root})/EFI/Microsoft/Boot/bootmgfw_BACKUP.efi
    boot
fi


Se o HD é achado, é exibido um GRUB. Se não, vai direto para o boot do Windows!

lucianox

Oldschool

alexandre.mbm

Sim. Em modo tablet tudo se passa como na configuração original de fábrica. Em modo notebook (com base), vem o GRUB.