Nothing Like

Continuando as atividades do blog, dessa vez resolvi falar sobre Linux, o que provavelmente não é o tópico de maior interesse de quem lê este blog.
Como ultimamente o pessoal da faculdade está instalando novas distros e literalmente destruindo o boot (não culpem o slackware a culpa é de vocês) após ler esse artigo do TuxRadar, resolvi traduzi-lo para que o pessoal entenda o que está acontecendo e possa resolver a maioria dos seus problemas, pelo menos no quesito boot.
Lembro também que quem quiser ler o artigo original ele se encontra em TuxRadar – How to fix Linux Boot Problems, de qualquer maneira vale a visita ao site, que é novo mas tem bastante potencial.

Ainda planejo mais alguns artigos sobre Linux principalmente sobre a parte básica que estarei divulgando posteriormente, no mais aproveitem a leitura.

Note for English Readers: this is a translation, see the original on TuxRadar – How to fix Linux Boot Problems

O processo de boot, ou inicialização, é toda a mágica que acontece no seu computador da hora em que você o liga até o momento em que ele está pronto para que você possa logar.

Durante esse tempo todo tipo de mensagem incompreensível aparece na tela, o que geralmente você não presta atenção, e que na maioria das distros é substituida por uma bela splash-screen com uma barra de progresso.

Se fosse sempre assim tudo bem, mas pode acontecer de o boot parar de funcionar. Neste tutorial iremos examinar o processo de boot com mais detalhes, entender o que pode dar errado, como diagnosticar e como resolver o problema.

Desmistificando o problema.

Quando dou aulas sobre Linux, alguns de meus alunos demonstram várias maneiras de resolver os problemas, uns tentam a maneira “livro de receitas”, “Se aparecer a mensagem X eu devo executar o comando Y”, mas raramente isso funciona. Eu geralmente os aconselho da seguinte maneira “O mais importante é entender como o sistema deveria estar funcionando, depois é entender o que o sistema está fazendo quando a falha acontece”.

Fig. 1: O processo normal de boot no Linux.

Com isso em mente, vamos dar uma olhada em como o Linux faz o boot. Conhecendo a sequência normal e determinando até que ponto o sistema executou sem problemas serão os pontos chaves na resolução de problemas. A figura acima mostra a sequência normal de eventos do boot (setas verdes) e indica alguns dos possíveis problemas (setas vermelhas).

Entendendo o processo de boot

O boot ocorre em vários estágios. Quando o PC é ligado, o controle inicialmente é passado para um programa (chamado BIOS) que fica em uma memória de apenas leitura na placa-mãe. A BIOS executa testes internos de hardware e depois procura um dispositivo bootável, ela também provê uma interface onde você pode configurar a ordem de procura por dispositivos.

A maioria das BIOS modernas possui várias opções incluindo boot via rede (PXE), no nosso caso consideramos apenas o boot do disco rígido.

A BIOS carrega as informações de MBR (Master Boot Record) do dispositivo selecionado e as executa. Se houver alguma falha a BIOS informa “Sistema Operacional não encontrado” ou algo parecido. As informações de MBR ocupam o primeiro setor do disco e contém o esquema de partições (64 bytes) e um pequeno programa (446 bytes) conhecido como “stage1″ do processo de boot.

O loader de stage1 é bem simples, tudo o que ele faz é mostrar a palavra GRUB na tela e carregar o próximo passo utilizando o “block map” que está contido no MBR. (O “block map” mostra em quais blocos do disco está o segundo loader). Estou assumindo aqui que você está utilizando o GRUB, há vários outros bootloaders, incluindo um mais antigo e conhecido deles, o LILO, porém o GRUB é mais recente, esperto e utilizado na maioria das distros atuais. O segundo estágio de boot na verdade é chamado de “stage1.5″, e se você procurar no seu diretório “/boot/grub” você pode ver estes arquivos, usualmente eles tem nomes como e2fs_stage_1_5 ou reiserfs_stage_1_5.

Cada um destes programas é responsável por tratar um sistema de arquivos, e2fs_stage_1_5 pode ler partições em ext2 e ext3, o reiserfs_stage_1_5 pode ler partições reiser, e etc. Essa habilidade do GRUB de ler os arquivos pelo nome durante o boot (antes que o Linux seja carregado) é o que realmente o diferencia do LILO.

