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