O novo xerife da inicialização

Propaganda
O novo xerife da inicialização | ANÁLISE
Boot com UEFI
ANÁLISE
O novo xerife da
inicialização
A especificação do boot UEFI oferece novas capacidades – e novas dores
de cabeça também – se o usuário não estiver preparado para isso.
por Christopher Dock
A
lgumas coisas das quais nunca
devemos esquecer:
➧ primeiro carro
➧ primeiro computador
➧ primeiro beijo
No entanto, uma destas primeiras
coisas não deve ser um borked (termo usado para algo que foi destruído
ou não funciona corretamente) [1]
das partições do novo laptop. Infelizmente, algumas pessoas passam
por essa experiência, especialmente quando displicentes ao instalar o
Kubuntu 12.04 em modo dual-boot
com o Windows 7. A principal razão
de problemas é geralmente porque
o Windows 7 original pré-instalado
estava configurado para usar o novo
recurso de boot UEFI, e o Linux
novo, adicionado posteriormente,
não tinha essa capacidade.
Master Boot
Record (MBR)
Até recentemente, a maioria dos
computadores usava o Basic Input
Output System (BIOS) para gerenciar o processo de boot. O sistema
de BIOS executa algumas tarefas
preliminares e então carrega o setor
de boot do disco rígido. Este setor
de boot é chamado de Master Boot
Linux Magazine #100 | Março de 2013
Record (MBR) e é composto pelos
primeiros 512 bytes de início do disco, onde estão descritos não apenas
o layout do disco (suas partições),
como também a forma de iniciar o
(ou os) sistema operacional. O MBR
mudou um pouco ao longo dos anos,
mas não é radicalmente tão diferente
de quando foi criado, em 1983.
O MBR contém quatro partições
primárias, onde uma delas é definida
como partição ativa ou inicializável. Juntamente com uma lista das
partições e contém um pequeno
carregador de boot (bootloader) (de
aproximadamente 440 bytes) para
carregar o sistema operacional. Este
bootloader encontra a partição ativa
e então executa o Volume Boot Record (o primeiro setor da partição),
que continuará o processo de carregamento do sistema operacional.
O MBR possui algumas limitações que têm impedido seu progresso. Duas dessas limitações são
o fato de o número de partições
primárias ser limitada a quatro, e
o tamanho das partições de disco
ser limitada a 2TB. Estes limites
não eram um problema quando
surgiu a primeira implementação
do MBR, mas agora que é possível
comprar um drive USB de 3TB por
menos de R$300, estas questões se
tornaram mais visíveis.
Os especialistas têm reconhecido a necessidade de romper com
o passado e produzir um moderno
firmware independente do sistema
operacional e com suporte para inicializar a partir de discos de grandes
dimensões, bem como em um ambiente sem sistema operacional de
forma flexível, com capacidade de
rede e design modular. A interface
de firmware estendida (Extended
Firmware Interface) da Intel é o
resultado desse esforço. Uma organização de toda a indústria foi
formada em 2005 para promover
a adoção da especificação EFI, e a
especificação foi então renomeada
de Unified EFI (UEFI) [2].
Como funciona
a UEFI
A UEFI traz o conceito de BIOS
para um nível totalmente novo. Em
vez de um MBR de 512 bytes e algum
código de inicialização, a UEFI, em
contraste com a opção de simples
legado do BIOS, sabe o que é um
sistema de arquivos e ainda possui
seu próprio sistema de arquivos, com
arquivos e drivers.
73
ANALISE | O novo xerife da inicialização
Este sistema de arquivos possui
geralmente entre 200MB e 500MB e
é formatado como FAT32. Em vez de
alguns bytes de código de montagem
para carregar o sistema operacional,
cada sistema instalado deve possuir
um bootloader próprio (como por
exemplo, no caso do Grub: grubx64.
efi). Este bootloader terá lógica o
suficiente para exibir algum tipo de
menu de boot ou iniciar o carregamento de um sistema operacional.
Basicamente, a UEFI é o próprio
mini-sistema operacional.
A UEFI tem deixado de lado
a antiga metodologia de partição
MBR e, ao invés dela, utiliza o
GPT (GUID Partition Table) para
gerenciar tabelas de partição. Usar
o GPT elimina a limitação no
número de partições e também
garante o suporte para partições
maiores de até 9ZB [3]. A partição
GPT é parte do padrão UEFI, mas
é limitada a apenas uma lista de
partições sem nenhuma lógica de
bootloader. A especificação permite um número quase ilimitado de
partições, mas implementações específicas podem impor limites mais
práticos (o Windows, por exemplo,
limita o número de partições a 128
[4]). Como o MBR, a UEFI marca uma das partições como ativa,
mas esta é apenas a partição EFI,
nunca qualquer uma das partições
do sistema operacional.
A estrutura geral do sistema de
arquivos EFI significa que cada sistema operacional (ou fornecedor) tem
seu próprio diretório. Este diretório
pode conter quaisquer dados e também todos os arquivos necessários
para carregar o sistema operacional:
/EFI
/Boot
/Microsoft/
/ubuntu
/refind
Alguns diretórios possuem uma
hierarquia bastante horizontalizada,
enquanto outros (por exemplo, os da
74
Microsoft [5]), não. Os programas
bootloader, por padrão, possuem a extensão .efi; no entanto, esta é apenas
uma convenção: arquivos bootloader
são devidamente criados e executados quando necessário mesmo sem
essa extensão.
Olhar para a estrutura de diretório
EFI oferece a esperança de que, com
a próxima instalação ou reinstalação,
outro sistema operacional Microsoft
não irá sobrescrever nossa instalação Linux atual, mas não tentamos
isso ainda. Uma coisa especialmente
conveniente sobre como a UEFI foi
implementada no Linux é que, após
o computador ser iniciado, a partição
EFI, pelo menos no Kubuntu, é montada sobre a partição de boot (/boot/
efi), o que torna fácil mudar ou experimentar este sistema de arquivos.
Levando isso um passo adiante, no
entanto, um bootloader é apenas um
programa que executa a operação de
carregamento do sistema operacional.
E se este programa fosse um Shell?
Um Shell com habilidade UEFI
permitiria que o usuário interagisse
com o sistema UEFI para modificar
os parâmetros de boot, iniciasse bootloaders e obtesse informações sobre
o ambiente de firmware. Shells para
EFI já existem mas o usuário não
precisa se contentar com qualquer
Shell que tenha sido enviado com
sua instalação UEFI: ao invés disso,
pode obter um novo ou escrever o seu
próprio. O projeto Tianocore fornece
um EFI Shell [6] referenciado no site
Arch Linux [7]. O Shell Tianocore
inclui várias opções que atualmente
não possuem muita utilidade, mas que
podem vir a calhar no futuro. Com
este Shell, é possível selecionar um
novo bootloader manualmente, fazer
listas de diretório, editar arquivos de
texto ou remover arquivos.
Ao iniciar o Shell, é necessário
um ponto de partida. Curiosamente,
quando executamos o nosso Shell, o
diretório de trabalho atual não se encontra em qualquer um dos sistemas
de arquivos, o que causa um erro em
cada comando. Para criar uma listagem de diretório ou mudar para um
diretório diferente, só precisamos selecionar o sistema de arquivos primeiro.
Este Shell foi criado, conferindo-lhe
uma atmosfera MS-DOS. Por exemplo, para mudar para um sistema de
arquivos, basta selecionar o número
do sistema de arquivos: FS0: <Enter>.
A designação de unidade FS0
é uma referência ao File System 0;
dependendo da configuração, também podemos ter um FS1 ou FS2.
Podemos registrar um novo Shell,
um novo sistema operacional, ou sistemas operacionais múltiplos com a
UEFI. Assim, o próprio computador
pode perfeitamente suportar múltiplos
sistemas operacionais ou Shells. Temos algumas opções diferentes para
manter essas entradas.
A primeira seria usar o programa
efibootmgr do Linux para manipular entradas armazenadas na memória RAM não volátil (NVRAM).
Dependendo da implementação,
a UEFI pode realmente suportar
o efibootmgr quando inicializar em
tela UEFI/BIOS. O Asus N76, que
usa o sistema de firmware Aptio baseado em UEFI da AMI, permite
que o usuário registre o programa
diretamente com a opção Add New
Boot Option (adicionar nova opção
de boot) (figura 1).
Eventualmente, podíamos fazê- lo
trabalhar quando paramos de fazer referência explícita à unidade (no caso,
\EFI\path versus FSO:\EFI\path). Foi
possível, então, experimentar novos
bootloaders e um Shell. As entradas
do caminho apontado em path são
relativas à partição EFI instalada.
Boot seguro
A UEFI oferece muita flexibilidade, mais (e maiores) partições, e
uma maneira fácil e padrão para a
definição de vários sistemas operacionais. O que há para não gostar?
Talvez o usuário já tenha ouvido
www.linuxmagazine.com.br
O novo xerife da inicialização | ANÁLISE
falar do infame recurso “Secure
Boot” (Boot Seguro) da UEFI,
que foi controverso e bastante comentado Internet a fora e esteja
preocupado com isso.
O boot seguro garante o processo de boot, impedindo drivers
ou bootloaders que não sejam assinados com uma chave conhecida
de inicializar, evitando uma possivel infeccção do seu sistema de
inicialização por vírus ou trojans.
Como várias fontes na comunidade de código aberto já relataram,
este recurso impediria com eficiência que alguém compilasse
a distribuição favorita e a instalasse no próprio PC (pelo menos
no pior dos casos – um caso um
pouco melhor seria se o usuário
tivesse a capacidade de desativar
o recurso de boot seguro [8] [9]).
Como consertar
o laptop
Vamos considerar a seguinte configuração problemática:
Drive 0:
➧ GPT particionado
➧ Sistema de arquivos UEFI
➧ Instalação do Windows não-
funcional
Drive 1:
➧ MBR particionado
➧ Algumas partições repletas de
dados
➧ Instalação Linux não-funcional
A incompatibilidade entre GPT
e MBR, bem como nossos esforços
de reparo subsequentes, tornaram
o sistema impossível de inicializar (unbootable). Quando acrescentamos o Linux, o bootloader
preexistente não pode inicializar
o sistema Linux no Drive 1 MBR
particionado. Tentamos mudar o
drive de boot, que nos devolveu
o Linux – incluindo um menu
GRUB que apontava para a opção de inicialização do Windows.
Contudo, o Windows não iniciou
com êxito. Para obter o Windows
de volta, tentamos usar a opção
Windows Restore, mas causamos
ainda mais problemas, o que tornou o sistema Linux impossível
de inicializar.
Como corrigir os problemas com
a bagunça do dual-boot? A facilidade da nossa recuperação foi porque
tínhamos uma imagem de backup
do primeiro disco, antes de qualquer
instalação Linux, porque o Linux
estava sendo instalado no segundo
disco, e porque reconhecemos a
necessidade de instalar o Kubuntu,
com suporte da EFI.
A lista de tarefas a serem realizadas, foi pequena:
1. Converter a unidade 1 do MBR
para GPT;
2. Adicionar/modificar partições
no Drive 1;
3. Instalar o Kubuntu, com suporte da EFI;
4. Salvar toda a configuração da
EFI
Instalação Kubuntu;
5. Restaurar imagem de disco
para Drive 0;
6. Restaurar configuração Kubuntu para partição EFI;
7. Reiniciar o computador e testar.
Nota: quando se tratam de partições, é importante fazer backup dos
dados para evitar uma possível perda.
Figura 1 Alguns sistemas de firmware permitem adicionar uma opção de inicialização própria para a configuração.
Linux Magazine #100 | Março de 2013
75
ANALISE | O novo xerife da inicialização
O processo segue de perto uma
instalação gráfica padrão; configuramos nossas partições de troca
(swap) (/) e /home e selecionamos o
GRUB como bootloader. O único
truque para esta etapa é como devemos iniciar o disco.
Arquivos de
configuração
do Kubuntu
Figura 2 No nosso Asus, os dispositivos de UEFI boot prontos são
iniciados com o prefixo “UEFI:”.
Conversão MBR
para GPT
O laptop foi inicializado com o
Kubuntu 12.04 com um DVD Live.
As partições estavam bem; o problema
era o particionamento, então a coisa
mais fácil era usar o comando sgdisk
para ler na antiga tabela de partição
MBR e escrever uma nova tabela de
partição GTP. É importante ter em
mente que deve haver algum espaço
livre para manter as novas estruturas
GPT. Isso pode exigir redimensionar
a primeira partição para deixar algum
espaço livre no início do disco, bem
como redimensionar a partição final
para deixar algum espaço no final.
Tudo isso é descrito em detalhes por
Rod Smith [10].
Uma vez que toda a preparação
tenha sido feita, o comando a seguir
executa a conversão:
sgdisk -g /dev/sdX
Este comando irá fazer a conversão adequada, mas deixará a unidade
sem qualquer sistema operacional
inicializável.
Adicionar/modificar
partições
Todo o particionamento foi feito
durante a instalação anterior; nenhum particionamento adicional
76
foi necessário neste caso (o usuário também pode realizar o particionamento na etapa de instalação
do Kubuntu).
Instalação do Kubuntu
12.04 com suporte EFI
Esta etapa é fácil, mas não 100%
óbvia. Quando colocamos um CD
ou DVD na unidade e o iniciamos, a
UEFI vai examinar o que a mídia tem
disponível; o que pode ser também
um pendrive USB ou um DVD de
boot. No entanto, pelo menos para
o nosso Asus, tanto um DVD MBR
de boot normal quanto um DVD
de boot UEFI foram encontrados
na lista de dispositivos de inicialização. Apesar de ambas as entradas
se referirem ao mesmo disco, é importante que a entrada UEFI seja
escolhida porque esta entrada parece ser o gatilho para a utilização do
GRUB EFI em vez da configuração
padrão do MBR. No nosso Asus, os
dispositivos UEFI inicializáveis são
prefixados com UEFI: na lista de
boot (figura 2).
Quando inicializamos o Kubuntu como um dispositivo UEFI, ele
traz uma lista de menus GRUB familiares. É possível que qualquer
uma dessas opções consiga instalar
qualquer sistema compatível com o
EFI com sucesso, mas escolhemos a
opção Install Expert Mode.
A partição EFI é simplesmente
um sistema de arquivos FAT32. Fazer
o backup da configuração significa
simplesmente copiar os arquivos
para um local seguro. Basta montar
o sistema de arquivos EFI e copiar os
arquivos necessários para outro lugar:
mount /dev/sdX1 /mnt/mountpoint
cp -rp /mnt/mountpoint/EFI/refind
/media/usbstick
cp -rp /mnt/mountpoint/EFI/ubuntu
/media/usbstick
Nota: o diretório EFI provavelmente será a partição 1, sdX1, mas
essa não é uma regra.
Restaurar a imagem
de disco para disk1
Como nunca planejamos fazer
uma bagunça na nossa instalação,
antes de começarmos esta grande
aventura, fizemos o backup do Drive
0 usando o comando dd:
Salvar
dd bs=1M if=/dev/sdX
of=/media/usbdevice/saved-image
Restaurar
dd bs=1M
if=/media/usbdevice/saved-image
of=/dev/sdX
Neste ponto, o Drive 0 do laptop possui a instalação original do
Windows 7, mas a configuração
do bootloader Kubuntu foi perdida. Isto não tem nada a ver com a
Microsoft ou com o Windows, mas
sim com a forma como fizemos o
backup do disco.
www.linuxmagazine.com.br
O novo xerife da inicialização | ANÁLISE
Restaurarção EFI
do Kubuntu
O laptop foi inicializado com o
Kubuntu 12.04 em um DVD Live
para o próximo passo. A partição EFI
é simplesmente um sistema de arquivos FAT32. Restaurar a configuração
significa simplesmente copiar os arquivos a partir de um local seguro:
mount /dev/sdX1 /mnt/mountpoint
cp -rp /media/usbstick/refind
/mnt/mountpoint/EFI
cp -rp /media/usbstick/ubuntu
/mnt/mountpoint/EFI
Depois de restaurar esses arquivos,
seremos capazes de reiniciar o laptop
e iniciar o Linux ou o Windows 7. n
Gostou do artigo?
Queremos ouvir sua opinião. Fale
conosco em
[email protected]
Este artigo no nosso site:
http://lnm.com.br/article/8311
Linux Magazine #100 | Março de 2013
Mais informações
[1] Borked: http://www.urbandictionary.com/define.php?term=borked
[2] UEFI: http://www.uefi.org/home
[3] Tamanho das partições GPT: http://en.wikipedia.
org/wiki/GUID_Partition_Table
[4] Windows e GPT: http://msdn.microsoft.com/en-us/
library/windows/hardware/gg463525.aspx
[5] FAQ Windows e GPT: http://msdn.microsoft.com/enus/library/windows/hardware/gg463525.aspx
[6] Tiancore ProjectL: http://sourceforge.net/apps/
mediawiki/tianocore/index.php?title=Efi-shell
[7] Shell UEFI no Arch: https://wiki.archlinux.org/index.php/Unified_
Extensible_Firmware_Interface#UEFI_Shell_download_links
[8] Como fazer o boot seguro da UEFI funcionar em plataformas
abertas: http://www.linuxfoundation.org/publications/
making-uefi-secure-boot-work-with-open-plataforms/
[9] Linus Torvalds sobre Windows 8, UEFI e Fedora: http://www.zdnet.com/
blog/open-source/linus-torvalds-on-windows-8-uefi-and-fedora/11187
[10] http://www.rodsbooks.com/gdisk/mbr2gpt.html
77
Download