O loader “stage1.5″, responsável por carregar o “stage2″ é ligeiramente maior. Esse stage é responsável por ler um arquivo de configuração (em geral /boot/grub/menu.lst ou /boot/grub/grub.conf) e, baseado nas entradas que ele encontrar, montar um menu de opções de quais SOs você deseja efetuar o boot. Se ele não encontrar nenhum dos arquivos de configuração ele abre um prompt interativo onde você pode entrar com os comandos manualmente.

Uma entrada típica do arquivo “menu.lst” é parecida com:

title openSUSE 10.2
    root (hd0,0)
    kernel /boot/vmlinuz-2.6.18.2-34-default root=/dev/hda1 vga=0x317 showopts
    initrd /boot/initrd-2.6.18.2-34-default

A linha “title” simplesmente especifica o que irá aparecer no menu do GRUB. A linha que a segue determina os comandos a serem executados se esta for selecionada. A linha “root” mostra pro GRUB onde o sistema está alocado. O GRUB tem um sistema próprio para nomear as partições de disco que é um pouco diferente do sistema utilizado no Linux em geral.

Na língua do GRUB, “hd0″ se refere ao primeiro disco do sistema, em um sistema que utiliza discos IDE corresponde ao “/dev/hda”, ou em casos de discos SATA o “/dev/sda”. o “(hd0,0)” se refere a primeira partição daquele disco, no Linux “/dev/(h|s)da1″. A linha “kernel” demonstra o arquivo de kernel que o GRUB deve carregar. No fim desse arquivo ainda há outras opções que podem ser passadas pro kernel, mais sobre isso depois.

A linha “initrd” indica o arquivo de disco RAM, “initial RAM Disk”, uma imagem que será usada pelo kernel enquanto ele inicializa, o GRUB também é responsável por carregar este arquivo para a memória, se ele falhar para encontrar o kernel ou o a imagem ramdisk ele reporta “Error 15: File not found” e para.

Assim que o kernel inicia ele monta o sistema de arquivos do HD. O nome da partição que contém esse sistema de arquivos é passado como parâmetro para o kernel, como pode ser visto nas linhas do “menu.lst” acima. Montar o sistema de arquivos corretamente é o ponto chave para o boot e se você está tentando resolver problemas no boot é vital saber se ele chega ou não até este ponto. Falhas em montar o sistema de arquivo geralmente geram “kernel panic”, apesar de que alguns sistemas apenas pararão.

Se o kernel conseguir montar o sistema de arquivos corretamente, ele lança um único processo (que tem sua ID 1) o qual roda o programa “/sbin/init”. Se este programa não for encontrado pode acontecer: “kernel panic”, desligamento ou (dependendo da distro) que você caia em uma shell em modo root. E apenas pra colocar um pouco de confusão, o Ubuntu não utiliza o init, ele foi substituido pelo upstart.

O “init” é responsável por rodar os scripts que inicializarão todos os outros processos do sistema. Há também outro script que é inicializado neste processo, em sistemas Red-Hat ele é o “/etc/rc.d/c.sysinit”, no SUSE é o “/etc/init.d/boot”. Entre várias coisas estes scripts executam verificações de consistência e montam outras partições do disco que estão especificadas no “/etc/fstab”. Como há milhares de coisas que podem dar errado nesse estágio nos pararemos nesse ponto, pelo menos nesse artigo.

Mexendo diretamente com o GRUB

Um ponto importante à saber é como interver na sequência de boot do GRUB. A maioria das distros configura o GRUB com uma opção de boot padrão, e uma pequeno tempo (em geral, alguns segundos) nos quais você pode apertar ESC e ganhar controle direto do GRUB.

A partir de agora você pode: seguir as instruções na tela e editar os comandos associados com a sua seleção do menu antes de iniciar o boot ou abrir um prompt de comando do GRUB e digitar os comandos diretamente, nesse ponto você pode digitar as linhas “root”, “kernel” e “initrd” que vimos no arquivo “menu.lst” anteriormente. Fig. 2 (abaixo) mostra o resultado de digitar “help” na linha de comando do GRUB.

