\chapter{Como Fazer um Disco de Inicialização Linux }
\author{Tom Fawcett ({\ttfamily fawcett@croftj.net}
        \\ 
      }
\date{v3.2, June 1998}
Este documento descreve como definir e construir o seu próprio disquete de inicialização e do sistema de arquivos raiz para o Linux. Estes discos podem ser usados como disquetes de emergência ou no teste de novos componentes do sistema. Caso não se tenha lido o FAQ do Linux e outros relacionados, como o Tutorial de Instalação Linux e o Guia de Instalação Linux, não é indicada a construção de discos de inicialização. Caso se deseje somente criar discos de emergência, veja o Anexo \ref{distbootdisks} {(Discos de inicialização pré-configurados )}.


\section{Prefácio}



{\bfseries Nota: este documento pode não estar atualizado.} Caso a data no título da página seja anterior a 6 meses, por favor verifique na página do Projeto de Documentação Linux \nameurl{http://sunsite.unc.edu/LDP/}{} se há alguma  versão  mais  recente  deste  documento.

Apesar  deste  documento  estar  em  formato texto, ele pode ser  visualizado  de maneira muito {\itshape mais\/} agradável em formato Postscript ({\ttfamily .ps}) ou HTML, 
em virtude dos comandos  de  notação  tipográfica utilizados. Nós  sugerimos a utilização de um destes  formatos. 




\subsection{Notas}

\nidx{kernel, versões}

Graham Chapman ({\ttfamily grahamc@zeta.org.au}) escreveu a versão original e a suportou até a versão 3.1. Tom Fawcett
({\ttfamily fawcett@croftj.net}) adicionou uma grande quantidade de informações do Núcleo 2.0 e é o mantenedor atual da versão 3.2, porém muito da versão original ainda permanece. 

Este documento está voltado para usuários da versão {\bfseries  2.0 do Kernel do Linux ou posterior}. Caso se esteja utilizando uma versão anterior (1.2.xx ou mais antiga), é aconselhável utilizar versões do Bootisk-HOWTO arquivadas na \nameurl{http://www.zeta.org.au/~grahamc/linux.html}{Página Pessoal de Graham Chapman}.

As informações aqui apresentadas estão voltadas para os usuários da plataforma {\bfseries Intel}, porém muito do aqui descrito aplica-se ainda a outros processadores, porém não podemos ser conclusivos a respeito disso. Caso alguém tenha essa experiência, por favor  nos contate.








\subsection{Opiniões e Créditos}

Quaisquer comentários ou sugestões, positivas ou negativas, sobre o conteúdo deste documento são bem-vindas. Fizemos o melhor possível para garantir que as informações aqui contidas sejam confiáveis e acuradas. Por favor avise-nos caso sejam encontrados erros ou omissões.

Agradecemos às inúmeras pessoas que enviaram as suas sugestões e correções. A sua contribuição certamente tornou este documento muito melhor, do que se   tivéssemos feito tudo sozinhos.   

Por favor envie comentários, correções e dúvidas ao autor  no email apresentado mais acima. Não me incomodo em responder dúvidas, porém por favor leia primeiramente a seção  \ref{problemas} {(Problemas)}.








\subsection{Política de Distribuição}



Copyright \copyright{} 1995,1996,1997,1998 de Tom Fawcett and Graham Chapman. Este documento pode ser distribuído sob os termos da Licença do Projeto de Documentação Linux  disponível em \nameurl{http://sunsite.unc.edu/LDP/COPYRIGHT.html}{}.  Por favor contacte os autores caso não seja possível obter uma licença.

Esta é uma documentação livre. É distribuída na expectativa de ser útil, porém sem {\bfseries qualquer garantia};  mesmo as garantias inerentes de  {\bfseries comercialização} ou {\bfseries adequação a um propósito particular}.








\section{Introdução}



Discos de inicialização do Linux são úteis em diversas situações, tais como:
\begin{itemize}
\item Testes de um novo kernel.
\item Recuperação de falhas de disco -- qualquer coisa que pode variar desde um setor de inicialização à uma quebra de cabeça de disco. 
\item Consertando um sistema defeituoso. Um pequeno erro como superusuário pode tornar o sistema  sem condições de uso, e pode ser necessário inicializar o sistema a partir um disquete, para consertá-lo.
\item Atualizar arquivos críticos do sistema, tais como o {\ttfamily libc.so}.  
\end{itemize}


Há várias formas de se obter discos de inicialização (boot):

\begin{itemize}
\item Usar um de uma distribuição como Slackware, Red Hat, Conectiva Linux, o qual permitirá que ao menos o sistema seja inicializado.
\item Usar um pacote  desenvolvido para a criação de discos de emergência.
\item Aprender o que é necessário para cada tipo de disco operar e construir um por conta própria.
\end{itemize}


Algumas pessoas escolhem a última opção, construindo os seus próprios discos de emergência. Desta forma, na ocorrência de algum problema, eles podem saber o que deve ser corrigido. Mais ainda, é uma grande maneira de aprender como o Linux funciona.

Este documento assume alguma familiaridade com os conceitos básicos de administração de sistemas Linux. Por exemplo, deve-se  conhecer os conceitos de diretórios, sistemas de arquivos e disquetes. Deve-se saber ainda utilizar os comandos  {\ttfamily mount} e tt/df/, bem como o significado dos arquivos \url{/etc/passwd} e\url{fstab} e como eles estão constituídos, assim como saber que a maioria dos comandos deste HOWTO devem ser executados como superusuário (root).

A construção de um disco de inicialização do nada pode ser bem complexa. Caso não se tenha lido os conteúdos do FAQ do Linux e documentos relacionados, como por exemplo, o  HOWTO Instalação Linux e o Guia de Instalação Linux, não é aconselhável tentar-se a construção dos discos desta forma. Caso se necessite somente de um disco de emergência  que funcione, será {\itshape muito\/}  mais simples utilizar um pré-existente. Veja o Apêndice \ref{distbootdisks} {(Discos de Inicialização Pré-Configurados)}, abaixo, a fim de verificar onde encontrá-los .








\section{Discos de Inicialização e o Processo de Inicialização do Sistema}

\nidx{processo de inicialização}

Um disco de inicialização é basicamente uma miniatura de um sistema completo, ou seja é um sistema Linux contido em um disquete. Ele deve executar muitas das funções que o sistema completo permite. Antes de tentar construir um, deve-se conhecer os conceitos básicos do processo de inicialização do sistema, apresentados a seguir, os quais são suficientes para o entendimento do restante deste documento. Alguns detalhes e opções foram omitidos por não serem significativos para o conteúdo deste documento.




\subsection{O Processo de Inicialização}

\nidx{setor de inicialização}
Todos os sistemas em microcomputadores começam o processo de inicialização executando código existente na ROM  (especificamente no \idx{BIOS}), para carregar o setor 0 do cilindro 0 do dispositivo de inicialização. O \idx{ dispositivo de inicialização} é normalmente a primeira unidade de disquete (denominada  {\ttfamily A:} no DOS e \url{/dev/fd0} no Linux).
O BIOS tenta então executar este setor. Em muitos discos inicializáveis, o setor 0, cilindro 0, pode conter ainda:
\begin{itemize}
\item código de um carregador de sistemas, como o LILO, o qual localiza o kernel do sistema escolhido, carrega e  executa, de acordo com a opção definida.
\item o início de um kernel de um sistema operacional, como por exemplo o Linux.
\end{itemize}


Caso o kernel do Linux  tenha sido copiado fisicamente para um disquete, o primeiro setor do disco será o primeiro setor do kernel do Linux. O primeiro setor continuará o processo de inicialização, carregando o restante do kernel contido no dispositivo.

Uma vez que o  kernel tenha sido completamente carregado, ele executa alguma inicialização básica de dispositivos. Ele tenta carregar e montar o {\bfseries \idx{sistema de arquivos raiz}} a partir de algum dispositivo. Um sistema de arquivos raiz é simplesmente um sistema de arquivos montado como  ``/''.  Deve-se indicar para o kernel a localização do sistema de arquivos raiz; caso não seja encontrada uma imagem inicializável naquele local, o sistema é paralisado.

Em algumas situações de início do sistema, freqüentemente na inicialização a partir de disquetes, o sistema de arquivos é montado em um {\bfseries \idx{disco em memória}},  o qual é acessado na memória RAM, como se fosse um disco físico. Há duas razões para o sistema ser carregado em discos em memória. Inicialmente, memória RAM é muitas vezes mais rápida que um disquete, tornando a operação do sistema mais rápida, e segundo, o kernel do sistema pode ser armazenado como um
{\bfseries \idx{sistema de arquivos compactado}}  em um disquete, e descompactado no disco em memória, permitindo que muitos mais arquivos sejam armazenados no disquete.

Uma vez que o sistema de arquivos raiz é montado, pode-se visualizar uma mensagem similar a:

\begin{verbatim}
        VFS:  Raiz montado (sistema de arquivos ext2) somente para leitura.
\end{verbatim}


\ncdx{init}\ncdx{inittab}\ncdx{sysinit} Neste momento o sistema encontra o programa {\ttfamily init} no sistema de arquivos raiz (em {\ttfamily /bin} ou {\ttfamily /sbin})  e executa-o.   {\ttfamily init} lê o arquivo de configuração \url{/etc/inittab},  procurando por uma linha denominada {\ttfamily sysinit},  e executa o programa especificado. O programa {\ttfamily sysinit}  é normalmente denominado \url{/etc/rc} ou \url{/etc/init.d/boot}.  Este programa é constituído de uma série de comandos de shell que configuram os serviços básicos do sistemas, como por exemplo:

\begin{itemize}
\item Execução do comando  {\ttfamily \cdx{fsck}} em todos os discos
\item Carga dos \idx{módulos} necessários ao kernel
\item Inicialização da área de troca
\item Inicialização da rede 
\item Montagem dos discos descritos em {\ttfamily \cdx{fstab}}.
\end{itemize}


Este programa normalmente aciona diversos outros, tornando o processo de inicialização modular. Por exemplo, na estrutura comum do SysVinit, o diretório \url{/etc/rc.d/} contém uma estrutura complexa de subdiretórios, cujos arquivos definem como iniciar e desligar a maior parte dos serviços do sistema. De qualquer forma, um programa sysinit em um disco de inicialização é normalmente muito simples.

Quando o programa sysinit termina, o controle retorna ao  {\ttfamily init},  o qual entrará no  {\itshape nível de execução padrão\/}, especificado em  {\ttfamily inittab}, através da palavra chave {\ttfamily initdefault}.  A linha de nível de execução normalmente especifica um programa como {\ttfamily \cdx{getty}},  o qual é responsável pelo gerenciamento das comunicações através da console e ttys. É o programa  {\ttfamily getty} que apresenta a expressão familiar ``{\ttfamily login:}''. O programa {\ttfamily getty} por sua vez, chama o programa {\ttfamily \cdx{login}}  para administrar o processo de validação e iniciar  as sessões dos usuários.




\subsection{Tipos de Discos}

Após a revisão do processo básico de inicialização, podemos agora definir diversos tipos de discos envolvidos. Podemos classificar os discos em quatro tipos. A discussão aqui contida e através de todo o documento do uso do termo disco refere-se a disquetes, a menos que seja especificado o contrário, observando-se que na verdade, o conceito pode ser aplicado sem distinção a discos rígidos.

\begin{description}


\item[inicialização] \mbox{}

Um disco contendo um kernel do sistema que pode ser inicializado. O disco pode ser usado  para iniciar o kernel do sistema, o qual pode carregar o sistema de arquivos raiz a partir de outro disco. O kernel em um disco de inicialização pode receber informações sobre a localização do sistema de arquivos raiz.

Freqüentemente um disco de inicialização carrega o sistema de arquivos raiz a partir de outro disquete, porém é possível configurar a carga a partir de um sistema de arquivos raiz residente em um disco rígido, por exemplo. Isso é comumente feito quando se está testando um novo kernel (na verdade ``{\ttfamily make zdisk}'' criará um disco de inicialização automaticamente a partir dos fontes do kernel).



\item[raiz] \mbox{}

Um disco com um sistema de arquivos raiz contém os arquivos necessários para a execução de um sistema Linux. Tal disco pode não conter necessariamente nem o kernel e tão pouco o carregador de sistemas \nidx{disco raiz}.

Um disco raiz pode ser usado para executar o sistema independentemente de outros discos, uma vez que o kernel do sistema tenha sido inicializado. Normalmente o disco raiz é automaticamente copiado para um disco em memória, o que torna o acesso às suas informações muito mais rápido e libera a unidade de disquetes para outras atividades.



\item[inicialização/raiz] \mbox{}

Um disco pode conter  tanto o kernel    \nidx{disco de inicialização/raiz} quanto um sistema de arquivos raiz. Em outras palavras, ele contém todo o necessário para inicializar e executar um sistema Linux, sem a necessidade de um disco rígido. A vantagem desse tipo de disco é que a solução torna-se compacta. Todo o necessário está em um único disco. Por outro lado, o gradual aumento de tamanho dos itens necessários ao processo significa o aumento da dificuldade de colocar-se tudo em um único disquete, mesmo com compactação.



\item[utilitário] \mbox{}

É um disco que contém um sistema de arquivos, mas que não será montado como um sistema raiz. É um disco de dados adicionais, e pode ser utilizado para a disponibilização de utilitários, caso o disco raiz não tenha mais espaço disponível.\nidx{disquete com utilitários}



\end{description}


Em geral, quando falamos de "construir um disco de inicialização" significa a criação das funções de carga do kernel e do sistema de arquivos raiz. Elas podem estar juntas (em um único disco de inicialização e raiz) ou separados (disco de inicialização e disco raiz). A abordagem mais flexível para discos de emergência é provavelmente usar disquetes separados, e um ou mais disquetes de utilitários para gerenciar o que não foi possível colocar nos primeiros. 






\section{Construíndo um Sistema de Arquivos Raiz}

\label{buildroot}

Criar um sistema de arquivos raiz envolve a seleção dos arquivos necessários para que o sistema possa ser executado. Nesta seção descreveremos como construir um {\itshape \idx{sistema de arquivos raiz compactado}\/}. Uma opção menos usual é a construção de um sistema de arquivos não compactados em um disquete, que é montado diretamente como raiz; esta alternativa é descrita na seção \ref{nonramdiskroot} {()}.




\subsection{Visão Geral}

Um sistema de arquivos raiz deve conter todo o necessário para suportar um sistema Linux completo. Para tanto, o disco deve incluir os requisitos mínimos de um sistema Linux:



\begin{itemize}
\item A estrutura básica do sistema de arquivos
\item Conjunto mínimo de diretórios: {\ttfamily /dev, /proc, /bin, /etc, /lib, /usr,
/tmp}
\item Conjunto básico de utilitários: {\ttfamily sh, ls, cp, mv}, etc.
\item Conjunto mínimo de arquivos de configuração: {\ttfamily rc, inittab, fstab}, etc...
\item Dispositivos: {\ttfamily /dev/hd*, /dev/tty*, /dev/fd0}, etc...
\item Biblioteca que disponibilize as funções básicas necessárias aos utilitário
\end{itemize}


Evidentemente, qualquer sistema somente torna-se útil quando permite a execução de algum programa, e um disquete raiz somente é útil quando permite que sejam executadas funções como:

\begin{itemize}
\item Verificar um sistema de arquivos em outro dispositivo, por exemplo para checar o sistema de arquivos raiz em um disco rígido será necessário carregar o sistema operacional a partir de outro dispositivo, o que pode ser feito com um sistema de arquivos raiz em disquete. Pode-se então executar {\ttfamily \cdx{fsck}} no dispositivo original que contém o sistema raiz enquanto ele não estiver montado.
\item Restauração total ou parcial do dispositivo raiz original a partir de uma cópia de segurança usando arquivamento ou utilitários de compactação, tais como  {\ttfamily cpio, tar, gzip} e {\ttfamily ftape}.
\end{itemize}


Descreveremos como construir um sistema de arquivos  {\itshape compactado\/}, assim chamado  porque é arquivado compactado no disco e é descompactado do disco para memória. \nidx{sistema de arquivos raiz compactado}
Um sistema de arquivos compactado pode conter diversos arquivos (aproximadamente 2 megabytes) em um disquete padrão 1.440 Kb. Como o arquivo é muito maior que o disquete, não se pode construí-lo diretamente no dispositivo. Deve-se construí-lo em outro local qualquer, compacta-lo, e então copiá-lo para o disquete.






\subsection{Criando o Sistema de Arquivos}

\label{creatingrootfs}

Para construir-se um sistema de arquivos raiz, deve-se ter um dispositivo extra, grande o suficiente para conter todos os arquivos antes da compactação. Deve-se ter à mão um dispositivo capaz de conter pelo menos 4 Mb. Há diversas opções:

\begin{itemize}
\item Usar um {\bfseries \idx{disco em memória}} (DEVICE = \url{/dev/ram0}). Neste caso a memória é utilizada para simular um dispositivo de disco, sendo que deve ser grande o suficiente para conter todo o sistema de arquivos em seu tamanho adequado. Caso se use o LILO, deve-se verificar o arquivo de configuração (\url{/etc/lilo.conf}) e buscar uma linha similar a :

\begin{verbatim}
        RAMDISK_SIZE = nnn
\end{verbatim}


\nidx{RAMDISK\_SIZE, parâmetro LILO} o qual determina quanto de memória RAM será alocada. O padrão é  4096K, o qual deverá ser suficiente. Não se deve tentar utilizar esse disco em memória para máquinas com menos de 8 Mb de RAM.

Verifique a existência de um dispositivo como por exemplo \url{/dev/ram0, /dev/ram} ou \url{/dev/ramdisk}. Caso não exista, crie  \url{/dev/ram0} com  {\ttfamily mknod} (major number 1, minor 0).
\item Caso se tenha uma partição de disco rígido grande o suficiente (diversos megabytes) disponível, esta certamente será uma boa solução. Caso se tenha memória RAM disponível, pode-se desligar as funções de troca e utilizar a partição de troca (swap).
\item Usar uma {\bfseries \idx{simulação de dispositivo}}, o qual permite que um arquivo em disco seja tratado como um dispositivo. Usando-se uma simulação permite a criação de um arquivo de três megabytes no disco rígido e a construção do sistema de arquivos nele.

Para fazer uso da simulação de dispositivos, deve-se utilizar os programas {\ttfamily mount} e {\ttfamily unmount} especialmente alterados para isso. Eles podem ser encontrados no diretório:
\url{ftp://ftp.win.tue.nl/pub/linux/util/mount/}

Caso não se tenha uma simulação de dispositivos  (\url{/dev/loop0},
\url{/dev/loop1}, etc...) no sistema, pode-se criar uma através do comando ``{\ttfamily mknod /dev/loop0 b 7 0}''.  Uma vez instalados os binários especiais de {\ttfamily mount} e {\ttfamily umount} , deve-se criar um arquivo temporário em um disco rígido com capacidade suficiente (por exemplo, \url{/tmp/fsfile}). Pode-se, por exemplo, utilizar o comando:

\begin{tscreen}
dd if=/dev/zero of=/tmp/fsfile bs=1k count={\itshape nnn\/}
\end{tscreen}

para criar um arquivo com  {\itshape nnn\/} blocos.

Deve-se utilizar então o nome do arquivo no lugar do DISPOSITIVO a seguir. Ao utilizar o comando mount deve-se incluir a opção``{\ttfamily -o loop}'' para definir uma simulação de dispositivos.  \nidx{simulação de dispositivos} Por exemplo:
\begin{verbatim}
        mount -o loop -t ext2 /tmp/fsfile /mnt
\end{verbatim}


irá montar  \url{/tmp/fsfile} (através de uma simulação de dispositivo) no ponto de montagem  {\ttfamily /mnt}.  Através do comando {\ttfamily df} pode-se obter a confirmação disso.



\end{itemize}


Após a escolha de alguma dessas opções, deve-se preparar o DISPOSITIVO com o seguinte comando:

\begin{verbatim}
        dd if=/dev/zero of=DISPOSITIVO bs=1k count=3000
\end{verbatim}


Este comando inicializa com zeros o DISPOSITIVO. Este passo é importante pois o sistema de arquivos será compactado posteriormente e as partes não utilizadas e preenchidas com zeros, atingirão o máximo de compactação.



\nidx{inodes, alocação} Após, pode-se criar o sistema de arquivos. O kernel do Linux reconhece dois tipos de sistemas de arquivos para discos raiz a serem automaticamente copiados para discos em memória. Há o minix e o ext2, sendo o segundo o mais indicado.  No caso de utilização do ext2, pode ser útil  o uso da opção {\ttfamily -i} para especificar um número maior de inodes que o padrão do sistema; {\ttfamily -i 2000} é o valor sugerido, garantindo-se assim que não faltarão inodes. Alternativamente, pode-se salvar inodes removendo-se os diversos arquivos {\ttfamily dev} desnecessários.  {\ttfamily mke2fs} irá criar 360 inodes por padrão em um disquete 1.44. Cremos que 120 inodes são suficientes para um disco de emergência padrão, mas caso todos os dispositivos {\ttfamily /dev} sejam incluídos, então pode-se facilmente exceder os 360 disponíveis. Usar um sistema de arquivos raiz compactado permite um sistema de arquivos maior, provocando a utilização de um número de inodes maior que o padrão, porém pode ainda ser necessário reduzir o número de arquivos ou incrementar o número de inodes.

O comando necessário será algo similar a: 
\begin{tscreen}
mke2fs -m 0 -i 2000 DISPOSITIVO
\end{tscreen}


(Caso se esteja usando uma simulação de dispositivos, o arquivo em disco que se esteja utilizando deve ser informado no lugar do DISPOSITIVO.  \nidx{simulação de dispositivo} Neste caso {\ttfamily mke2fs} perguntará se realmente se deseja executar o comando e a resposta deve ser positiva.)

O comando {\ttfamily mke2fs}  automaticamente detectará o espaço disponível e fará a configuração automaticamente. O parâmetro {\ttfamily -m 0}  evita a alocação de espaço para o raiz, e adicionalmente provê mais espaço útil em disco.

A seguir deve-se montar o dispositivo:

\begin{verbatim}
        mount -t ext2 DISPOSITIVO /mnt
\end{verbatim}


(Deve-se criar um ponto de montagem {\ttfamily mnt} caso ele ainda não exista). Nas próximas seções, todos os nomes de diretórios são assumidos como relativos a  {\ttfamily /mnt}.




\subsection{Ocupando o Sistema de Arquivos}



Segue um razoável número mínimo de diretórios no sistema de arquivos raiz:

\begin{itemize}
\item  {\ttfamily /dev}  Dispositivos, necessários para as operações de Leitura/Gravação
\item  {\ttfamily /proc} Diretório temporário requerido pelo sistema de arquivos proc
\item  {\ttfamily /etc}  Arquivos de configuração do sistema
\item  {\ttfamily /sbin} Binários fundamentais do sistema
\item  {\ttfamily /bin}  Binários básicos e considerados parte do sistema
\item  {\ttfamily /lib}  Bibliotecas compartilhadas que provêem suporte à execução dos binários
\item  {\ttfamily /mnt}  Um ponto de montagem para manutenção em outros discos
\item  {\ttfamily /usr}  Utilitários adicionais e aplicações
\end{itemize}


(A estrutura de diretórios aqui apresentada é somente para uso no disquete raiz. Sistemas Linux têm uma política mais complexa e disciplinada, chamada Padrões de Sistemas de Arquivos, para determinar quais arquivos devem estar presentes e aonde.)

\ncdx{proc}\ncdx{mnt}\ncdx{usr}

Três destes diretórios devem estar vazios no sistema de arquivos raiz, devendo somente serem criados com o comando  {\ttfamily mkdir}.  O diretório {\ttfamily /proc} é basicamente um ponto de referência onde o sistema de arquivos proc está localizado. Os diretórios  {\ttfamily /mnt} e {\ttfamily /usr} são somente pontos de montagem para uso após a inicialização do sistema e a carga do sistema de arquivos raiz. Mais uma vez, estes diretórios somente precisam ser criados.

Os quatro diretórios remanescentes estão descritos nas seções a seguir:







{\ttfamily /dev}



\nidx{diretório de dispositivos (dev) }

Um diretório {\ttfamily /dev}  contendo um arquivo especial com todos os dispositivos a serem utilizados pelo sistema é fundamental para o Linux. O diretório em si é um diretório comum e pode ser criado com o comando  {\ttfamily mkdir}  da forma usual. Os arquivos especiais de dispositivos devem ser criados de uma forma especial, utilizando-se o comando  {\ttfamily \cdx{mknod}}.

Há um atalho, podendo-se copiar o conteúdo do diretório {\ttfamily /dev} e apagando-se o que for desnecessário. A única exigência é que a cópia seja efetuada com a utilização do parâmetro {\ttfamily -R}. Isso copiará o diretório sem copiar o conteúdo dos arquivos. {\itshape  Esteja seguro de utilizar um R maiúsculo\/}. Caso seja utilizado  {\ttfamily r} em formato minúsculo, provavelmente será copiado o conteúdo completo de todo o disco rígido -- ou no mínimo, o que couber no disquete! De qualquer forma, é importante estar atento ao comando:

\begin{verbatim}
        cp -dpR /dev /mnt
\end{verbatim}




Assumindo-se que o disquete esteja montado em {\ttfamily /mnt}.  A opção {\ttfamily dp} garante que ligações simbólicas serão copiadas como ligações, ao invés de usar um arquivo de destino, e que os atributos originais do arquivo serão preservados, assim como as informações sobre os donos.

Alternativamente, pode-se usar o programa {\ttfamily cpio}  com a opção {\ttfamily -p}, uma vez que  {\ttfamily cpio}  lida com arquivos especiais corretamente, e não tentará copiar o seu conteúdo. Pode-se por exemplo, utilizar o seguinte comando:

\begin{tscreen}
\begin{verbatim}
cd /dev
find . -print | cpio -pmd /mnt/dev
\end{verbatim}
\end{tscreen}


o qual irá copiar todos os arquivos especiais de  {\ttfamily /dev} para \url{/mnt/dev}. Na verdade, irá copiar todos os arquivos da árvore de diretórios iniciada em {\ttfamily /dev},  e criará todos os subdiretórios necessários na árvore de diretórios de destino.

Caso se deseje fazer da forma mais difícil, deve-se usar  {\ttfamily ls -l}  para mostrar os números major e minor dos dispositivos desejados, e criá-los  no disquete através do comando  {\ttfamily mknod}.

Uma vez que os dispositivos estejam copiados, é aconselhável verificar se todos os arquivos de dispositivos necessários foram copiados no disco de emergência. Por exemplo,  {\ttfamily \cdx{ftape}}  é utilizado por unidades de fitas, sendo necessário copiar todos eles, caso se pretenda acessar um dispositivo desse tipo a partir do disco de inicialização. 

Note que um inode é necessário para cada tipo de arquivo especial de dispositivo, e  \idx{inodes} podem, às vezes, serem um recurso escasso, especialmente em disquetes com sistemas de arquivos configurados. Desta forma é indicada a remoção de qualquer arquivo especial de dispositivos em {\ttfamily /dev} que não seja necessário no sistema específico. Por exemplo, caso não se tenha discos SCSI, pode-se tranqüilamente remover todos os arquivos de dispositivos começados por {\ttfamily sd}.  Similarmente, caso não se pretenda utilizar portas seriais, então todos os arquivos começados com  {\ttfamily cua} também podem ser removidos.

{\itshape Deve-se necessariamente ter os seguintes arquivos neste diretório:\/}
{\ttfamily console, kmem, mem, null, ram, tty1}.

{\ttfamily /etc}

\nidx{diretório etc}

Este diretório deve conter uma série de arquivos de configuração. Na maioria dos sistemas este pode estar dividido em três grupos:



\begin{enumerate}
\item Sempre requeridos, {\itshape por exemplo\/} {\ttfamily rc, fstab, passwd}
\ncdx{rc}\ncdx{fstab}\ncdx{passwd}
\item Podem ser requeridos, mas não há como assegurar
\item Arquivos desnecessários
\end{enumerate}


Arquivos que não são essenciais podem ser identificados através do comando:

\begin{tscreen}
\begin{verbatim}
        ls -ltru
\end{verbatim}
\end{tscreen}


Este comando gera uma lista em ordem inversa de último acesso, dependendo de que arquivos não são acessados ou utilizados e que, podem não estar presentes no disquete raiz.

Nos nossos disquetes raiz, temos um número de arquivos de configuração inferior a 15. Isso reduz o trabalho de lidar com um conjunto de três tipos de arquivos.

\begin{enumerate}
\item Os arquivos que devem ser configurados para um  sistema:

\begin{enumerate}
\item {\ttfamily rc.d/*} início do sistema e definição dos programas de cada nível de execução 
\item {\ttfamily \cdx{fstab}} lista dos sistemas de arquivos que devem ser montados
\item {\ttfamily \cdx{inittab}} parâmetros para o processo {\ttfamily init} , o primeiro que é executado em tempo de inicialização do sistema. \ncdx{init}
\end{enumerate}

\item Estes devem ser customizados para a inicialização de um sistema:
\begin{enumerate}
\item {\ttfamily \cdx{passwd}} lista de usuários, diretórios pessoais, etc...
\item {\ttfamily \cdx{grupo}} grupos de usuários \nidx{grupos de usuários}
\item {\ttfamily \cdx{shadow}} senha dos usuários. Eventualmente pode não existir. \nidx{sombra das senhas}
\end{enumerate}


Caso segurança seja um item importante do sistema específico, {\ttfamily passwd}  e {\ttfamily shadow}  devem ser  suprimidos, a fim de evitar a cópia de senhas de usuários para fora do sistema, e quando o sistema for inicializado através de disquetes, acessos indesejados serão rejeitados. De qualquer forma, há uma razão para  {\itshape não\/} suprimir  {\ttfamily passwd} e  {\ttfamily group}.  {\ttfamily tar} (e provavelmente outros programas de arquivamento) armazenam o usuário e o grupo junto com os dados dos arquivos. Caso estes arquivos sejam restaurados no disco rígido a partir de uma fita, os arquivos serão restaurados com seus nomes originais. Caso os nomes dos donos e grupos não existam em  {\ttfamily passwd}/{\ttfamily group}  durante a restauração,  as identificações de usuários e grupos (UID e GID) não estarão corretas. \nidx{restaurando arquivos}

Esteja certo de que o arquivo {\ttfamily \cdx{passwd}} contém ao menos o superusuário {\ttfamily root}.  Caso se pretenda utilizar outros usuários para acessar o sistema, deve-se estar seguro da existência de seus diretórios pessoais e interpretadores de comando (shell).
 
\item  Os demais: verificaremos mais adiante as informações sobre este tópico.
\end{enumerate}


Além disso, deve-se somente configurar dois arquivos, e o que eles devem conter é surpreendentemente pequeno.
\begin{itemize}
\item {\ttfamily rc} deve conter
\begin{verbatim}
        #!/bin/sh
        /bin/mount -av
        /bin/hostname Conectiva
\end{verbatim}


Deve-se estar seguro de que os diretórios estão corretos. A execução de {\ttfamily \cdx{hostname}}  não é obrigatória, somente dá um melhor acabamento ao trabalho.
\item {\ttfamily \cdx{fstab}} deve conter, no mínimo:

\begin{verbatim}
        /dev/ram0       /               ext2    defaults
        /dev/fd0        /               ext2    defaults
        /proc           /proc           proc    defaults
\end{verbatim}


Pode-se copiar as entradas de um arquivo  {\ttfamily fstab}, já existente, mas não se deve montar automaticamente qualquer partição do disco rígido; usando-se então o parâmetro {\ttfamily noauto}, pois o disco rígido pode estar danificado ou sem condições de uso no momento da inicialização do sistema.
\end{itemize}




O {\ttfamily \cdx{inittab}} deve ser alterado, de outra forma a linha  {\ttfamily \cdx{sysinit}} executará o  {\ttfamily rc} ou qualquer outro programa básico de inicialização que seja indicado. Ainda para assegurar-se de que usuários em portas seriais não poderão acessar o sistema, pode-se comentar todas as entradas em {\ttfamily getty} que incluam  dispositivos {\ttfamily ttys} ou {\ttfamily ttyS}  ao final da linha. Deve-se deixar as portas {\ttfamily tty} para poder-se acessar o sistema a partir da console.

Um arquivo {\ttfamily \cdx{inittab}} mínimo contém:
\begin{verbatim}
        id:2:initdefault:
        si::sysinit:/etc/rc
        1:2345:respawn:/sbin/getty 9600 tty1
        2:23:respawn:/sbin/getty 9600 tty2
\end{verbatim}


O arquivo {\ttfamily \cdx{inittab}} define o que o sistema executará nos vários estados, inclusive no seu início, em modo multiusuário, etc... Um ponto no qual deve-se ter muito cuidado é o de checar se todos os comandos informados em {\ttfamily inittab} referem-se a programas presentes e se o diretório está corretamente indicado. Caso se coloque no disco de emergência os arquivos de comandos apresentados  na Seção \ref{listings} {(Listas de exemplo do conteúdo do disco de inicialização)}  como um guia, e após se copie o  {\ttfamily inittab}  para o disco sem uma checagem cuidadosa, provavelmente ele falhará, e o problema terá origem na ausência de arquivos ou indicações erradas de diretórios.

\nidx{localizações pré-definidas}
Note que alguns comandos não podem ser movidos para qualquer outro lugar, porque alguns programas têm a sua localização dentro de seu código. Por exemplo em nosso sistema, \url{/etc/shutdown} tem a sua localização definida no fonte do comando \url{/etc/reboot}. Caso {\ttfamily reboot} seja movido para \url{/bin/reboot}, e após seja executado o comando {\ttfamily shutdown}, ele falhará, porque o arquivo {\ttfamily reboot} não pode ser localizado.

\nidx{diretório etc}

Para todo o restante, deve-se simplesmente copiar os arquivos texto no diretório {\ttfamily /etc}, mais os executáveis do mesmo diretório que não possam ser definidos como desnecessários. Como um guia, pode-se consultar os exemplos na Seção \ref{listings} {(Listas de exemplo do conteúdo do disco de inicialização)}. Provavelmente será suficiente copiar somente aqueles arquivos, porém sistemas podem ser muito diferentes, então não se pode estar seguro de que a lista apresentada seja suficiente. O único método de estar seguro é iniciar o sistema com {\ttfamily inittab} e verificar o que é solicitado.

Muitos sistemas utilizam um diretório \url{/etc/rc.d/} contendo shell scripts de diferentes níveis de execução. O mínimo é um simples programa {\ttfamily rc}, mas pode ser mais simples copiar o {\ttfamily \cdx{inittab}} e o diretório \url{/etc/rc.d} de um sistema já existente, e suprimir os scripts no diretório {\ttfamily rc.d} para remover os processamentos não relevantes do ambiente de sistema em disquete.

{\ttfamily /bin e /sbin}

\nidx{diretório bin}
\nidx{diretório sbin}

O diretório {\ttfamily /bin}  é um lugar adequado para utilitários extras necessários à execução de atividades básicas. Utilitários como {\ttfamily ls}, {\ttfamily mv}, {\ttfamily cat} e {\ttfamily dd}.Veja o Apêndice \ref{listings} {(Listagem de exemplo de conteúdo do disco de inicialização)} para um exemplo da lista de arquivos que podem estar presentes nos diretórios {\ttfamily /bin} e {\ttfamily /sbin}. Ela não inclui nenhum utilitário requerido para restaurar cópias de segurança, tais como {\ttfamily cpio}, {\ttfamily tar} e {\ttfamily gzip}. Isso porque estes programas foram colocados em um disquete de utilitários em separado, visando economizar espaço no disquete de inicialização e raiz. Uma vez que o disquete de inicialização tenha sido carregado, ele é copiado para o disco em memória, deixando a unidade de disquetes livre para montar outro disquete, o disquete de utilitários. Normalmente montamos esse disquete como {\ttfamily /usr}.

A criação de um \idx{disquete de utilitários} é descrito na Seção \ref{utilitydisk} {(Construindo um disquete de utilitários)}. É desejável manter uma cópia da mesma versão dos utilitários de cópias de segurança usados para gerar as cópias de segurança disponíveis, não perdendo-se tempo assim tentando-se instalar versões que não podem ler as cópias geradas.

{\itshape Esteja seguro de incluir os seguintes programas:\/} {\ttfamily init}, {\ttfamily getty}
ou equivalente, {\ttfamily login}, {\ttfamily mount}, algum interpretador que possa executar os programas rc, e uma ligação de {\ttfamily sh} para o shell.

\ncdx{init}\ncdx{getty}\ncdx{login}\nidx{shells}

{\ttfamily /lib}

\nidx{diretório de bibliotecas (lib)}
\nidx{bibliotecas}

No diretório {\ttfamily /lib} deve-se colocar as bibliotecas compartilhadas e seus carregadores. Caso as bibliotecas necessárias não sejam encontradas no diretório {\ttfamily /lib}, o sistema não poderá ser iniciado. Com um pouco de sorte pode-se receber uma mensagem de erro dizendo a razão.

\ncdx{libc.so}
Praticamente todos os programas requerem no mínimo a biblioteca {\ttfamily libc},
{\ttfamily libc.so.{\itshape N\/}}, onde {\itshape N\/} é o número da versão corrente. Ao verificar o diretório {\ttfamily /lib}, {\ttfamily libc.so.5} é normalmente uma ligação simbólica para um arquivo com o número completo da versão.

\begin{tscreen}
\begin{verbatim}
% ls -l /lib/libc.so*
lrwxrwxrwx  1 root root      14 Nov  1 20:34 /lib/libc.so.5 -> libc.so.5.4.33*
-rwxr-xr-x  1 root root  573176 Jun 12 02:05 /lib/libc.so.5.4.33*
\end{verbatim}
\end{tscreen}


Neste caso, tem-se disponível o arquivo {\ttfamily libc.so.5.4.33}. Para encontrar outras bibliotecas deve-se verificar todos os binários necessários e checar as suas dependências com o comando {\ttfamily \cdx{ldd}} . Por exemplo:

\begin{verbatim}
        % ldd /sbin/mke2fs
                libext2fs.so.2 => /lib/libext2fs.so.2
                libcom_err.so.2 => /lib/libcom_err.so.2
                libuuid.so.1 => /lib/libuuid.so.1
                libc.so.5 => /lib/libc.so.5
\end{verbatim}


O arquivo apresentado na coluna da direita é necessário, tendo-se em mente que as bibliotecas listadas podem ser ligações simbólicas.

Em  {\ttfamily /lib} deve-se ainda incluir um carregador de bibliotecas.
\nidx{carregadores} O carregador será ou o  {\ttfamily ld.so} (para bibliotecas a.out)
ou {\ttfamily ld-linux.so} (para bibliotecas ELF).\nidx{ELF}\nidx{a.out} Caso não se esteja seguro do que será necessário, deve-se executar o comando {\ttfamily file} na biblioteca.  Por exemplo:

\begin{verbatim}
% file /lib/libc.so.5.4.33 /lib/libc.so.4.7.2
  /lib/libc.so.4.7.2: Linux/i386 demand-paged executable (QMAGIC), stripped
  /lib/libc.so.5.4.33: ELF 32-bit LSB shared object, Intel 386, version 1, stripped
\end{verbatim}


{\ttfamily QMAGIC} indica que {\ttfamily 4.7.2} é para bibliotecas a.out, e 
{\ttfamily ELF} indica que {\ttfamily 5.4.33} é para ELF.\nidx{ELF}\nidx{a.out}

Deve-se então copiar o(s) carregador(es) necessário(s) para o sistema de arquivos raiz em construção. Bibliotecas e carregadores devem ser checados {\itshape cuidadosamente\/} com o binários incluídos. Caso o kernel não possa carregar a biblioteca necessária, normalmente haverá um travamento sem mensagens de erro.




\subsection{Módulos}

\nidx{módulos}

Caso se tenha um kernel modular, deve-se considerar quais módulos devem ser carregados a partir do disco de inicialização após o início do sistema. Pode-se incluir os módulos {\ttfamily ftape} e {\ttfamily zftape} caso cópias de segurança tenham sido feitas em um fita, módulos para dispositivos SCSI caso eles estejam presentes, e módulos para suporte a PPP ou SLIP caso se queira acesso a rede em uma emergência. \ncdx{ftape}

Estes módulos podem ser colocados em \url{/lib/modules}. Deve-se ainda incluir  {\ttfamily insmod}, {\ttfamily rmmod} e {\ttfamily lsmod}.

Caso se deseje carregar os módulos automaticamente, pode-se incluir ainda {\ttfamily modprobe}, {\ttfamily depmod} e {\ttfamily swapout}.  E caso se use o {\ttfamily kerneld}, deve-se incluir ainda o  \url{/etc/conf.modules}.

A principal vantagem de utilizar módulos reside no fato de poder mover módulos não essenciais para um disco de utilitários e carregá-los quando necessário, usando menos espaço no disco raiz. Porém, caso seja necessário lidar com muitos dispositivos diferentes, uma abordagem mais adequada pode  residir em construir um único kernel com diversos módulos integrados.
\nidx{disquete de utilitários}

{\itshape Note que para se ter um sistema de arquivos ext2 compactado, é obrigatória a existência de suporte a disco em memória e  sistemas de arquivos ext2\/}. Estes não podem ser disponibilizados como módulos.






\subsection{Alguns detalhes finais}



Alguns programas de sistema, como o  {\ttfamily login}, apresentam mensagem de advertência caso o arquivo \url{/var/run/utmp} e o diretório  \url{/var/log} não existam.\ncdx{utmp} Então:

\begin{verbatim}
        mkdir -p /mnt/var/{log,run}
        touch /mnt/var/run/utmp
\end{verbatim}


Finalmente, após ter-se configurado todas as bibliotecas necessárias, deve-se executar o {\ttfamily ldconfig}  para gerar novamente o  \url{/etc/ld.so.cache} no sistema de arquivos raiz. O cache diz ao carregador onde encontrar as bibliotecas. Para reconstruir  o {\ttfamily ld.so.cache}, execute os seguintes comandos:\ncdx{ldconfig}\ncdx{ld.so.cache}

\begin{verbatim}
        chdir /mnt; chroot /mnt /sbin/ldconfig
\end{verbatim}


O comando {\ttfamily chroot}  é necessário porque  {\ttfamily ldconfig}  sempre gera o cache para o sistema de arquivos raiz.




\subsection{Empacotando}

\label{empacotando}

Uma vez concluída a construção do sistema de arquivos raiz, ele deve ser desmontado, copiado para um arquivo e compactado:

\begin{verbatim}
        umount /mnt
        dd if=DISPOSITIVO bs=1k | gzip -v9 > saraiz.gz
\end{verbatim}


Isso pode levar diversos minutos. Ao finalizar estará disponível um arquivo {\ttfamily saraiz.gz}  que é o sistema de arquivos raiz compactado. Deve-se verificar se o arquivo cabe em um disquete. Caso não caiba, deve-se retornar aos passos anteriores e eliminar alguns arquivos. A Seção \ref{slimfast} {(Reduzindo o tamanho de um sistema de arquivos raiz)} fornece algumas dicas sobre a redução de tamanho do sistema de arquivos raiz.






\section{Escolhendo um kernel}

\nidx{kernel, escolhendo}

Neste ponto tem-se disponível um sistema de arquivos raiz compactado. O próximo passo é construir um kernel ou selecionar um kernel. Em muitos casos é possível copiar o kernel atual e inicializar o sistema a partir do disquete. Porém em muitos casos poderá ser necessário construir um em separado.

Uma das razões é o tamanho. Caso se esteja construindo um único disquete de inicialização e raiz, o kernel será um dos maiores arquivos no disquete e será necessário reduzí-lo o máximo possível. Caso se esteja construindo dois discos (um de inicialização e um raiz), isso não será problema pois o kernel irá em um disquete separado.

Para reduzir seu tamanho, deve-se construir um kernel com o mínimo de facilidades necessárias ao suporte do sistema desejado. Isso significa, deixar de lado tudo que não seja absolutamente necessário. Suporte a rede é um dos prováveis candidatos, assim como suporte a unidades de disco e outros dispositivos desnecessários durante o início do sistema. Conforme descrito anteriormente, o kernel  {\itshape deve\/} ter suporte a disco em memória e ext2 .

Após incluir somente o mínimo necessário de facilidades no kernel, deve-se verificar o que deve retornar. Provavelmente um dos usos mais comuns a um disquete de inicialização e raiz é a restauração de sistemas de arquivos raiz com problemas, e para que isso seja possível é necessário suporte no kernel do sistema. Por exemplo, caso as cópias de segurança tenham sido efetuadas em fita, utilizando Ftape para acessar uma unidade de fita,  então será obrigatória a presença de suporte a dispositivos de fitas para efetuar uma restauração. Caso não esteja presente, poderá ser necessário reinstalar o Linux, copiar e reinstalar \cdx{ftape}, e então tentar  ler as cópias de segurança.

O ponto aqui é, qualquer suporte a leitura e gravação que seja adicionado ao kernel para suportar cópias de segurança, deve também ser adicionado ao kernel de inicialização do sistema em disquete de emergência.

\nidx{kernel, construindo do fonte}

O procedimento para construir um kernel é descrito na documentação que o acompanha. É relativamente simples, podendo-se verificar o conteúdo de  \url{/usr/src/linux}.  Note que caso se tenha problemas construindo um novo kernel, então provavelmente não se deve tentar construir um disco de inicialização. Deve-se lembrar de compactar o kernel  através do comando ``{\ttfamily make zImage}''.




\section{Colocando tudo junto: Construindo o(s) disco(s)}



Neste ponto, tem-se um kernel e um sistema de arquivos raiz. Caso se esteja construindo um único disco de inicialização e raiz, deve-se verificar o seu tamanho e estar seguro de que eles caberão em um único disco. Caso se esteja construindo dois discos, deve-se verificar se o sistema de arquivos cabe em um único disquete.

Deve-se decidir pelo uso ou não do LILO no disquete de inicialização do kernel. A alternativa será copiar o kernel diretamente no disquete e iniciar o sistema sem o \cdx{LILO}.  A vantagem de utilizar o LILO reside na possibilidade de passagens de parâmetros para o kernel, o que pode ser necessário para inicializar algum hardware (deve-se verificar o conteúdo do arquivo \url{/etc/lilo.conf}.  Caso exista alguma linha do tipo ``{\ttfamily append=...}'', provavelmente esta facilidade será necessária). A desvantagem de usar o LILO é que a construção do disco de inicialização torna-se mais complexa e  mais espaço é necessário. Deve-se construir um pequeno sistema de arquivos em separado, o qual nós denominamos {\bfseries sistema de arquivos do kernel}, para onde se pode transferir o kernel e algumas outras coisas necessárias para o LILO.

\ncdx{lilo.conf}\nidx{sistema de arquivos lilo}\nidx{kernel, parâmetros}

Caso se vá utilizar o LILO, siga adiante, caso contrário pode-se ir diretamente para a seção  \ref{semlilo} {(Transferindo o kernel sem o LILO)}.




\subsection{Transferindo o kernel com o  LILO\ncdx{LILO}}

\label{usandolilo}

O primeiro item que deve ser criado é um pequeno arquivo de configuração do LILO. Ele deve ser similar ao seguinte:

\par
\addvspace{\medskipamount}
\nopagebreak\hrule
\begin{verbatim}
        boot      =/dev/fd0
        install   =/boot/boot.b
        map       =/boot/map
        read-write
        backup    =/dev/null
        compact
        image     = KERNEL
        label     = Disquete_Inic
        root      =/dev/fd0
\end{verbatim} 
\nopagebreak\hrule 
\addvspace{\medskipamount}


Para opter detalhes destes parâmetros, por favor verifique a documentação de usuário do LILO. Pode ser desejável ainda adicionar a linha {\ttfamily append=...}  copiada do arquivo \url{/etc/lilo.conf} existente em disco.\ncdx{lilo.conf}

Deve-se salvar o arquivo como  {\ttfamily bdlilo.conf} e a seguir criar um pequeno sistema de arquivos, o qual será denominado 
{\bfseries \idx{sistema de arquivos do kernel}},  para distingui-lo do sistema de arquivos raiz.

Inicialmente, deve-se verificar o tamanho que o sistema de arquivos terá. Verifique o tamanho do kernel em blocos (o tamanho é mostrado através do comando ``{\ttfamily ls -l KERNEL}''  dividido por 1024 e arredondado para cima) e acrescido de 50, referentes ao espaço necessário aos inodes e outros arquivos. Pode-se calcular o número exato ou simplesmente utilizar 50. Caso se esteja criando um conjunto com dois disquetes, pode-se superestimar o espaço usado pelo kernel. Denominaremos este número de {\ttfamily NÚCLEO\_BLOCOS}.\ncdx{NÚCLEO\_BLOCOS}

Deve-se colocar um disquete no dispositivo (para simplificar assumiremos que será em  \url{/dev/fd0}) e após criar um sistema de arquivos tipo ext2 para o kernel:

\begin{verbatim}
        mke2fs -i 8192 -m 0 /dev/fd0 NÚCLEO_BLOCOS
\end{verbatim}


\nidx{inodes, alocação}

O parâmetro ``{\ttfamily -i 8192}'' especifica que desejamos um inode para cada 8192 bytes. Após, deve-se montar o sistema de arquivos, remover o diretório {\ttfamily lost+found} e criar os diretórios {\ttfamily dev} e {\ttfamily boot} para o  LILO:

\begin{verbatim}
        mount /dev/fd0 /mnt
        rm -rf /mnt/lost+found
        mkdir /mnt/{boot,dev}
\end{verbatim}


Após, deve-se criar os dispositivos \url{/dev/null} e \url{/dev/fd0}. Ao invés de procurar pelos números dos dispositivos, pode-se simplesmente copiá-lo do disco rígido utilizando-se {\ttfamily -R}:

\begin{verbatim}
        cp -R /dev/{null,fd0} /mnt/dev
\end{verbatim}


LILO necessita de uma cópia de seu  carregador de inicialização, {\ttfamily boot.b},  o qual pode ser encontrado no disco rígido, normalmente no diretório  {\ttfamily /boot} .

\begin{verbatim}
        cp /boot/boot.b /mnt/boot
\end{verbatim}


Finalmente, deve-se copiar os arquivos de configuração do LILO criado conforme a seção anterior, assim como o kernel. Ambos devem estar presentes no diretório raiz:

\begin{verbatim}
        cp bdlilo.conf KERNEL /mnt
\end{verbatim}


Todo o necessário para que o LILO possa ser executado está presente no sistema de arquivos do kernel. Deve-se então executar o   LILO com o parâmetro {\ttfamily -r}  para instalar o carregador de inicialização : \ncdx{LILO}

\begin{verbatim}
        lilo -v -C bdlilo.conf -r /mnt
\end{verbatim}


LILO deverá ser executado sem erros, após o qual o sistema de arquivos do kernel deve ter a seguinte aparência: 
\nidx{sistema de arquivos do kernel}

\par
\addvspace{\medskipamount}
\nopagebreak\hrule
\begin{verbatim}
total 361
  1 -rw-r--r--   1 root     root          176 Jan 10 07:22 bdlilo.conf
  1 drwxr-xr-x   2 root     root         1024 Jan 10 07:23 boot/
  1 drwxr-xr-x   2 root     root         1024 Jan 10 07:22 dev/
358 -rw-r--r--   1 root     root       362707 Jan 10 07:23 vmlinuz
boot:
total 8
  4 -rw-r--r--   1 root     root         3708 Jan 10 07:22 boot.b
  4 -rw-------   1 root     root         3584 Jan 10 07:23 map
dev:
total 0
  0 brw-r-----   1 root     root       2,   0 Jan 10 07:22 fd0
  0 crw-r--r--   1 root     root       1,   3 Jan 10 07:22 null
\end{verbatim} 
\nopagebreak\hrule 
\addvspace{\medskipamount}


Não há motivos para preocupação caso os tamanhos de arquivos sejam um pouco diferentes.

Pode-se ir agora para a seção \ref{ramdiskword} {(Configurando o disco em memória)}.




\subsection{Transferindo o kernel sem o LILO}

\label{semlilo}

Caso  {\itshape não\/}  se esteja utilizando o LILO, o kernel pode ser transferido para o disco de inicialização com o comando {\ttfamily dd} :

\begin{verbatim}
        % dd if=KERNEL of=/dev/fd0 bs=1k
        353+1 records in
        353+1 records out
\end{verbatim}


Neste exemplo, {\ttfamily dd}  gravou 353 registros completos e 1 parcialmente, concluindo-se que o kernel ocupou 354 blocos do disquete. Denominaremos este número como {\ttfamily NÚCLEO\_BLOCOS} , o qual será utilizado na próxima seção.\ncdx{NÚCLEO\_BLOCOS}

Finalmente, deve-se configurar o disquete como o dispositivo raiz e dar-lhe permissões de leitura e gravação:

\begin{verbatim}
        rdev /dev/fd0 /dev/fd0
        rdev -R /dev/fd0 0
\end{verbatim}


\ncdx{rdev}

Deve-se ter o máximo cuidado ao usar o {\ttfamily -R} maiúsculo no comando  {\ttfamily rdev} .






\subsection{Configurando o disco em memória}

\label{ramdiskword}

Dentro da imagem do kernel está a  {\bfseries \idx{palavra (dois ou mais bytes) de configuração do disco em memória}} que especifica onde o sistema de arquivos raiz deve ser encontrado, em conjunto com as suas opções. A palavra  é definida em  \url{/usr/src/linux/arch/i386/kernel/setup.c} e é interpretada da seguinte forma:

\begin{verbatim}
bits  0-10:     deslocamento para início da memória, em blocos de 1024 bytes
bits 11-13:     sem utilização
bit     14:     Indicador se o disco em memória deve ser carregado
bit     15:     Indicador de prompt antes da carga do sistema de arquivos raiz
\end{verbatim}


Caso o bit 15 esteja configurado, no processo de inicialização será solicitada a inserção de um novo disquete na unidade. Isso é necessário no caso de conjuntos de dois disquetes de inicialização.

Há dois casos, dependendo da construção de um único disquete ou de um conjunto de dois disquetes (inicialização e raiz).

\begin{enumerate}
\item  Caso se esteja construindo um único disco, o sistema de arquivos raiz será colocado exatamente após o kernel, sendo o deslocamento então igual ao primeiro bloco livre (o que deve ser igual a  {\ttfamily NÚCLEO\_BLOCOS}).  O bit 14 será configurado com 1 e o bit 15 com zeros.\ncdx{NÚCLEO\_BLOCOS}
\item Caso se esteja construindo um conjunto de dois disquetes, o sistema de arquivos raiz começará no bloco zero e o deslocamento será igual a zero. Bit 14 será igual a 1 e o bit 15 também será igual a 1.
\end{enumerate}

Após calcular cuidadosamente o valor da palavra de disco em memória, deve-se configurá-la com  {\ttfamily rdev -r}.\ncdx{rdev}\nidx{palavra disco em memória} Esteja seguro de utilizar valores  {\itshape decimais\/}. Caso se esteja utilizando o LILO, o argumento  {\ttfamily rdev}  deve ser igual  ao {\itshape caminho do kernel\/}, por exemplo {\ttfamily /mnt/vmlinuz}; caso o kernel tenha sido copiado com {\ttfamily dd}, deve-se usar o nome do dispositivo de disquetes ({\itshape por exemplo,\/}{\ttfamily /dev/fd0}).

\begin{verbatim}
        rdev -r NÚCLEO_OU_UNIDADE_ DE _DISQUETE
\end{verbatim}


Caso se esteja utilizando o LILO, a unidade de disquetes deve ser desmontada agora.




\subsection{Transferindo o sistema de arquivos raiz}



O último passo é a transferência do sistema de arquivos raiz.

\begin{itemize}
\item Caso o sistema de arquivos raiz seja colocado no  {\itshape mesmo\/} disco que o kernel, a transferência deve ser efetuada utilizando-se o comando {\ttfamily dd} com a opção {\ttfamily seek},  a qual especifica quantos blocos devem ser ignorados até que a gravação tenha início:

\begin{verbatim}
        dd if=rootfs.gz of=/dev/fd0 bs=1k seek=BLOCOS_NÚCLEO
\end{verbatim}

\item Caso o sistema de arquivos raiz seja colocado em um  {\itshape segundo\/} disco, deve-se remover o primeiro disquete e colocar o segundo na unidade, transferindo-se o sistema de arquivos raiz:

\begin{verbatim}
        dd if=rootfs.gz of=/dev/fd0 bs=1k
\end{verbatim}

\end{itemize}


Parabéns, serviço concluído!

{\bfseries DEVE-SE SEMPRE TESTAR UM DISCO DE INICIALIZAÇÃO ANTES DE GUARDÁ-LO, PARA USO EM UMA EMERGÊNCIA}




\section{Problemas}

\label{problemas}
\nidx{problemas}

Na construção de discos de inicialização, as primeiras tentativas normalmente gerarão discos com problemas. A abordagem de construção de um disco raiz é montar seus componentes a partir de um sistema já existente e tentar construir um disquete baseado nele  que viabilize a  carga do sistema até o momento em que mensagens possam ser apresentadas na console. Após esse passo, cabe verificar as mensagens e os erros apresentados, e ir corrigindo um a  um, de acordo com o apresentado no console. Caso o sistema simplesmente trave, sem maiores explicações, encontrar a causa será um pouco mais difícil. Para ter-se um sistema que possa chegar ao estágio de enviar mensagens para o console, são requeridos diversos componentes, que devem estar presentes e corretamente configurados. O procedimento recomendado na investigação de um problema onde o sistema não apresente a sua causa é o seguinte:
\begin{itemize}
\item Verificar se o disco raiz contém realmente os diretórios necessários. É comum copiar de níveis errados e ter algo como  \url{/discoraiz/bin} ao invés de  {\ttfamily /bin} no disquete.
\item Verificar se existe \url{/lib/libc.so} com a mesma ligação que aparece no diretório {\ttfamily /lib} do disco rígido. \ncdx{libc.so}
\item Verificar se todas as  ligações simbólicas no diretório  {\ttfamily /dev} existem  no sistema de arquivos raiz do disquete, onde aquelas ligações devem ser para dispositivos que estão inclusos no disco raiz. Em particular, ligações para {\ttfamily /dev/console} são fundamentais em diversos casos. \nidx{diretórios de dispositivos (dev)}
\item Verificar se os arquivos {\ttfamily /dev/tty1, /dev/null, /dev/zero,
/dev/mem, /dev/ram} e {\ttfamily /dev/kmem} foram incluídos.
\item Verificar se a configuração do kernel suporta todos os recursos requeridos até o momento de acesso ao sistema e se estão adicionados ao kernel de forma residente e não como módulos.  {\itshape Suporte a discos em memória e ext2 devem estar residentes\/}.
\item Verificar se as configurações do dispositivo  raiz e do kernel e o disco em memória estão corretas.
\end{itemize}


Alguns deste aspectos gerais são melhor detalhados a seguir:

\begin{enumerate}
\item Esteja certo de que  {\ttfamily init} foi incluído como  \url{/sbin/init} ou \url{/bin/init} e  que tem permissão de execução.\ncdx{init}
\item Execute  {\ttfamily ldd init} para checar as bibliotecas necessárias à execução do init. Normalmente é necessária somente {\ttfamily libc.so}. Esteja certo de que todas as bibliotecas e carregadores foram incluídos.
\item Esteja certo de utilizar o carregador correto para as bibliotecas --- {\ttfamily ld.so} para a.out ou {\ttfamily ld-linux.so} para ELF.\nidx{carregadores}
\item Verificar se o arquivo \url{/etc/inittab} no sistema de arquivos do disquete de inicialização, aponta para o programa {\ttfamily getty} (ou algum programa similar a  {\ttfamily getty}, como por exemplo {\ttfamily agetty}, {\ttfamily mgetty} ou
{\ttfamily getty\_ps}).\ncdx{inittab}\ncdx{getty} Cheque duplamente esse arquivo comparando-o com o disponível no disco rígido. Verifique as páginas do manual do programa que está sendo utilizado para estar seguro que a configuração está correta. {\ttfamily inittab}  é possivelmente a parte mais repleta de detalhes devido à sua sintaxe e o seu conteúdo depende do programa usado no sistema. A única forma de não correr riscos é ler as páginas de manual do  {\ttfamily init} e {\ttfamily inittab}   e verificar exatamente o que o sistema está fazendo ao ser iniciado. Esteja seguro que  \url{/etc/inittab} tem uma entrada de inicialização no sistema. Deve haver um comando de execução do programa de inicialização do sistema, o qual deve existir.
\item Assim como realizado com  {\ttfamily init}, execute {\ttfamily ldd} em {\ttfamily \cdx{getty}} para verificar as dependências, esteja certo de que as bibliotecas necessárias e carregadores estão presentes no sistema de arquivos raiz.
\item Esteja seguro de ter incluído um shell script (por exemplo, {\ttfamily bash} ou {\ttfamily ash}), capaz de executar todos os programas rc .\nidx{interpretador de comandos}
\item Caso se tenha um arquivo  \url{/etc/ld.so.cache} no disco de emergência, refaça-o. \ncdx{ld.so.cache}
\end{enumerate}




Caso {\ttfamily init} comece, mas seja obtida a seguinte mensagem:
\begin{verbatim}
        Id xxx respawning too fast: disabled for 5 minutes
\end{verbatim}


\ncdx{retransmitindo muito rápido}
ela é oriunda do {\ttfamily init}, normalmente indicando que  os programas {\ttfamily getty} ou {\ttfamily login} estão sendo encerrados imediatamente após o seu início. \ncdx{init}\ncdx{getty}\ncdx{login} Verifique os executáveis {\ttfamily getty} e  {\ttfamily login} e as bibliotecas necessárias. Esteja seguro que as chamadas em \url{/etc/inittab} estão corretas. Caso mensagens estranhas apareçam a partir do {\ttfamily getty}, pode significar que a chamada em  \url{/etc/inittab} está errada. As opções disponíveis em  {\itshape getty\/}  variam bastante; assim como diferentes versões do  {\ttfamily agetty} podem ter incompatibilidades na sintaxe das chamadas.\ncdx{inittab}

Caso ao se tentar executar algum programa, tal como  {\ttfamily df},  presente no disco de emergência, e obtêm-se mensagens como: {\ttfamily df: não encontrado}, deve-se verificar: (1) o diretório que contém o comando está configurado na variável de ambiente PATH, e (2) todas as bibliotecas e carregadores necessários ao programa estão presentes.






\section{Diversos}






\subsection{Reduzindo o tamanho do sistema de arquivos raiz}

\label{slimfast}

Algumas vezes o sistema de arquivos raiz é muito grande para caber em um disquete, mesmo após a sua compactação. Seguem algumas formas de reduzir seu tamanho, listadas em ordem decrescente de efetividade:

\begin{description}


\item[Aumentar a densidade do disco] \mbox{}

Por padrão, disquetes são formatados em 1400K, mas  formatos de maior densidade estão disponíveis. \url{fdformat} poderá formatar nos seguintes tamanhos: 1600, 1680, 1722, 1743, 1760, 1840, e 1920. Muitos dispositivos de 1440K suportarão  1722K, e é este que sempre usamos para disquetes de inicialização. A página de manual \url{fdformat} e  o arquivo \url{/usr/src/linux/Documentation/devices.txt} fornecem maiores informações sobre o tema.



\item[Alterar o interpretador de comandos] \mbox{}

Alguns dos mais populares interpretadores de comando para Linux, como  {\ttfamily bash} e {\ttfamily tcsh}, são grandes e requerem diversas bibliotecas.\nidx{interpretador de comandos} Alternativas mais leves existem, tais como {\ttfamily ash}, {\ttfamily lsh}, {\ttfamily kiss} e {\ttfamily smash}, os quais são muito menores e requerem menos (ou nenhuma) bibliotecas. Muitos dos interpretadores alternativos estão disponíveis em \nameurl{http://sunsite.unc.edu/pub/Linux/system/shells/}{}. Esteja certo porém de que o interpretador seja capaz de executar todos os comandos e programas configurados nos arquivos  {\ttfamily rc} incluídos no disco de inicialização.



\item[Diminuir as bibliotecas e os binários] \mbox{}

\nidx{bibliotecas}Muitas bibliotecas e binários estão tipicamente com todos os símbolos de depuração inclusos, o que aumenta seu tamanho. Executando-se '{\ttfamily file}' nestes arquivos , ele apresentará a mensagem  '{\ttfamily not stripped}' caso essa afirmativa seja verdadeira. Ao copiar binários para o seu sistema de arquivos raiz, é aconselhável utilizar:

\begin{verbatim}
        objcopy --strip-all FROM TO
\end{verbatim}


\ncdx{strip}\ncdx{objcopy}\nidx{bibliotecas, diminuindo tamanho}
Ao copiar bibliotecas deve ser usado:

\begin{verbatim}
        objcopy --strip-debug FROM TO
\end{verbatim}




\item[Mover arquivos não críticos para um disco de utilitários] \mbox{}

Caso alguns binários não sejam necessários durante a inicialização ou no acesso ao sistema, eles podem ser movidos para um disquete adicional. Veja a Seção \ref{utilitydisk} {(Construindo um disquete de utilitários)} para maiores detalhes. Deve-se ainda considerar também a movimentação de módulos. \nidx{disquete de utilitários}



\end{description}





\subsection{Sistemas de arquivos raiz não residentes em discos na memória}

\label{nonramdiskroot}
\nidx{disco em memória}

A Seção \ref{buildroot} {(Construindo um sistema de arquivos raiz)} apresenta instruções sobre como construir um sistema de arquivos raiz compactado o qual é carregado em um disco em memória quando o sistema é iniciado. Este método tem diversas vantagens e é o mais comumente utilizado. De qualquer forma, alguns sistemas com pouca memória podem não suportar toda a RAM necessária para isso; e nestes casos o sistema de arquivos raiz é montado diretamente ao invés de ser copiado para um disco em memória.

Tais sistemas de arquivos são na verdade mais simples de serem construídos do que sistemas compactados, uma vez que eles podem ser construídos tanto em disquetes como em qualquer outro dispositivo, e não têm que ser compactados. Apresentaremos os procedimentos necessários e as suas diferenças em relação ao descrito até aqui. Caso seja esta a sua opção, deve-se ter em mente que se terá {\itshape  muito menos espaço \/} disponível.

\begin{enumerate}
\item Calcular o espaço disponível para os arquivos do sistema de arquivos raiz.

Caso se esteja construindo um único disco de inicialização e raiz, todos os blocos do kernel mais os do sistema de arquivos raiz devem caber em um disquete.
\item Utilizar o programa  {\ttfamily mke2fs}, para criar um sistema de arquivos raiz em um disquete com o tamanho apropriado.
\item Incluir os arquivos do sistema de arquivos conforme descrito acima.
\item Ao finalizar, desmontar o sistema de arquivos e transferi-lo para um arquivo de disco, {\itshape sem compactação\/}.
\item Transferir o kernel para um disquete, conforme descrito anteriormente. Ao calcular a palavra do disco em memória, {\bfseries configurar o bit 14 para zero}, para indicar que o sistema de arquivos raiz não será carregado para um disco em memória. Executar o comando  {\ttfamily rdev} conforme descrito.\ncdx{rdev}\nidx{palavra de disco em memória}
\item Transferir o sistema de arquivos raiz conforme descrito anteriormente.
\end{enumerate}

Há diversos atalhos que podem ser executados. Caso se esteja construindo um conjunto de dois disquetes, pode-se construir o sistema de arquivos raiz diretamente no segundo disquete, não sendo necessário transferi-lo para o disco rígido e após para o disquete novamente. Ainda, caso se esteja construindo um único disquete de raiz e inicialização utilizando-se o LILO, pode-se construir  um {\itshape único\/} sistema de arquivos no disco inteiro, contendo o kernel, arquivos do LILO e do raiz, e simplesmente executar o LILO como o último passo.






\subsection{Construindo um disquete de utilitários}

\label{utilitydisk}
\nidx{disquete de utilitários}

Construir um disquete de utilitários é bastante simples, basta simplesmente criar um sistema de arquivos em um disquete formatado e copiar os arquivos para ele. Para usá-lo com o disco de inicialização, deve-se montá-lo manualmente após o sistema ser carregado.

Conforme descrito anteriormente, o disquete de utilitários  pode ser montado como {\ttfamily /usr}.  Neste caso, os binários podem ser colocados no diretório {\ttfamily /bin} no disquete de utilitários, sendo que uma indicação a \url{/usr/bin} na variável de ambiente de caminho permitirá o acesso direto a eles. Bibliotecas adicionais podem ser colocadas no diretório  {\ttfamily /lib} no disquete de utilitários.

Há vários pontos importantes  para atentar-se ao se construir um disco de utilitários, a saber:

\begin{enumerate}
\item {\itshape Não\/} colocar binários ou bibliotecas que sejam críticos para o início do sistema, uma vez que o disquete não será montado antes da inicialização do sistema.
\item  Não é possível acessar uma unidade de disquete e uma unidade de fita simultaneamente. Isso significa que caso se tenha uma unidade de fita, não será possível acessá-la enquanto o disco de utilitários estiver montado.
\item O acesso aos arquivos no disco de utilitários será lento.
\end{enumerate}




Apêndice \ref{utilitylist} {(Listas de exemplo do conteúdo do disco de utilitários)} mostra um lista de exemplo de arquivos em um disquete de utilitários. Aqui estão colocadas algumas idéias que podem ser úteis: programas para examinar e manipular discos ( ({\ttfamily format, fdisk}) e sistemas de arquivos ({\ttfamily mke2fs, fsck, isofs.o}), um editor de textos leve ({\ttfamily elvis, jove}), utilitários de compactação e arquivamento ({\ttfamily gzip, tar, cpio, afio}), utilitários para fitas ({\ttfamily mt, tob, taper}), comunicação ({\ttfamily ppp.o, slip.o, minicom}) e dispositivos ({\ttfamily setserial, mknod}).




\section{Como os profissionais fazem isso}

\label{pros}

É possível perceber que os discos de inicialização das maiores distribuições, tais como Conectiva Linux, Red Hat, Slackware ou Debian, parecem ser mais sofisticados do que o descrito neste documento. Discos de inicialização de distribuições profissionais são baseados nos mesmos princípios aqui descritos, mas empregam alguns detalhes adicionais, uma vez que devem atender a um número maior de sistemas e situações. Inicialmente, eles devem ser capazes de funcionar com uma grande variedade de hardwares, sendo necessário então interagir com o usuário e carregar diversos arquivos de dispositivos. Segundo, eles devem ser preparados para trabalhar com diversas opções de instalação, com diferentes níveis de automação. Finalmente, distribuições normalmente combinam  funcionalidades de instalação e emergências.

Alguns discos de inicialização contém uma funcionalidade chamada  {\bfseries initrd} ({\bfseries disco em memória inicial}).\nidx{disco em memória inicial (initrd)} Esta funcionalidade foi introduzida com a versão 2.0.X e provê grande flexibilidade, permitindo que o kernel seja carregado em duas fases. Quando o kernel é inicializado, ele inicialmente carrega uma imagem do disco em memória a partir do disquete de inicialização. O disco em memória inicial é um sistema de arquivos raiz contendo um programa que é executado antes que o raiz verdadeiro seja carregado. Este programa normalmente inspeciona o ambiente e solicita que o usuário selecione entre diversas opções de inicialização, tais como o real dispositivo que deve ser utilizado para a carga do sistema de arquivos raiz. Tipicamente ele carrega módulos adicionais não incluídos no kernel. Quando o programa inicial termina, o kernel carrega o raiz original e o processo de inicialização continua normalmente. Para maiores informações sobre o {\ttfamily initrd}, veja \url{/usr/src/linux/Documentation/initrd.txt} e
\nameurl{ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz}{}.

As informações a seguir são um resumo dos discos de instalação de cada uma das distribuições, baseado na inspeção de seus sistemas de arquivos e dos códigos fontes. Não podemos garantir a exata acuidade das informações aqui descritas, ou se elas forem alteradas em novas versões.



Slackware (v.3.1) usa uma inicialização similar a um LILO descrito na seção \ref{usandolilo} {(Transferindo o kernel com o  LILO)}.  O disco de inicialização do Slackware apresenta uma mensagem (``{\ttfamily Bem-vindo ao disco de inicialização do kernel do Slackware Linux!}'') usando o parâmetro {\ttfamily message} do LILO. Após, o usuário é instruído a entrar com os parâmetros de inicialização, se necessários. Após a inicialização, um sistema de arquivos raiz é carregado de um segundo disco. O usuário executa o programa {\ttfamily setup}  que inicia a instalação. Ao invés de usar um kernel modular, Slackware provê uma série de diferentes kernels e depende do usuário a escolha do mais adequado aos seus requisitos de hardware.

RedHat (v.4.0)  também utiliza a inicialização do LILO. Ele carrega um disco em memória compactado a partir do primeiro disco, o qual executa um programa  {\ttfamily init} customizado. Este programa solicita os arquivos de controle de dispositivos e carrega-os de um disco suplementar quando necessário.

Debian (v.1.3) é provavelmente o mais sofisticado disco de instalação. Ele utiliza o carregador SYSLINUX para permitir várias opções de inicialização, usando então uma imagem do  {\ttfamily \cdx{initrd}} para guiar o usuário pelo processo de instalação. Aparenta usar tanto um  {\ttfamily init} quanto um interpretador customizados.






\section{Lista das Perguntas Mais Frequentes (FAQ)}



{\bfseries Q. Eu carrego meus discos de inicialização e raiz e nada acontece. O que posso fazer?}

Veja a Seção \ref{problemas} {(Problemas)}.

{\bfseries Q. Como o disco de inicialização da Conectiva/Red Hat/Slackware/Debian funcionam?}

Veja a Seção \ref{pros} {(Como os profisisonais fazem isso)}.

{\bfseries Q. Como eu posso construir um disquete de inicialização com o arquivo de controle de dispositivos XYZ?}

A forma mais simples é obter um kernel do Slackware em um site espelho mais próximo. Os kernels do Slackware são genéricos e tentam incluir arquivos de controle para o maior número de dispositivos possível. Então caso se tenha uma controladora IDE ou SCSI, as chances são grandes de se ter um arquivo de controle para elas em um kernel do Slackware.
Vá para o diretório  {\ttfamily a1}  e selecione IDE ou SCSI dependendo do tipo de controladora que se tenha. Verifique o arquivo xxxxkern.cfg do kernel  selecionado para ver os arquivos de controle que foram incluídos neste kernel. Caso o dispositivo que se deseje instalar esteja incluído na lista, então o kernel correspondente deve inicializar o seu computador. Transfira o arquivo  xxxxkern.tgz e copie para o seu disquete de inicialização conforme descrito acima, na seção de construção de discos de inicialização. \nidx{arquivos de controles de dispositivos, device drivers}

Deve-se checar o dispositivo raiz no kernel usando-se o comando rdev:
\begin{verbatim}
        rdev zImage
\end{verbatim}


{\ttfamily rdev} mostrará o dispositivo raiz atual do kernel. Caso este não seja o mesmo desejado, deve-se usar o  {\ttfamily rdev} para alterá-lo.
Por exemplo, um kernel testado apontava para \url{/dev/sda2}, porém a partição raiz SCSI era \url{/dev/sda8}. Para usar um disquete raiz, deve-se utilizar o comando:

\begin{verbatim}
        rdev zImage /dev/fd0
\end{verbatim}


Caso se queira saber como configurar um disquete de inicialização do Slackware, sugere-se verificar o Guia de Instalação Linux ou obter uma distribuição Slackware. Veja a seção denominada "Referências".

{\bfseries Q. Como atualizar um disco de inicialização com um novo kernel?}

\nidx{kernel, atualização}

Simplesmente copie o novo kernel em um disquete de inicialização utilizando o comando dd para um disquete sem sistema de arquivos, ou através do comando cp para um disco de inicialização e raiz. Verifique a seção denominada "inicialização" para detalhes sobre a criação de um disquete de inicialização.  A descrição aplica-se perfeitamente à atualização do kernel em um disquete de inicialização.

{\bfseries Q. Como atualizar o disquete raiz com novos arquivos?}

\nidx{sistema de arquivos raiz, atualização}

A maneira mais simples é copiar o sistema de arquivos do disco raiz de volta ao DISPOSITIVO utilizado, seção \ref{creatingrootfs} {(Criando um sistema de arquivos)}. Após monte o sistema de arquivos e faça as alterações necessárias. Deve-se lembrar sempre onde o sistema de arquivos começa e quantos blocos ele ocupa:

\begin{verbatim}
dd if=/dev/fd0 bs=1k skip=INÍCIO_RAIZ  count=BLOCOS | gunzip > DISPOSITIVO
mount -t ext2 DISPOSITIVO /mnt
\end{verbatim}


Após as alterações serem concluídas, proceda de acordo com a Seção \ref{empacotando} {(Empacotando)} e transfira o sistema de arquivos raiz de volta para o disco. Não se deve retransferir o kernel ou recalcular a palavra do disco em memória caso não tenha havido alterações do ponto de início do novo sistema de arquivos raiz.

{\bfseries Q. Como remover o LILO para ser possível utilizar a inicialização DOS novamente?}

\ncdx{LILO}
\nidx{Registro Master de Inicialização - Master Boot Record (MBR)}

No Linux pode-se executar:

\begin{tscreen}
\begin{verbatim}
        /sbin/lilo -u
\end{verbatim}
\end{tscreen}


Pode-se ainda usar o comando   {\ttfamily dd} para utilizar a cópia de segurança salva pelo LILO do setor de inicialização. Veja na documentação do LILO maiores informações.

No DOS ou Windows pode-se executar o seguinte comando DOS:
\begin{tscreen}
\begin{verbatim}
        FDISK /MBR
\end{verbatim}
\end{tscreen}


MBR significa Registro Master de Inicialização (Master Boot Record), e após o comando acima o setor de inicialização recebe registros DOS sem alterar a tabela de partições. Alguns puristas não concordam com essa abordagem, mas mesmo o autor do  LILO, Werner Almesberger, sugere isso, além de ser simples e funcional.

{\bfseries Q. Como inicializar o sistema se o kernel {\itshape e\/} o disco de inicialização foram perdidos?}

Caso não se tenha um disco de inicialização extra, provavelmente o método mais simples será obter um kernel do Slackware para a sua controladora de discos ((IDE ou SCSI) conforme descrito anteriormente em "Como construir um disco de inicialização com o arquivo de controle de dispositivos XYZ?". Pode-se iniciar o sistema com esse kernel e procurar reparar o que estiver danificado.

O kernel obtido pode não conter o tipo de disco e a partição que se deseje. Por exemplo, kernel genérico do Slackware para controladoras SCSI tem o dispositivo raiz configurado para \url{/dev/sda2},  e eventualmente a partição raiz pode estar em  \url{/dev/sda8}. Neste caso o dispositivo raiz do kernel deve ser alterado.

Pode-se mudar os parâmetros de dispositivo raiz e disco em memória no kernel, mesmo que tudo o que tenha seja um kernel ou mesmo a partir de outro sistema operacional, como por exemplo DOS.

{\ttfamily rdev} altera o kernel através de alterações de valores de deslocamentos fixos do arquivo do kernel, então pode-se utilizar um editor em hexadecimal  em qualquer sistema disponível, como por exemplo o Editor de Disco de Utilitários Norton sob DOS. Deve-se checar se é necessário mudar os valores do kernel nos seguintes deslocamentos:
\nidx{palavra do disco em memória rdevi}

\begin{tscreen}
\begin{verbatim}
HEX     DEC  DESCRIPTION
0x01F8  504  Byte inferior da palavra do disco em memória
0x01F9  505  Byte superior da palavra do disco em memória
0x01FC  508  Número menor do dispositivo raiz - vide abaixo
0X01FD  509  Número maior do dispositivo raiz - vide abaixo
\end{verbatim}
\end{tscreen}


A interpretação da palavra do disco em memória está descrita na seção \ref{ramdiskword} {(Configurando o disco em memória)}.

O número maior e menor do dispositivo devem ser configurados caso se deseje montar o sistema de arquivos raiz nele. Alguns valores importantes são:

\begin{tscreen}
\begin{verbatim}
DISPOSITIVO      MAJOR MINOR
/dev/fd0             2     0       primeira unidade de disquetes
/dev/hda1            3     1       partição 1 no primeiro disco IDE
/dev/sda1            8     1       partição 1 no primeiro disco SCSI
/dev/sda8            8     8       partição 8 no primeiro disco SCSI
\end{verbatim}
\end{tscreen}


Uma vez que estes valores estejam configurados, pode-se gravar o arquivo utilizando tanto o editor Norton, quanto um programa chamado {\ttfamily rawrite.exe}. Este programa é incluído em todas as distribuições, e é executado em ambientes DOS, sendo capaz de gravar os dados de forma direta, ao invés de gravar através do sistema de arquivos. Caso se utilize o Norton deve-se gravar o arquivo em um disco físico com início igual ao do disco de inicialização.

{\bfseries Q. Como fazer cópias adicionais dos disquetes de inicialização e raiz?}

Como a mídia magnética pode deteriorar-se com o tempo, deve-se manter diversas cópias dos discos de emergência, para as situações em que o original não funcione.

A forma mais simples de fazer cópias de qualquer disquete, inclusive disquetes que podem ser inicializados e disquetes de utilitários, é através da utilização do comando {\ttfamily dd}  para cópia do disquete original em um disco rígido e após o mesmo comando para copiar do disco rígido para os diversos disquetes.  Note que não se deve montar os disquetes, porque o comando  {\ttfamily dd}  utiliza o acesso direto ao dispositivo.

Para copiar o disquete original, execute o comando:
\begin{tscreen}
\begin{verbatim}
        dd if=NOME_DISPOSITIVO of=NOME_ARQUIVO
        onde NOME_DISPOSITIVO é o nome da unidade de disquetes
        e NOME_ARQUIVO é o nome do arquivo de saída (no disco rígido)
\end{verbatim}
\end{tscreen}


Omitindo-se o parâmetro  {\ttfamily count}  faz com que o comando copie todo o disquete (2880 blocos de alta densidade).

Para copiar o arquivo resultante para um novo disquete, deve-se inserir o disquete na unidade e executar o comando:

\begin{tscreen}
\begin{verbatim}
        dd if=NOME_ARQUIVO of=NOME_DISPOSITIVO
\end{verbatim}
\end{tscreen}


Note que o exemplo acima assume que se tenha somente uma unidade de gravação de disquetes. Caso se tenha duas de mesmo tipo, pode-se copiar o disquete usando-se o comando:

\begin{tscreen}
\begin{verbatim}
        dd if=/dev/fd0 of=/dev/fd1
\end{verbatim}
\end{tscreen}


{\bfseries Q. Como inicializar o sistema sem ter que digitar "ahaxxxx=nn,nn,nn" toda vez?}

\nidx{kernel, parâmetros}

Quando um dispositivo não pode ser detectado automáticamente, é necessário fornecer ao kernel os parâmetros através do comando de dispositivos, como por exemplo:
\begin{tscreen}
\begin{verbatim}
        aha152x=0x340,11,3,1
\end{verbatim}
\end{tscreen}

Este parâmetro pode ser fornecido pelo LILO de diversas formas:

\begin{itemize}
\item Informando o comando toda a vez que o sistema for inicializado via LILO. A opção  menos aconselhável.
\item Usando o parâmetro  ``{\ttfamily lock}'' para armazenar a linha de comando como a linha padrão de comando, fazendo com que o LILO use estas opções toda a vez que o sistema for carregado.
\item  Utilizando o parâmetro  {\ttfamily append=} no arquivo de configuração do LILO. Note que o parâmetro deve estar entre aspas.
\end{itemize}


Por exemplo, uma linha de comando usando os parâmetros acima poderia ser:
\begin{tscreen}
\begin{verbatim}
        zImage  aha152x=0x340,11,3,1 root=/dev/sda1 lock
\end{verbatim}
\end{tscreen}


Este comando passa os parâmetros do dispositivo,  configura o dispositivo raiz em \url{/dev/sda1} e salva todo o comando para reutilização futura.

Um exemplo de comando append:
\begin{tscreen}
\begin{verbatim}
        \{append} = "aha152x=0x340,11,3,1"
\end{verbatim}
\end{tscreen}


Note que o parâmetro não deve estar entre aspas na linha de comando, mas é obrigatório que assim esteja no comando append.

Note ainda que  para que o parâmetro seja ativado, o kernel deve conter o módulo para o dispositivo assinalado. Caso contrário,  o comando não surtirá efeito algum e o kernel deverá ser reconstruído para incluir o módulo requerido. Para maiores detalhes sobre a reconstrução do kernel, mude o diretório  para \url{/usr/src/linux} e veja o arquivo README, e leia o FAQ e o tutorial de instalação. Alternativamente pode-se obter um kernel genérico e instalá-lo.

É extremamente indicado a leitura da documentação LILO antes de se tentar instalá-lo. Usos indevidos do comando  {\ttfamily BOOT} podem causar danos às partições.

{\bfseries Q. Durante a inicialização  ocorreu o erro  "{\ttfamily A: não pode executar B}". Por quê?}

\nidx{localizações pré-definidas}

Há diversos casos em que nomes de programas encontram-se dentro do código de vários utilitários. Este casos não ocorrem em toda parte, mas pode ser uma explicação de porquê um executável aparentemente pode não ser encontrado, apesar de estar presente no sistema. Pode-se descobrir se um determinado programa tem o nome de outro dentro de seu código usando-se o comando {\ttfamily strings} e conectando sua saída com o comando {\ttfamily grep}.

Exemplos conhecidos de localizações pré-definidas:
\begin{itemize}
\item Shutdown em algumas versões tem o programa  \url{/etc/reboot} pré-definido, sendo que {\ttfamily reboot} deverá estar no diretório  {\ttfamily /etc} .
\item {\ttfamily init} pode causar alguns problemas, caso o kernel não consiga encontrá-lo em {\ttfamily init}.
\end{itemize}


Para corrigir estes problemas, deve-se ou mover os programas para o diretório correto, ou mudar os arquivos de configuração (por exemplo  {\ttfamily inittab}) para apontarem para o diretório correto. Em caso de dúvidas, ponha os programas no mesmo diretório em que eles estavam no disco rígido, e utilize os mesmos  {\ttfamily inittab} e  \url{/etc/rc.d} da forma como eles estão presentes.

{\bfseries Q. Meu kernel tem suporte a disco em memória, mas aparece com 0 Kb de espaço.}



Quando isso ocorre, uma mensagem do kernel aparecerá durante a inicialização: \nidx{disco em memória}

\begin{verbatim}
Dispositivo de disco em memória inicializado: 
16 discos em memória com tamanho de 0K.
\end{verbatim}

Isso se deve provavelmente à definição do tamanho em zero através dos parâmetros de kernel em tempo de inicialização. Algo como:

\begin{tscreen}
\begin{verbatim}
ramdisk=0
\end{verbatim}
\end{tscreen}


Isso foi incluído como exemplo de configuração do LILO em algumas distribuições antigas, e foi colocado para sobrepor-se a parâmetros anteriores de configuração do kernel. Caso essa linha esteja presente, deve ser retirada.

Note que ao se tentar utilizar um disco em memória com tamanho igual a zero, o comportamento do sistema é imprevisível, e pode resultar em travamentos do kernel.




\section{Recursos e Endereços\label{referências}}

Nesta seção, {\itshape vvv\/} é usado no lugar de versões dos nomes dos pacotes, a fim de evitar a referência a uma versão específica. Ao recuperar um pacote, deve-se procurar usar sempre a versão mais recente, a menos que haja alguma boa razão para fazer o contrário.




\subsection{Discos de Inicialização Pré-Configurados}

\label{distbootdisks}

Há diversas fontes de discos de distribuições.  {\itshape  Por favor use um dos sites espelhos para reduzir o tráfego nestas máquinas.\/}
\begin{itemize}
\item  \nameurl{http://sunsite.unc.edu/pub/Linux/distributions/slackware/bootdsks.144/}{Discos de inicialização Slackware} e \nameurl{http://sunsite.unc.edu/pub/Linux/distributions/slackware/MIRRORS.TXT}{Sites espelho Slackware}
\item  \nameurl{http://sunsite.unc.edu/pub/Linux/distributions/redhat/current/i386/images/}{ Discos de inicialização Red Hat} e \nameurl{http://www.redhat.com/ftp.html}{Sites espelho Red Hat}
\item  \nameurl{ftp://ftp.debian.org/pub/debian/stable/disks-i386}{ Discos de inicialização Debian} e \nameurl{ftp://ftp.debian.org/debian/README.mirrors}{Sites espelho Debian}
\end{itemize}


Em adição aos discos das distribuições, as seguintes imagens de discos de emergência estão disponíveis:

\begin{itemize}
\item {\ttfamily tomsrtbt}, de Tom Oehser, é um único disco de inicialização e raiz, baseado no kernel 2.0.33, com uma grande lista de funcionalidades e programas de suporte. Suporta IDE, SCSI, fita, placas de rede, PCMCIA e mais. Mais de 100 utilitários e ferramentas estão inclusas para correção e restauração de discos. O pacote ainda inclui programas para desmontagem e reconstrução de imagens, permitindo que novos itens possam ser incluídos.\nameurl{http://www.toms.net/~toehser/rb/tomsrtbt-current.tar.gz}{}

\nameurl{http://sunsite.unc.edu/pub/Linux/system/recovery/}{}



\item {\ttfamily rescue02}, de John Comyns, é um disco de emergência baseado no kernel 1.3.84, com suporte a IDE e  Adaptec 1542 e NCR53C7,8xx. Usa binários ELF, porém contém comandos suficientes para ser utilizado em qualquer sistema. Há módulos que podem ser carregados após a inicialização do sistema para todas as placas SCSI. Provavelmente não funcionará em sistemas com 4 Mb de RAM, uma vez que utiliza um disco de 3 Mb.\nameurl{http://sunsite.unc.edu/pub/Linux/system/recovery/rescue02.zip}{}



\item {\ttfamily resque\_disk-2.0.22}, de Sergei Viznyuk,  é um disco de inicialização e raiz baseado no kernel 2.0.22 com suporte a IDE, muitas controladoras SCSI e ELF/OUT. Inclui ainda diversos módulos e utilitários para reparar e restaurar discos rígidos.\nameurl{http://sunsite.unc.edu/pub/Linux/system/recovery/resque_disk-vvv.tar.gz}{}



\item {\ttfamily Imagens cramdisk} baseado no kernel 2.0.33, disponível para máquinas com 4 e 8 Mb. Incluem emulador matemático e suporte à comunicação (PPP e programas de discagem, NE2000, 3C509), ou suporte a dispositivos ZIP paralelos. Estas imagens serão capazes de inicializar um 386 com 4 Mb de RAM. Suporte a MSDOS está incluso, podendo-se assim transmitir da Internet para uma partição DOS.\nameurl{http://sunsite.unc.edu/pub/Linux/system/recovery/images/}{}



\end{itemize}





\subsection{Discos de Emergência}

Diversos pacotes de criação de discos de emergência estão disponíveis em sunsite.unc.edu. Com estes pacotes pode-se especificar um conjunto de arquivos para inclusão e o software automatiza (em vários níveis) a criação do disco de inicialização. Veja \nameurl{http://sunsite.unc.edu/pub/Linux/system/recovery/!INDEX.html}{} para maiores informações. {\bfseries Verifique as datas dos arquivos cuidadosamente} --- alguns destes pacotes podem estar desatualizados há vários anos e podem não suportar a criação de sistemas de arquivos raiz compactados carregados em discos em memória. Até onde conhecemos Yard é o único pacote que poderá fazer isso.




\subsection{Programas de Lote de Graham Chapman}



Graham Chapman  escreveu um conjunto de programas que podem ser bastante úteis como exemplos de criação de discos de inicialização. Em versões anteriores deste tutorial os programas apareciam como um apêndice, mas foram apagados deste documento e colocados em uma página web:
\nameurl{http://www.zeta.org.au/grahamc/linux.html}{}

Pode ser conveniente o uso destes programas, mas deve-se ler cuidadosamente as instruções -- por exemplo ao especificar uma área de troca incorreta, pode-se apagar o sistema de arquivos raiz definitivamente. Esteja seguro de que esteja bem configurado antes de usar os programas.




\subsection{LILO --- O carregador Linux}

\ncdx{LILO}

Escrito por  Werner Almesberger.  Excelente carregador da inicialização do sistema, e a documentação inclui informações sobre o setor de inicialização e os estágios anteriores do processo de carga de um sistema.

Ftp em \nameurl{ftp://tsx-11.mit.edu/pub/linux/packages/lilo/lilo.vvv.tar.gz}{}.  Está também disponível no Sunsite e seus diversos sites espelhos.




\subsection{Perguntas Mais Freqüentes e Como Fazer}

Estão disponíveis em diversos locais. Pode-se verificar os grupos de notícias da Usenet em  {\ttfamily news.answers} e {\ttfamily comp.os.linux.announce}.

Perguntas mais freqüentes em  \nameurl{http://sunsite.unc.edu/pub/Linux/docs/faqs/linux-faq}{} e Como Fazer em  \nameurl{http://sunsite.unc.edu/pub/Linux/docs/HOWTO}{}.

Mais documentação sobre o Linux pode ser encontrada em  \nameurl{http://sunsite.unc.edu/LDP/}{Página do Projeto de Documentação Linux}.

Caso o problema seja seríssimo pode-se enviar uma mensagem em inglês para {\ttfamily mail-server@rtfm.mit.edu} com a palavra 
``{\ttfamily help}'' na mensagem.




\subsection{Uso do Disco em Memória}

\nidx{Disco em memória}
Uma excelente descrição de como funciona o novo código de disco em memória pode ser encontrada com a documentação do kernel do Linux. Veja em  \url{/usr/src/linux/Documentation/ramdisk.txt}. Foi escrito por Paul Gortmaker e inclui uma seção sobre a criação de discos em memória compactados.






\subsection{O processo de inicialização do Linux}

\nidx{processo de inicialização}

Para maiores detalhes sobre o processo de inicialização do Linux, seguem algumas indicações:

\begin{itemize}
\item O Guia de Administração do Sistema Linux contém uma seção sobre o processo. Veja em  \nameurl{http://sunsite.unc.edu/LDP/LDP/sag-0.5/node68.html}{}
\item Visão Geral do  LILO  \nameurl{http://sunsite.unc.edu/pub/Linux/system/boot/lilo/lilo-t-20.ps.gz}{} tem uma visão tecnicamente detalhada e definitiva sobre o processo de inicialização e como o kernel é carregado.
\item O código fonte é o último guia. Abaixo seguem alguns arquivos do kernel relacionados com o processo de inicialização. Caso se tenha à disposição os fontes do Linux, que podem ser encontrados em  \url{/usr/src/linux} em sistemas Linux; ou alternativamente  Shigio Yamaguchi (shigio@wafu.netgate.net) tem um kernel em hipertexto em  \nameurl{http://wafu.netgate.net/linux/}{}.

\begin{description}


\item[arch/i386/boot/bootsect.S,setup.S] \mbox{}

Contém o código Assembler para o setor de inicialização.



\item[arch/i386/boot/compressed/misc.c] \mbox{}

Contém o código para descompactar o kernel.



\item[arch/i386/kernel/] \mbox{}

Diretório contendo o código de inicialização do kernel. {\ttfamily setup.c} contém a palavra de configuração do disco em memória.





\item[drivers/block/rd.c] \mbox{}

Contém o arquivo de controle do disco em memória. Os procedimentos {\ttfamily rd\_load} e   {\ttfamily rd\_load\_image} 
carregam os blocos de um dispositivo em um disco em memória. O procedimento  {\ttfamily identify\_ramdisk\_image} 
determina o tipo do sistema de arquivos encontrado e se ele é compactado.



\end{description}

\end{itemize}







\section{Códigos de Erros de Inicialização do LILO}

\nidx{LILO, códigos de erros}
Questões sobre esses códigos de erros, tem sido freqüentes na Usenet, sendo que incluímos aqui como um serviço público. Este sumário foi desenvolvido a partir da Documentação do Usuário LILO de Werner Almsberger, disponível em  \nameurl{ftp://lrcftp.epfl.ch:/pub/linux/local/lilo/lilo.u.19.ps.gz}{}.

Quando o LILO carrega a si próprio, ele apresenta a palavra ``{\ttfamily LILO}''.  Cada letra é apresentada antes da execução de algum processo, assim sendo as letras podem ser um indicador do estágio atingido e da origem do problema.

\begin{description}
\item[] \mbox{}

Nenhuma parte do LILO foi carregada. LILO pode não estar instalado ou a partição no qual o setor de inicialização está localizado não está ativa.



\item[L] \mbox{}

O primeiro estágio do carregador foi iniciado e executado, mas não foi possível carregar o segundo estágio. Os códigos de erro com dois dígitos indicam o tipo de problema (Veja ainda "Códigos de Erros de Discos"). Esta condição indica normalmente a falha na mídia ou erro de geometria (por exemplo parâmetros de disco incorretos).



\item[LI] \mbox{}

O primeiro estágio foi capaz de carregar o segundo, mas falhou na sua execução. Isso pode ser causado por erro de geometria ou pela movimentação do /boot/boot.b  sem a execução do instalador.



\item[LIL] \mbox{}

O segundo estágio conseguiu ser iniciado, mas não pode carregar a tabela de descritores do arquivo map. Isso normalmente é causado por falha na mídia ou erro de geometria.



\item[LIL?] \mbox{}

O segundo estágio do LILO foi carregado para um endereço incorreto. Isso é tipicamente causado por erros de geometria ou pela movimentação do arquivo \url{/boot/boot.b} sem a execução do instalador.



\item[LIL-] \mbox{}

A tabela de descritores está corrompida. Isso pode ser causado   por erros de geometria ou pela movimentação do arquivo \url{/boot/boot.b} sem a execução do instalador.



\item[LILO] \mbox{}

Todas as partes do LILO foram carregadas.



\end{description}

Caso o BIOS apresente algum erro quando o LILO estiver tentando carregar uma imagem de inicialização, o respectivo código de erro é apresentado. Estes códigos variam de {\ttfamily 0x00} até {\ttfamily 0xbb}. Veja o Guia do Usuário LILO para uma maior explicação sobre este tema.






\section{Listas de exemplo do conteúdo do disco de inicialização}

\label{listings}
\nidx{sistema de arquivos raiz}
Aqui está o conteúdo dos disquetes raiz e utilitários de Graham. Estas listas são apresentadas como um exemplo dos arquivos incluídos em um sistema funcional. Graham adicionou algumas notas explicativas que parecem muito úteis.





\begin{tscreen}
\begin{verbatim}
total 18
drwxr-xr-x   2 root     root         1024 Jul 29 21:16 bin/
drwxr-xr-x   2 root     root         9216 Jul 28 16:21 dev/
drwxr-xr-x   3 root     root         1024 Jul 29 20:25 etc/
drwxr-xr-x   2 root     root         1024 Jul 28 19:53 lib/
drwxr-xr-x   2 root     root         1024 Jul 24 22:47 mnt/
drwxr-xr-x   2 root     root         1024 Jul 24 22:47 proc/
drwxr-xr-x   2 root     root         1024 Jul 28 19:07 sbin/
drwxr-xr-x   2 root     root         1024 Jul 29 20:57 tmp/
drwxr-xr-x   4 root     root         1024 Jul 29 21:35 usr/
drwxr-xr-x   3 root     root         1024 Jul 28 19:52 var/

/bin:
total 713
-rwxr-xr-x   1 root     bin          7737 Jul 24 22:16 cat*
-rwxr-xr-x   1 root     bin          9232 Jul 24 22:48 chmod*
-rwxr-xr-x   1 root     bin          8156 Jul 24 22:48 chown*
-rwxr-xr-x   1 root     bin         19652 Jul 24 22:48 cp*
-rwxr-xr-x   1 root     root         8313 Jul 29 21:16 cut*
-rwxr-xr-x   1 root     bin         12136 Jul 24 22:48 dd*
-rwxr-xr-x   1 root     bin          9308 Jul 24 22:48 df*
-rwxr-xr-x   1 root     root         9036 Jul 29 20:24 dircolors*
-rwxr-xr-x   1 root     bin          9064 Jul 24 22:48 du*
-rwxr-x---   1 root     bin         69252 Jul 24 22:51 e2fsck*
-rwxr-xr-x   1 root     bin          5361 Jul 24 22:48 echo*
-rwxr-xr-x   1 root     bin          5696 Jul 24 22:16 hostname*
-rwxr-xr-x   1 root     bin          6596 Jul 24 22:49 kill*
-rwxr-xr-x   1 root     bin         10644 Jul 24 22:17 ln*
-rwxr-xr-x   1 root     bin         13508 Jul 24 22:17 login*
-rwxr-xr-x   1 root     bin         26976 Jul 24 22:17 ls*
-rwxr-xr-x   1 root     bin          7416 Jul 24 22:49 mkdir*
-rwxr-x---   1 root     bin         34596 Jul 24 22:51 mke2fs*
-rwxr-xr-x   1 root     bin          6712 Jul 24 22:49 mknod*
-rwxr-xr-x   1 root     bin         20304 Jul 24 22:17 more*
-rwxr-xr-x   1 root     bin         24704 Jul 24 22:17 mount*
-rwxr-xr-x   1 root     bin         12464 Jul 24 22:17 mv*
-rwxr-xr-x   1 root     bin         20829 Jul 24 22:50 ps*
-rwxr-xr-x   1 root     bin          9424 Jul 24 22:50 rm*
-rwxr-xr-x   1 root     bin          4344 Jul 24 22:50 rmdir*
-rwxr-xr-x   1 root     root       299649 Jul 27 14:12 sh*
-rwxr-xr-x   1 root     bin          9853 Jul 24 22:17 su*
-rwxr-xr-x   1 root     bin           380 Jul 27 14:12 sync*
-rwxr-xr-x   1 root     bin         13620 Jul 24 22:17 umount*
-rwxr-xr-x   1 root     root         5013 Jul 29 20:03 uname*

/dev:
total 0
lrwxrwxrwx   1 root     root           10 Jul 24 22:34 cdrom -> /dev/sbpcd
crw--w--w-   1 root     tty        4,   0 Jul 24 21:49 console
brw-rw----   1 root     floppy     2,   0 Apr 28  1995 fd0
lrwxrwxrwx   1 root     root            4 Jul 24 22:34 ftape -> rft0
crw-rw-rw-   1 root     sys       10,   2 Jul 18  1994 inportbm
crw-rw----   1 root     kmem       1,   2 Jul 28 16:21 kmem
crw-rw----   1 root     kmem       1,   1 Jul 18  1994 mem
lrwxrwxrwx   1 root     root            4 Jul 24 22:34 modem -> cua0
lrwxrwxrwx   1 root     root            4 Jul 24 22:34 mouse -> cua1
crw-rw-rw-   1 root     sys        1,   3 Jul 18  1994 null
brw-rw----   1 root     disk       1,   1 Jul 18  1994 ram
crw-rw----   1 root     disk      27,   0 Jul 18  1994 rft0
brw-rw----   1 root     disk      25,   0 Jul 19  1994 sbpcd
***  Foram incluídos arquivos de dispositivos para as partições SCSI em uso
***  Caso sejam utilizados discos IDE, deve-se usar /dev/hdxx .
brw-rw----   1 root     disk       8,   0 Apr 29  1995 sda
brw-rw----   1 root     disk       8,   6 Apr 29  1995 sda6
brw-rw----   1 root     disk       8,   7 Apr 29  1995 sda7
brw-rw----   1 root     disk       8,   8 Apr 29  1995 sda8
lrwxrwxrwx   1 root     root            7 Jul 28 12:56 systty -> console
*** esta ligação de systty para a console é obrigatória
crw-rw-rw-   1 root     tty        5,   0 Jul 18  1994 tty
crw--w--w-   1 root     tty        4,   0 Jul 18  1994 tty0
crw--w----   1 root     tty        4,   1 Jul 24 22:33 tty1
crw--w----   1 root     tty        4,   2 Jul 24 22:34 tty2
crw--w--w-   1 root     root       4,   3 Jul 24 21:49 tty3
crw--w--w-   1 root     root       4,   4 Jul 24 21:49 tty4
crw--w--w-   1 root     root       4,   5 Jul 24 21:49 tty5
crw--w--w-   1 root     root       4,   6 Jul 24 21:49 tty6
crw-rw-rw-   1 root     tty        4,   7 Jul 18  1994 tty7
crw-rw-rw-   1 root     tty        4,   8 Jul 18  1994 tty8
crw-rw-rw-   1 root     tty        4,   9 Jul 19  1994 tty9
crw-rw-rw-   1 root     sys        1,   5 Jul 18  1994 zero

/etc:
total 20
-rw-r--r--   1 root     root         2167 Jul 29 20:25 DIR_COLORS
-rw-r--r--   1 root     root           20 Jul 28 12:37 HOSTNAME
-rw-r--r--   1 root     root          109 Jul 24 22:57 fstab
-rw-r--r--   1 root     root          271 Jul 24 22:21 group
-rw-r--r--   1 root     root         2353 Jul 24 22:27 inittab
-rw-r--r--   1 root     root            0 Jul 29 21:02 issue
-rw-r--r--   1 root     root         2881 Jul 28 19:38 ld.so.cache
*** Diversos erros ocorrem na inicialização se ld.so.cache não está presente,mas
*** esteja seguro que  ldconfig está incluído e pode ser executado em rc.x para 
*** atualizá-lo.
-rw-r--r--   1 root     root           12 Jul 24 22:22 motd
-rw-r--r--   1 root     root          606 Jul 28 19:25 passwd
-rw-r--r--   1 root     root         1065 Jul 24 22:21 profile
drwxr-xr-x   2 root     root         1024 Jul 29 21:01 rc.d/
-rw-r--r--   1 root     root           18 Jul 24 22:21 shells
-rw-r--r--   1 root     root          774 Jul 28 13:43 termcap
-rw-r--r--   1 root     root          126 Jul 28 13:44 ttys
-rw-r--r--   1 root     root            0 Jul 24 22:47 utmp

/etc/rc.d:
total 5
*** Não me importo muito com programas de encerramento do sistema -
*** tudo é executado em um disco em memória, não havendo muitas coisas
*** para finalizar.
-rwxr-xr-x   1 root     root         1158 Jul 24 22:23 rc.K*
-rwxr-xr-x   1 root     root         1151 Jul 28 19:08 rc.M*
-rwxr-xr-x   1 root     root          507 Jul 29 20:25 rc.S*

/lib:
total 588
*** Tenho um sistema ELF, tendo sido incluído o carregador loader ld-linux.so. 
***  Caso se esteja ainda utilizando o  a.out, então deve-se incluir ld.so. 
*** Deve-se usar o comando file para verificar quais  bibliotecas devem ser incluídas.
lrwxrwxrwx   1 root     root           17 Jul 24 23:36 ld-linux.so.1 -> ld-linux.so.1.7.3*
-rwxr-xr-x   1 root     root        20722 Aug 15  1995 ld-linux.so.1.7.3*
lrwxrwxrwx   1 root     root           13 Jul 24 23:36 libc.so.5 -> libc.so.5.0.9*
-rwxr-xr-x   1 root     root       562683 May 19  1995 libc.so.5.0.9*
***  Deve-se incluir   libtermcap
lrwxrwxrwx   1 root     root           19 Jul 28 19:53 libtermcap.so.2 -> libtermcap.so.2.0.0*
-rwxr-xr-x   1 root     root        11360 May 19  1995 libtermcap.so.2.0.0*

/mnt:
total 0

/proc:
total 0

/sbin:
total 191
***  Utilizo Slackware, o qual usa  agetty. Muitos sistemas usam  getty.
***  Verifique em /etc/inittab para ver qual o necessário. Note que  (a)getty e login
***  são necessários para que se possa fazer algo no sistema.
-rwxr-xr-x   1 root     bin         11309 Jul 24 22:54 agetty*
-rwxr-xr-x   1 root     bin          5204 Jul 24 22:19 halt*
***  Obrigatório na inicialização do sistema
-rwxr-xr-x   1 root     bin         20592 Jul 24 22:19 init*
-rwxr-xr-x   1 root     root        86020 Jul 28 19:07 ldconfig*
-rwxr-xr-x   1 root     bin          5329 Jul 27 14:10 mkswap*
-rwxr-xr-x   1 root     root         5204 Jul 24 22:20 reboot*
-rwxr-xr-x   1 root     root         6024 Jul 24 22:20 rdev*
-rwxr-xr-x   1 root     bin         12340 Jul 24 22:20 shutdown*
-rwxr-xr-x   1 root     root         5029 Jul 24 22:20 swapoff*
-rwxr-xr-x   1 root     bin          5029 Jul 24 22:20 swapon*
-rwxr-xr-x   1 root     root        20592 Jul 27 18:18 telinit*
-rwxr-xr-x   1 root     root         7077 Jul 24 22:20 update*

/tmp:
total 0

/usr:
total 2
drwxr-xr-x   2 root     root         1024 Jul 29 21:00 adm/
drwxr-xr-x   2 root     root         1024 Jul 29 21:16 lib/

/usr/adm:
total 0

/usr/lib:
total 0

/var:
total 1
***  Muitos problemas ocorreram antes da inclusão do  /etc/rc.S 
***  para inicializar o /var/run/utmp, mas talvez  isso não seja necessário
*** em outros sistemas
drwxr-xr-x   2 root     root         1024 Jul 28 19:52 run/

/var/run:
total 0
\end{verbatim}
\end{tscreen}





\section{Listas de exemplo do conteúdo do disco de utilitários}

\label{utilitylist}
\nidx{disquete de utilitários}

\begin{tscreen}
\begin{verbatim}
total 579
-rwxr-xr-x   1 root     root        42333 Jul 28 19:05 cpio*
-rwxr-xr-x   1 root     root       103560 Jul 29 21:31 elvis*
-rwxr-xr-x   1 root     root        56401 Jul 28 19:06 find*
-rwxr-xr-x   1 root     root        29536 Jul 28 19:04 fdisk*
-rw-r--r--   1 root     root       128254 Jul 28 19:03 ftape.o
-rwxr-xr-x   1 root     root        17564 Jul 25 03:21 ftmt*
-rwxr-xr-x   1 root     root        64161 Jul 29 20:47 grep*
-rwxr-xr-x   1 root     root        45309 Jul 29 20:48 gzip*
-rwxr-xr-x   1 root     root        23560 Jul 28 19:04 insmod*
-rwxr-xr-x   1 root     root          118 Jul 28 19:04 lsmod*
lrwxrwxrwx   1 root     root            5 Jul 28 19:04 mt -> mt-st*
-rwxr-xr-x   1 root     root         9573 Jul 28 19:03 mt-st*
lrwxrwxrwx   1 root     root            6 Jul 28 19:05 rmmod -> insmod*
-rwxr-xr-x   1 root     root       104085 Jul 28 19:05 tar*
lrwxrwxrwx   1 root     root            5 Jul 29 21:35 vi -> elvis*
\end{verbatim}
\end{tscreen}