Fig. 2: O resultado de digitar o comando “help” na linha de comando do GRUB.

A Mídia de Resgate

Se ajustar as opções do GRUB não ajudarem no reparo do sistema então é hora de usar um boot de resgate, que significa efetuar o boot de um CD de instalação ou alguma outra mídia de reparo. O kernel e seus módulos serão carregados à partir desta mídia um sistema pequeno (mas completo) para a memória, resultando em um sistema que não depende de nenhum dos arquivos do HD.

Você pode então montar as partições (do HD) à partir desse sistema e reparar o estrago. Na maioria das distros novas o seu CD (ou DVD) de instalação pode ser usado desta maneira e nem é necessário que o CD de resgate seja da mesma distro que você está utilizando.

É importante lembrar também que a maneira que você irá visualizar os arquivos que estão no seu HD é diferente, eles não estarão localizados nos mesmos locais caso eles fossem montados diretamente. Exemplo: Se utilizando o CD de resgate você montar sua partição principal dentro de “/mnt” e quiser acessar o arquivo “/etc/fstab” dentro dessa partição ele estará em “/mnt/etc/fstab”.

Estudo de Caso

Nosso primeiro estudo de caso é sobre um sistema RHEL5 (Red Hat) no qual o diretório “/usr” foi colocado em uma partição separada. Por alguma razão (que eu não me lembro qual seja) eu tive que ditar o arquivo “/etc/fstab” para um administrador novato que acabou preenchendo o campo LABEL=/user ao invés de LABEL=/usr na linha que especificava a montagem dessa partição. O erro causado não deixava o sistema ser multi-usuário, e sim caia em uma shell mono-usuário. A mensagem era:

fsck.ext3: Unable to resolve 'LABEL=/user'        [FAILED]

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell
Give root password for maintenance
(or type Control-D to continue):

O importante aqui é tentar ler a mensagem de erro. Por quê o sistema está tentando achar a label chamada “/user”? Em que arquivo essa label aparece?

Hmmmm…. Talvez o “/etc/fstab”? Como o sistema gentilmente nos deixou em uma shell de root podemos ir direto ao arquivo e editá-lo. Porém, o sistema de arquivos está montado como somente leitura (por causa do fsck) então não é possível editar o arquivo e salva-lo. A dica é mudar as opções de montagem da partição para permissão de escrita sem desmontá-la, isso é feito da seguinte maneira:

# mount -o remount,rw / # primeiro # pertence ao comando.

Depois de fazer isso é só corrigir o “/etc/fstab” e reiniciar normalmente.

Segundo estudo de caso

Nosse segundo estudo de caso é mais complexo que o anterior e envolve um cenário com dual-boot.

Primeiro eu instalei o openSUSE 10.2 em um HD vazio, alocando 8GB para a partição “hda1″ como partição principal e 2GB em “hda2″ como partição de “swap”. O instalador escreveu o “stage1″ na MBR e o “stage1.5″ nos blocos subsequentes, depois eu instalei o Fedora 7 no espaço vazio do HD, alocando assim mais 8GB em “hda3″ para a partição principal do Fedora e compartilhando o swap com o openSUSE.

A figura 3 (abaixo) pode ajudar caso você esteja perdido. Eu permiti que o Fedora instalasse o seu GRUB por padrão em “/dev/sda”. (A convenção de nomes é um pouco confusa por que o openSUSE 10.2 utiliza o nome das partições padrão, “hda”, enquanto o Fedora usa o estilo SCSI, “sda”.)

Fig. 3: A configuração dual-boot mostra a interação entre as partições do SUSE e do Fedora.

Durante a instalação do Fedora me foi oferecido a opção de adicionar itens extras no GRUB eu pedi que fosse instalado um item para o SUSE 10.2 que está em “/dev/sda1″. O item criado adicionou as seguintes linhas na configuração do GRUB:

title SUSE 10.2
      rootnoverify (hd0,0)
      chainloader +1

Se eu selecionar este item pelo menu, o GRUB do Fedora irá carregar o GRUB do openSUSE do primeiro setor da primeira partição (que o GRUB chama de “(hd0,0)” e o Fedora 7 chama de “/dev/sda1″ e o openSUSE chama de “/dev/hda1″ – será que isso precisava ser tão confuso?) Agora eu posso escolher entre o Fedora e o SUSE no boot, apesar de que escolhendo o SUSE eu ainda tenho o pequeno incômodo de passar por um segundo menu de boot do GRUB. Se eu tivesse feito isso de uma maneira inteligente eu teria copiado as configurações do SUSE para o GRUB que estão “hda1″ para o GRUB que está em “hda3″ o que seria mais conveniente, já que eu não teria que passar pelo segundo menu.

Se livrando do Fedora

Algumas semanas depois eu decidi que não precisaria mais da instalação do Fedora e que ao invés disso eu usaria a partição na instalação do SUSE, então (logado no SUSE) rodei o comando:

# mke2fs -j /dev/hda3

…para criar um novo sistema na partição. Lembrando, “hda3″ era a partição da minha instalação do Fedora. Então montei a nova partição em “/mnt”. Tudo funcionou perfeitamente até o momento que o sistema foi reiniciado. O GRUB falhou, eu não conseguia fazer boot no Fedora (o que era esperado já que eu destrui a partição) e o pior, eu também não conseguia efetuar boot no SUSE, de fato a única coisa que acontecia era aparecer a palavra “GRUB” na tela.

O grande segredo: “Não entre em pânico!”, pense sobre o que você fez. Olhe novamente a figura 3 e lembre-se que o conteúdo de “hda3″ foram sobreescritos. O “stage1.5″ instalado pelo Fedora que referenciava o “stage2″ em “hda3″ não existe mais. O que precisamos pra reinstalar o “stage1″ e “stage1.5″ originais e conseguirmos efetuar o boot no SUSE?

A única maneira de fazer isso é com uma mídia de resgate. Como mencionado anteriormente qualquer instalação do Linux pode fazer esse trabalho, eu escolhi o Ubuntu por que ele vem em formato “livecd”, ou seja, eu consigo um desktop completo, incluindo Gnome, apartir do CD.

O Ubuntu, diferente do Fedora, nomeia as partições como “sda” assim quando o meu livecd iniciou eu pude montar minha partição do SUSE no Ubuntu da seguinte maneira:

$ sudo mount /dev/sda1 /mnt

(Caso você esteja se perguntando o que é o comando “sudo”, ele é utilizado por que o Ubuntu desabilita o login direto como root, o que requer que o comando “sudo” seja utilizado para os comandos que precisam desse privilégio. No livecd não é necessário nenhuma senha para executa-lo)

Agora é preciso que o GRUB reescreva o MBR. Ainda não tenho certeza de onde o GRUB se encontra (estou procurando o GRUB da instalação do SUSE, ou seja o que está em “hda1″), mas executando:

$ sudo find /mnt -name grub

Eu facilmente encontrei o grub no diretório “/mnt/usr/sbin/grub”. Agora é possível executá-lo e digitar os comandos necessários em seu prompt:

$ sudo /mnt/usr/sbin/grub

grub> root (hd0,0)
grub> setup (hd0) (hd0,0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded. succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.
grub> quit

O comando chave aqui é “setup (hd0) (hd0,0)” que diz para o GRUB reinstalar o “stage1″ original (o do SUSE) na MBR do (hd0), e então copiar o “stage1.5″ para os setores subsequentes. (Para uma descrição mais detalhada leia o manual do GRUB).
Depois que isso foi feito eu posso reiniciar e então logar normalmente no SUSE.

Resgate Internacional

LiveCDs como o Ubuntu ou Knoppix funcionam perfeitamente, mas existem opções menores e mais rápidas. Uma que seria interessante de se olhar é o SystemRescueCD, que não só é mais rápido no boot mas também contém uma coleção de ferramentas para trabalhar com as partições, desde de o clássico gparted até itens não-usuais como o ntfs-3g, que permite acessar partições NTFS com total suporte à escrita e leitura, o que facilita caso precise recuperar algo de uma partição NTFS com mal funcionamento. Outro benefício desse CD é que ele pode ser totalmente carregado em memória podendo assim deixar o drive de CD livre caso necessário.