Carlos E. Morimoto

Introdução

O Knoppix é uma das distribuições mais bem sucedidas. Além de ser uma das distribuições mais populares, ele deu origem a um sem número de distribuições especializadas, que juntas possuem um número de usuários provavelmente maior do que qualquer outra distribuição.

Isso foi possível pois, além de ser fácil de usar como um live-CD, o Knoppix pode ser personalizado, o que permite desenvolver novas distribuições e soluções. Você pode escolher entre começar a partir do Knoppix original ou usar o Kurumin (ou outra das muitas distribuições derivadas dele), corrigindo problemas, adicionando novos recursos ou personalizando o que quiser.

O Kurumin mantém a detecção de hardware, possibilidade de personalização e outras características positivas do Knoppix original, adicionando diversos scripts, personalizações, drivers e ferramentas de configuração que tornam o sistema mais fácil e agradável de usar. Enquanto o Knoppix é um sucesso entre o público técnico, o Kurumin conseguiu crescer rapidamente entre os usuários finais, um
terreno que até então parecia difícil de conquistar.

Os exemplos deste capítulo se concentram na remasterização do Kurumin (que é, afinal, uma das soluções mais usadas aqui no Brasil), mas os mesmos passos podem ser usados em outras distribuições recentes, derivadas do Knoppix. É uma uma boa oportunidade de colocar em prática o que aprendemos até aqui.

 

O Básico

O Knoppix é uma distribuição baseada no Debian, que utiliza o módulo cloop para rodar a partir de uma imagem compactada. Além de dar boot diretamente através do CD, DVD ou pendrive, sem alterar os arquivos no HD, ele inclui uma série de utilitários, com destaque para o hwsetup, que se encarrega de detectar todo o hardware da máquina durante o boot.

Não importa qual seja a configuração do PC: se os componentes forem compatíveis com a versão do Kernel usada, ele funciona sem nenhuma intervenção do usuário. Os scripts de inicialização podem ser editados, de forma a incluir suporte a componentes adicionais, que não sejam detectados pelo script padrão, ou executar funções adicionais diversas, como salvar as configurações em um pendrive ou num compartilhamento de rede.

Além do Kurumin, existem hoje em dia algumas centenas de distribuições baseadas no Knoppix ou distribuições “netas”, desenvolvidas a partir do Kurumin ou outra das distribuições “filhas”. As vantagens em relação a outras distribuições são:

1- Ele detecta e configura o hardware automaticamente, dispensando a configuração manual em cada máquina

2- Além de ser usado como live-CD, ele pode ser instalado no HD, mantendo a configuração e a detecção de hardware feita durante o boot. O próprio instalador pode oferecer opções adicionais e fazer modificações onde necessário.

3- Você pode instalar novos programas a partir dos repositórios do Debian, usando o apt-get, sem precisar manter pacotes ou um repositório externo.

4- O conteúdo do CD é compactado, o que permite instalar quase 2 GB de programas num CD de 700 MB, mais do que suficiente para uma distribuição completa. Os mesmos passos descritos aqui podem ser usados caso seja necessário desenvolver um sistema maior, destinado a ser gravado em DVD, ou uma distribuição compacta, destinada a ser gravada em um mini-CD.

5- É possível instalar drivers para softmodems e outros tipos de hardware não suportados por default, programas binários ou comerciais, e assim por diante. Você pode até mesmo usar o Wine para rodar alguns aplicativos Windows.
Existem inúmeras aplicações para a idéia. Você pode criar uma distribuição padrão para ser instalada em todos os PCs da empresa e, ao mesmo tempo, usá-la como uma forma de introduzir o Linux aos funcionários, mantendo o Windows instalado no HD. É possível criar CDs bootáveis com softwares diversos para apresentar a seus clientes; criar CDs para aplicações específicas, como discos de recuperação, CDs com documentação, e assim por diante. Só depende da sua criatividade.

Dentro da imagem do CD, você encontra apenas alguns arquivos pequenos, incluindo a página html exibida no final do boot, que variam de acordo com a distribuição. Dentro da pasta /KNOPPIX, vai o arquivo compactado com o sistema, que ocupa quase todo o espaço do CD.

Este arquivo nada mais é do que uma imagem compactada da partição raiz do sistema. O módulo cloop “engana” o Kernel, fazendo-o pensar que está acessando uma partição EXT2 no HD, quando, na verdade, os dados dentro da imagem vão sendo descompactados de forma transparente, conforme são requisitados.

Algumas pastas do sistema que precisam de suporte a escrita, como, por exemplo, os diretórios “/home” e “/var”, são armazenadas num ramdisk de 2 MB criado no início do boot. Este ramdisk pode crescer conforme necessário, desde que exista memória suficiente. Como nem todo mundo tem 256 MB de RAM ou mais, o sistema usa partições Linux swap, ou arquivos de troca encontrados em partições Windows, caso exista um HD instalado. Na falta dele, o sistema roda inteiramente na memória RAM, lendo os arquivos a partir do CD.

O módulo cloop foi originalmente desenvolvido por Andrew Morton, que é atualmente o mantenedor do Kernel 2.6. Na época ele achou que o módulo não serviria para nada interessante e o descartou. Algum tempo depois ele foi redescoberto pelo Klaus Knopper, que acabou o utilizando como um dos componentes base do Knoppix. É um bom exemplo sobre como as coisas funcionam dentro do open-source.

Nas versões recentes, o ramdisk é usado também para armazenar as alterações feitas com a ajuda do UnionFS. O diretório raiz contém um conjunto de links que apontam para diretórios dentro da pasta “/UNIONFS”, que é composta pela combinação do ramdisk (leitura e escrita) e da pasta “/KNOPPIX”, onde é montada a imagem compactada do CD (somente leitura).

Para gerar uma versão customizada, precisamos descompactar esta imagem numa pasta do HD, fazer as modificações desejadas, gerar uma nova imagem compactada e finalmente, gerar o novo arquivo .iso, que pode ser gravado no CD ou DVD.

Para isso, você precisará de uma partição Linux com 2.5 GB de espaço livre (no caso do Kurumin) ou 3.5 GB caso esteja remasterizando o Knoppix ou outra distribuição com 700 MB. No caso das versões em DVD, é necessário um espaço proporcionalmente maior. Calcule um espaço 5 vezes maior que o tamanho do sistema original, pois a imagem descompactada ocupa 3 vezes mais espaço e vai ser necessário guardar também a nova imagem compactada e o arquivo .iso final.

É necessário ter também uma partição Linux swap (ou um arquivo swap) de 1 GB, menos a quantidade de RAM do PC. Se você tem 512 MB de RAM, por exemplo, vai precisar de pelo menos mais 512 MB de swap. O problema neste caso é que o sistema usa a memória para armazenar a imagem compactada enquanto ela está sendo processada, copiando o arquivo para o HD apenas no final do processo.

Note que a quantidade de memória varia de acordo com o tamanho da imagem gerada. Ao gerar uma imagem maior, destinada a ser gravada em DVD, você vai precisar de uma quantidade proporcional de memória ou swap.

Todo o processo de remasterização pode ser feito a partir do próprio CD do Kurumin, ou da distribuição que está sendo modificada. Todas as ferramentas necessárias estão inclusas no próprio CD.

Uma observação importante é que é preciso usar a mesma versão do módulo cloop instalada no sistema de desenvolvimento para fechar o arquivo compactado. Em outras palavras, se você está fazendo um remaster do Kurumin, com uma versão personalizada do Kernel 2.6.16, por exemplo, você vai precisar instalar a mesma imagem do Kernel numa instalação do Kurumin no HD e fechar o novo ISO usando esta instalação.

Se você estiver rodando versões diferentes do Kernel, ou estiver usando outra distribuição, as versões do cloop serão diferentes e o novo CD simplesmente não vai dar boot.

Extraindo

O primeiro passo é dar boot com o CD do Kurumin ou da distribuição em que vai trabalhar. Monte a partição que será usada para extrair o sistema. Você pode aproveitar também a partição de uma distribuição Linux já existente no HD, desde que ele possua espaço livre suficiente.

Um detalhe importante é que (no Kurumin) você deve montar a partição via terminal e não usando os atalhos no desktop. Eles montam as partições adicionando o parâmetro “nodev”, que impede que os scripts direcionem suas saídas para o “/dev/null”, causando uma série de erros. Vou usar como exemplo a partição “/dev/hda6″.

# mount -t reiserfs /dev/hda6 /mnt/hda6

O próximo passo é criar duas pastas, uma para abrigar a imagem descompactada e outra para guardar os arquivos que irão no CD (fora da imagem compactada), como os arquivos de boot e os manuais. Lembre-se de que os arquivos dentro da imagem compactada ficam acessíveis apenas dando boot pelo CD, enquanto os arquivos fora da imagem podem ser acessados a partir de qualquer sistema operacional, como se fosse um CD-ROM comum.

Na época em que comecei a desenvolver o Kurumin, a única referência (embora bem resumido) era o “Knoppix how-to” do Eadz. Em homenagem, continuo até hoje usando os nomes de pastas indicados nele:

# mkdir /mnt/hda6/knxmaster
# mkdir /mnt/hda6/knxsource
# mkdir /mnt/hda6/knxsource/KNOPPIX
A pasta “knxmaster” é usada para armazenar uma cópia simples dos arquivos do CD, usada para gerar o ISO final. A pasta “knxsource/KNOPPIX” por sua vez armazena a cópia descompactada do sistema, onde fazemos as modificações.

Comece fazendo a cópia completa dos arquivos do CD para dentro da pasta “knxmaster/”. Ao dar boot pelo CD, os arquivos ficam disponíveis dentro da pasta “/cdrom”:

# cp -a /cdrom/* /mnt/hda6/knxmaster/

Em seguida, vamos criar a imagem descompactada do sistema na pasta knxsource/KNOPPIX/. Para o comando abaixo você deve ter dado boot a partir do CD; ele nada mais é do que uma forma de copiar o sistema de arquivos montado durante o boot para a pasta indicada:

# cp -Rp /KNOPPIX/* /mnt/hda6/knxsource/KNOPPIX/

Esta etapa demora um pouco, pois além de ler os arquivos no CD, o processador tem o trabalho de descompactar tudo, como se estivesse instalando o sistema no HD. Terminada a cópia, você verá a árvore de diretórios do sistema dentro da pasta:

Você deve estar se perguntando se o próximo passo será acessar a pasta e sair editando os arquivos de configuração e instalando aplicativos manualmente. Bem, isso até seria possível para alguém sem muito o que fazer, mas existe uma forma muito mais fácil de trabalhar dentro da pasta de desenvolvimento, utilizando o comando “chroot“. Ele permite transformar a pasta no diretório raiz do sistema, de modo que você possa instalar programas, instalar e remover pacotes e até mesmo abrir o KDE e sair alterando suas configurações. Tudo o que você fizer dentro da janela do chroot alterará seu novo CD bootável. Para ativá-lo, use o comando:

# chroot /mnt/hda6/knxsource/KNOPPIX/

(como root)

A partir daí, a pasta passa a ser vista pelo sistema como se fosse o diretório raiz, fazendo com que todos os comandos sejam executados dentro do seu sistema de desenvolvimento:

Antes de começar a trabalhar, monte o diretório /proc dentro do chroot. Sem isso a funcionalidade será limitada e você receberá erros diversos ao instalar programas:

# mount -t proc /proc proc

Nas versões recentes, que utilizam o udev (usado a partir do Kurumin 6.0), é necessário montar também a pasta “/sys” e o “/dev/pts”. Sem os dois, você não conseguirá carregar o modo gráfico, como explico adiante:

# mount -t sysfs sys /sys
# mount -t devpts /dev/pts /dev/pts

Para acessar a internet de dentro do chroot e assim poder usar o apt-get para instalar programas, edite o arquivo “/etc/resolv.conf“, colocando os endereços dos servidores DNS usados na sua rede, como em:

nameserver 200.199.201.23
nameserver 200.177.250.138
A partir daí, você pode instalar novos pacotes via apt-get, como se fosse um sistema instalado. Se precisar instalar pacotes manualmente, copie os arquivos para dentro de uma pasta no diretório e instale usando o comando “dpkg -i”. No Kurumin, por exemplo, uso a pasta “/knxsource/KNOPPIX/packages/”, que é vista como “/packages” dentro do chroot.

Inicialmente, o chroot permite usar apenas comandos de modo texto. Você pode editar arquivos manualmente usando editores de modo texto, como o mcedit e o vi e usar o apt-get, mas não tem como usar ferramentas gráficas ou mudar configurações no centro de controle do KDE, por exemplo.

É possível carregar o modo gráfico de dentro do chroot, configurando a variável DISPLAY do sistema para que seja usado um servidor X externo. Isso permite carregar o KDE ou outros ambientes gráficos, útil principalmente quando você precisar alterar as opções visuais do sistema, editar o menu do KDE ou alterar a configuração dos aplicativos.

É até possível fazer isso via linha de comando (eu faço editando os arquivos de configuração do KDE (que vão dentro da pasta “.kde/”, no home) mas é muito mais simples através do Kcontrol.

Existem duas opções aqui. Você pode abrir um segunda seção do X, ou usar o Xnest (a opção mais simples, porém mais precária), que abre uma instância do X dentro de uma janela.

Para abrir o servidor X “real”, use o comando:

# X -dpi 75 :1

Isso abrirá um X “pelado”, com a tela cinza e o cursor do mouse. Volte para o X principal pressionando “Ctrl+Alt+F7″ e retorne para ele pressionando “Ctrl+Alt+F8″.

Para abrir o Xnest, use (neste caso com seu login de usuário, não o root), os comandos:

$ xhost +
$ Xnest :1
Em ambos os casos, você terá aberta uma segunda seção do X (:1), que podemos usar de dentro do chroot. Note que, para usar o Xnest, você precisa instalar o pacote “xnest” via apt-get.

Existem algumas considerações antes de continuar. Inicialmente, você está logado como root dentro do chroot. Ao alterar as configurações do sistema (configurações visuais, menu, programas que serão carregados na abertura do KDE, etc.) precisamos fazer isso como o usuário usado por padrão no sistema, “knoppix” no Knoppix ou “kurumin” no Kurumin.

As configurações padrão vão inicialmente na pasta “/etc/skel”. O conteúdo é copiado para a pasta home durante o boot, criando a pasta “/home/kurumin” ou “/home/knoppix”. Precisamos refazer esse processo artificialmente, de forma a carregar o ambiente gráfico (e com o usuário certo a partir do chroot.

Comece (ainda como root) copiando os arquivos para a pasta home do usuário desejado. Vou usar como exemplo o usuário kurumin. Lembre-se de que tudo isso é feito dentro da janela do chroot:

# cd /home
# cp -R /etc/skel kurumin
# chown -R kurumin.kurumin kurumin/
# rm -rf /var/tmp/*
Agora logue-se como o usuário kurumin (ainda dentro do chroot) e abra o KDE na instância extra do X que abrimos anteriormente:

# su kurumin
$ cd /home/kurumin/
$ export DISPLAY=localhost:1
$ startkde
Isso abrirá o KDE dentro da segunda seção do X. Se precisar carregar outra interface, substitua o “startkde” pelo comando adequado.

Ao usar o Xnest, é normal que sejam exibidas mensagens de erro diversas (no terminal) durante a abertura do KDE. Alguns aplicativos podem ser comportar de forma estranha, o que também é normal já que ele não oferece todos os recursos do servidor X “real”. Pense nele como uma forma rápida de alterar as configurações do sistema que está sendo remasterizado e não como algo livre de falhas.

Depois de alterar todas as configurações desejadas, feche o KDE pelo “Iniciar > Fechar Sessão > Finalizar sessão atual” e, de volta ao terminal do chroot, copie os arquivos modificados do “/home/kurumin” de volta para o “/etc/skel”, sem se esquecer de restabelecer as permissões originais:

$ exit
# cd /home
# cp -Rf kurumin/* /etc/skel/
# chown -R root.root /etc/skel
# rm -rf /home/kurumin

Fechando a nova imagem

Depois de fazer a primeira rodada de alterações, é hora de fechar a nova imagem e testar. Evite fazer muitas modificações de uma vez, pois assim fica mais difícil de detectar a origem dos problemas. O ideal é fazer algumas alterações, fechar uma nova imagem, testar, fazer mais algumas alterações, fechar outro, e assim por diante. Salve as imagens anteriores, elas podem ser usadas como pontos de recuperação. Com elas, você pode recuperar o sistema a partir de qualquer ponto, caso aconteça qualquer problema estranho que não consiga resolver sozinho.

Caso, mais adiante, você faça alguma alteração que quebre o sistema, basta dar boot com o último CD gerado, deletar o conteúdo da pasta “/knxsource/KNOPPIX” e extrair a imagem novamente. Você terá seu sistema de volta da forma como estava quando gravou o CD.

Para fazer os testes, você tem duas opções: gravar os CDs e dar boot num segundo micro ou usar uma máquina virtual, configurada para usar o arquivo .iso gerado como CD-ROM (a melhor opção se você tem apenas um PC). Evite gravar as imagens em CD-RW para testar, pois eles apresentam muitos erros de leitura, que podem levar a problemas estranhos no sistema, causados por falta de arquivos. Eles podem fazer você perder muito tempo procurando por problemas que na verdade são causados pela mídia. Use CD-R normais, ou use diretamente os arquivos .iso dentro da VM.

Ao fechar as imagens, comece limpando o cache de pacotes do apt-get dentro do chroot. O apt conserva uma cópia de todos os pacotes baixados, o que desperdiça bastante espaço.

# apt-get clean

Você pode também deletar a base de dados dos pacotes disponíveis (que é gerada ao rodar o “apt-get update”), reduzindo o tamanho da imagem final em quase 10 MB:

# rm -f /var/lib/apt/lists/*

(não delete a pasta “/var/lib/apt/lists/partial”, apenas os arquivos)

Outro comando útil, que ajuda a liberar espaço é o “deborphan”, que lista bibliotecas órfãs, que não são necessárias para nenhum programa instalado. Elas vão surgindo conforme você instala e remove programas.

# deborphan

Os pacotes listados por ele podem ser removidos com segurança usando o “apt-get remove”.

Delete também o histórico de comandos do root, que contém os comandos que você executou durante o processo de personalização; não existe necessidade de divulgá-los ao mundo. Aproveite para eliminar também o diretório .rr_moved:

# rm -f /home/root/.bash_history
# rm -rf /.rr_moved
Finalmente chegou hora de dar adeus ao chroot e gerar a nova imagem. Comece desmontando o “/dev/pts”, o “/sys” e o diretório “/proc” que montamos no início do processo, caso contrário todo o conteúdo da memória e do diretório /dev será incluído na imagem, gerando um arquivo gigante:

# umount /dev/pts
# umount /sys
# umount /proc
Agora pressione CTRL+D para sair do chroot.

O próximo passo é gerar o novo arquivo compactado. Esta etapa demora um pouco já que o sistema precisa compactar todo o diretório knxsource.

Antes de tentar gerar a imagem, use o comando free para verificar se a memória swap está ativada. Se necessário, formate novamente a partição swap e reative-a com os comandos “mkswap /dev/hda2″ e “swapon /dev/hda2″, substituindo o “hda2″ pela partição correta.

Depois de tudo verificado, o comando para gerar a imagem é:

# mkisofs -R -V “Meu_CD” -hide-rr-moved -pad /mnt/hda6/knxsource/KNOPPIX \
| /usr/bin/create_compressed_fs – 65536 > /mnt/hda6/knxmaster/KNOPPIX/KNOPPIX

(As duas linhas formam um único comando)

Ele é um pouco longo mesmo, dado o número de parâmetros necessários. Aqui vai uma explicação mais detalhada da função de cada um:

mkisofs: Este é o programa usado para gerar imagens ISO no Linux. Ele é utilizado originalmente por programas de gravação de CD. Graças aos parâmetros extras, ele é “adaptado” para gerar a imagem compactada do sistema.

-R: Ativa as extensões Rock-Ridge, que adicionam suporte a nomes longos no Linux.

-V “Kurumin”: O nome do volume. Você pode substituir o “Kurumin” por qualquer outro nome.

-hide-rr-moved: Esconde o diretório RR_MOVED caso encontrado. Apenas uma precaução.

-pad: Para prevenir problemas de leitura, o tamanho total da imagem deve ser sempre um múltiplo de 32 KB. Este parâmetro verifica isso e adiciona alguns bits zero no final da imagem para completar os últimos 32 KB, caso necessário.

/mnt/hda6/knxsource/KNOPPIX: Este é o diretório fonte, onde está a imagem descompactada do sistema. Não se esqueça de substituir o “hda6″ pela partição correta.

| /usr/bin/create_compressed_fs – 65536: Este é o grande truque. O pipe direciona toda a saída do comando para o programa “create_compressed_fs” (incluído no sistema), que se encarrega de compactar os dados. Note que por causa do uso deste comando, você só poderá gerar a imagem compactada a partir do Kurumin ou outra distribuição baseada no Knoppix, de preferência uma instalação do próprio sistema que está remasterizando. Você não conseguirá fazer a partir do Mandriva (por exemplo), pois ele não inclui o executável citado aqui.

> /mnt/hda6/knxmaster/KNOPPIX/KNOPPIX: O redirecionamento (>) faz com que o fluxo de dados gerado pelos comandos anteriores seja salvo no arquivo que especificamos aqui, gerando a imagem compactada do sistema, que será usada no novo arquivo .iso.

Depois de gerar a imagem você notará que o seu micro ficará um pouco lento, pois o processo consome toda a memória RAM disponível. Isso é normal, mova um pouco o mouse e clique nas janelas que ele logo volta ao normal.

Com a nova imagem compactada gerada, falta agora apenas fechar o .iso do CD, usando os arquivos da pasta knxmaster. Este comando é usado nas versões recentes, que utilizam o Kernel 2.6:

# cd /mnt/hda6/knxmaster

# mkisofs -pad -l -r -J -v -V “Kurumin” -no-emul-boot -boot-load-size 4 \
-boot-info-table -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat \
-hide-rr-moved -o /mnt/hda6/kurumin.iso /mnt/hda6/knxmaster
No final será gerado o arquivo “kurumin.iso” dentro da pasta “/mnt/hda6″. Você pode alterar o nome do arquivo destino de acordo com a necessidade.

O comando gera um CD bootável usando o isolinux, um sistema de boot que tem uma função similar à do lilo e grub, mas é otimizado para uso em CD-ROMs. Os arquivos vão dentro da pasta “boot/isolinux” no raiz do CD. O comando indica o caminho para o executável do isolinux, que será incluído no CD (boot/isolinux/isolinux.bin).

As versões antigas, com o Kernel 2.4, usavam uma imagem de um disquete de 1.44 como sistema de boot. Este é o sistema mais compatível com placas antigas, mas tem uma séria limitação: o sistema de boot precisa ter menos que 1.44 MB, a capacidade do disquete. Com todas as novidades e melhorias, o Kernel 2.6 ficou muito maior, tornando quase impossível criar um sistema de boot funcional em apenas 1.44 MB.

Caso você precise remasterizar uma versão antiga, ainda com o Kernel 2.4, os passos e comandos para remasterizar são os mesmos, mas o comando para fechar o ISO fica:

# mkisofs -pad -l -r -J -v -V “Meu_CD” -b KNOPPIX/boot.img -c \
KNOPPIX/boot.cat -hide-rr-moved -o /mnt/hda6/kurumin.iso /mnt/hda6/knxmaster
Ao remasterizar o Kanotix, ou outra distribuição live-CD que utilize o grub como gerenciador de boot, o comando fica:

# mkisofs -pad -l -r -J -v -V “Kanotix” -b boot/grub/iso9660_stage1_5 -c \
boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -hide -rr -moved \
-o /mnt/hda6/kanotix.iso /mnt/hda6/knxmaster
Existem duas variáveis dentro do script de instalação (o arquivo “/usr/local/bin/kurumin-install”), que devem ser alteradas de acordo com o tamanho do sistema. Você pode verificar isso a partir do próprio Konqueror, ou usando o comando “du -sh”, como em:

$ du -sh /mnt/hda6/knxsource/

Logo no começo do script, você encontra a função responsável pela barra de progresso exibida durante a cópia dos arquivos. Altere o valor de acordo com o tamanho do sistema informado pelo du:

progressbar()
{
{
TOTAL=1300
Um pouco mais abaixo, pela variável que determina o espaço mínimo necessário para fazer a instalação do sistema. O script aborta a instalação caso a partição destino seja menor que o valor especificado aqui:

FSMIN=1300

Personalizando o KDE e programas

Personalizar a configuração padrão do sistema, ajustando o comportamento dos programas, organizando o menu iniciar e arrumando a parte visual acaba sendo uma das partes mais importantes ao desenvolver um sistema destinado a usuários não técnicos, já que é necessário criar um ambiente familiar, bonito e fácil de usar.

O Kurumin armazena as preferências padrão do usuário kurumin (o usado por default) na pasta “/etc/skel“. O conteúdo desta pasta é copiado para a pasta “/ramdisk/home/kurumin” durante o boot e (ao rodar o sistema a partir do CD) todas as alterações são perdidas quando o micro é desligado.

Para alterar as configurações default é preciso ir direto ao ponto, editando diretamente os arquivos da pasta “/etc/skel” dentro do chroot. Navegando dentro dela você encontrará pastas com as preferências do KDE e vários outros programas. Não se esqueça de marcar a opção “marcar arquivos ocultos” no Konqueror.

É recomendável dar uma garimpada nestes arquivos de vez em quando, pois você sempre vai encontrar algumas opções de configuração que não estão disponíveis no Kcontrol. Uma dica, caso você queira estudar mais sobre a edição manual dos arquivos é usar a função “Procurar por arquivos modificados > Nos últimos xx minutos” dentro do kfind para localizar os arquivos modificados depois de cada alteração feita pelo Kcontrol. Embora não pareça à primeira vista, os arquivos de configuração do KDE são bastante organizados e legíveis.

O menu iniciar do KDE é gerado a partir da combinação dos links do diretório “/usr/share/applications/”, onde a maior parte dos pacotes instalados coloca seus ícones e do diretório “/usr/share/applnk”, onde você pode colocar ícones personalizados, que ficam disponíveis para todos os usuários.

Os ícones do KDE são arquivos de texto normais, salvos com a extensão .desktop. Abrindo-os num editor de texto, você verá uma estrutura como esta:

O mais importante aqui são as linhas “exec”, que contém o comando que é executado ao clicar sobre o ícone, a linha “Icon” que contém o ícone usado (os arquivos disponíveis estão dentro da pasta /usr/share/icons) e as linhas “Name” e “GenericName” que contém o nome e descrição, da forma como são exibidos no menu iniciar.

Além das pastas “/usr/share/applications” e “/usr/share/applink”, que formam o iniciar “principal” do sistema, existe um iniciar “particular” para cada usuário, que vai dentro da pasta “.kde/share/applnk/“, dentro do home.

O iniciar é montado a partir da junção do conteúdo das três pastas. Quando existe algum “conflito”, como um ícone configurado de forma diferente nas duas pastas, vale o que está na pasta do usuário.

Dentro das pastas você encontrará um arquivo .directory que contém o nome e descrição da pasta (com suporte a internacionalização) e o ícone usado ao exibí-la no iniciar:

Ao editar o iniciar utilizando o kmenuedit, as alterações são salvas nas pastas “.config” e “.local”, novamente dentro do home de cada usuário.

Os ícones que aparecem no Desktop do KDE ao dar boot vão na pasta “/etc/skel/Desktop”. Estes ícones seguem o mesmo padrão dos ícones do iniciar. Você pode incluir também sub-pastas:

<h1>

Finalmente, os aplicativos que são executados durante o boot (como a janela do Konqueror exibindo o index.html do CD), são configurados através de ícones colocados na pasta “/etc/skel/.kde/Autostart”. A sintaxe dos arquivos .desktop é a mesma em todas estas pastas, você pode arrastar um ícone da pasta “/usr/share/applnk” diretamente para ela, por exemplo:

Assim como o KDE, os demais programas sempre criam pastas de configuração dentro do home. As configurações do XMMS por exemplo, vão dentro da pasta “.xmms“, as do gMplayer vão dentro da “.mplayer“, e assim por diante. As configurações dos aplicativos do KDE ficam centralizadas dentro da pasta “.kde/share/apps“, também dentro do home. Todas estas pastas que começam com um ponto são vistas pelo sistema como pastas ocultas: para vê-las, você precisa marcar a opção “mostrar arquivos ocultos” no Konqueror.

Esta edição manual dos arquivos é interessante para conhecer melhor o sistema e ter mais controle sobre o que está acontecendo. Mas, por outro lado, ela é trabalhosa e demora até que você consiga dominar um número grande de opções.

A forma mais rápida de personalizar estas configurações é abrir o chroot, logar-se como o usuário desejado copiar as pastas do /etc/skel, rodar o KDE e alterar as configurações desejadas dentro da janela do Xnest e depois salvar as alterações, como vimos anteriormente. A edição manual pode ser usada para corrigir pequenos detalhes e eventuais problemas.

Scripts de inicialização

Depois de instalado, o Kurumin passa a se comportar de forma semelhante a uma instalação do Debian, com os serviços iniciados através de links ou scripts nas pastas “/etc/rcS.d” e “/etc/rc5.d”.

Mas, ao rodar a partir do CD, um único script cuida de toda a configuração do sistema, o “/etc/init.d/knoppix-autoconfig“. Ele roda o “/usr/bin/hwsetup” (a ferramenta de detecção de hardware), executa o “/usr/sbin/mkxf86config” (que faz a configuração do vídeo) e verifica os parâmetros passados durante o boot (como o “noacpi”, “bootfrom=”, “noscsi”, “xserver=vesa” etc.).

No final do script “/etc/init.d/knoppix-autoconfig”, vai o comando “/etc/init.d/kdm start” que inicia o carregamento do modo gráfico. Neste ponto é executado o script “/etc/X11/Xsession.d/45xsession”, que verifica os parâmetros de boot relacionados com o ambiente gráfico (desktop=fluxbox ou desktop=gnome, por exemplo), copia o diretório “/etc/skel” para o “/home/kurumin”, criando o diretório home do usuário padrão do sistema e, por último, carrega o KDE ou outro ambiente gráfico escolhido.

No Knoppix original e em outras distribuições derivadas dele, o carregamento do modo gráfico não é disparado pela abertura do KDM, mas sim diretamente através de uma entrada no arquivo “/etc/inittab”. Na prática isso não faz muita diferença, pois o script “/etc/X11/Xsession.d/45xsession” é executado da mesma forma.

A instalação do Kurumin é feita pelo script “/usr/local/bin/kurumin-install“, que copia os arquivos do sistema para a partição, define senhas e faz outras alterações necessárias.

Ao personalizar o sistema, é importante conhecer a função de cada um destes scripts, pois eles permitem modificar o comportamento do sistema durante o boot e fazê-lo executar funções adicionais. Vamos a alguns exemplos:

Quando você precisar fazer alguma alteração no processo inicial de boot, alterar o comportamento de uma das opções de boot ou criar uma nova (como o “kurumin union=” que adicionei no Kurumin 5.1), alterar a configuração padrão do teclado ou linguagem, ou executar algum comando em especial durante o boot, altere o “/etc/init.d/knoppix-autoconfig”.

Por exemplo, esta é a seção do script que verifica se o parâmetro “kurumin noalsa” foi passado no boot e decide se executará ou não os comandos que detectam e ativam a placa de som:

if checkbootparam “noalsa”; then
echo “Abortando a detecção da placa de som, como solicitado no boot.”
else
if [ -n "$USE_ALSA" -a -x /etc/init.d/alsa-autoconfig ]; then
touch /tmp/modules.dep.temp
[ -n "$SOUND_DRIVER" ] && rmmod -r “$SOUND_DRIVER” >/dev/null 2>&1
case “$ALSA_CARD” in auto*) ALSA_CARD=”";; esac
ALSA_CARD=”$ALSA_CARD” /etc/init.d/alsa-autoconfig
[ ! -r /etc/modules.conf ] && \
ln -sf /KNOPPIX/etc/modules.conf /etc/modules.conf
fi
/etc/init.d/alsa start
# Unmuta o som
aumix -w 80 &; aumix -v 80 &; aumix -m 20 &; aumix -c 80 &; aumix -l 50 &
# Abre as permissões do som para outros usuários:
chmod 666 /dev/dsp
chmod 666 /dev/mixer
fi
Quando você precisa verificar ou alterar algo relacionado com a configuração do vídeo, com a cópia dos arquivos do “/etc/skel” para o “/home/kurumin” ou com as opções de boot que permitem especificar o gerenciador de janelas padrão (kurumin desktop=fluxbox, kurumin desktop=gnome, etc.) procure no “/etc/X11/Xsession.d/45xsession”.

Este é um exemplo de configuração, a parte do script que verifica se foi dada alguma opção no boot para usar o fluxbox, gnome ou outro desktop e, caso contrário, carrega o KDE:

[ -f /etc/sysconfig/desktop ] && . /etc/sysconfig/desktop
export QDESKTOP=$(cat $HOME/.wmrc)
if [[ -n $QDESKTOP && $QDESKTOP != "default" ]]; then
DESKTOP=$QDESKTOP
else
# kde is the default
[ -z "$DESKTOP" ] && DESKTOP=”kde”
fi
Quando precisar alterar algo relacionado com o processo de instalação do sistema, como fazer com que ele se comporte de forma diferente depois de instalado, ou adicionar algum passo adicional na instalação, você pode modificar o instalador, que no caso do Kurumin é o script “/usr/local/bin/kurumin-install”.

Ele é uma evolução do “knx-hdinstall”, o antigo instalador do Knoppix. Atualmente o Knoppix utiliza um novo instalador, que faz um “live-install”, fazendo com que a instalação no HD se comporte da mesma forma que do CD, com o procedimento de detecção de hardware feito a cada boot. É uma idéia diferente de instalação, com alguns pontos positivos e outros negativos.

As versões recentes do Kanotix introduziram um instalador gráfico, com uma interface mais bonita e várias mudanças, que acabou sendo incorporado ao Knoppix como instalador alternativo. Como pode ver, existem outras opções de instaladores, que você pode utilizar na sua personalização.

Como comentei no início deste capítulo, você pode incluir funções adicionais para detectar componentes que não sejam automaticamente ativados pelos scripts padrão. Isto é importante em muitas situações, pois é comum que empresas possuam lotes de impressoras, placas de vídeo ou outros componentes que precisem de alguma configuração adicional para funcionarem. Ao invés de fazer as modificações máquina por máquina, é mais eficiente escrever um script que as faça automaticamente durante o boot do CD.

Você pode encontrar alguns exemplos de funções diversas que uso no Kurumin no arquivo “/usr/local/bin/hwsetup-kurumin“, executado no final do boot, através do comando incluído no final do arquivo “/etc/init.d/knoppix-autoconfig”.

Este arquivo não é muito longo, pois normalmente as entradas antigas vão sendo removidas com o tempo, conforme vão sendo usadas novas versões do hwsetup, com suporte aos novos componentes.

Uma forma simples de detectar componentes durante o boot é através da saída do comando “lspci”. Veja um trecho da identificação que não mude de um modelo de placa para outra e filtre usando um pipe e o grep, de forma a carregar o módulo apropriado caso a entrada seja encontrada. Estes são dois exemplos que usei no Kurumin 5.1 para detectar placas CMI 8738 e a placa de som virtual usada pelo VMware:

cmi=`lspci | grep “CM8738″`
if [ -n "$cmi" ]; then
/sbin/modprobe snd-cmipci
fi

ensonic=`lspci | grep “Ensoniq ES1371″`
if [ -n "$ensonic" ]; then
/sbin/modprobe snd-ens1371
fi
No caso de placas de vídeo, é necessário fazer alterações no arquivo “/etc/X11/xorg.conf”, modificando a linha com o driver usado. No caso de placas com suporte 3D, é muitas vezes necessário também carregar um módulo de Kernel.

A detecção do vídeo é feita pelo script “/usr/sbin/mkxf86config“. Ele detecta a placa de vídeo, monitor e outras informações necessárias e gera o arquivo de configuração do vídeo. Quando ele não conhece a identificação de uma determinada placa de vídeo, é normal que ele use o driver “vesa” que é um driver genérico, que possui um baixo desempenho.

Você pode incluir funções no final do script para detectar a placa usando a saída do lspci e substituir a linha com o driver usando o sed. Este é um exemplo que usei para detectar as placas Intel Extreme, usadas no HP NX6110 e outros notebooks. Colocado no final do arquivo, ele troca o driver de “vesa” para “i810″ quando a placa é detectada. Se o driver já estiver correto, ele não faz nada:

# Detecta as Intel Extreme
# (mais adiante, o próprio script renomeia o arquivo para xorg.conf)
vidintel=`lspci | grep “Intel Corp. Mobile Graphics”`
vidintel2=`lspci | grep “Intel Corporation Mobile”`
vidintel3=`lspci | grep “915GM/GMS”`
if [ -n "$vidintel" -o -n "$vidintel2" -o -n "$vidintel3" ]; then
sed -e ’s/vesa/i810/g’ /etc/X11/XF86Config-4 > /etc/X11/XF86Config-4.1
rm -f /etc/X11/XF86Config-4; mv /etc/X11/XF86Config-4.1 /etc/X11/XF86Config-4
fi
Em alguns casos, detalhes aparentemente simples podem fazer você perder um bom tempo. Um problema que tive nas versões recentes do Kurumin foi com relação com medidor de bateria do KDE. Você configura se ele deve ser ativado ou não durante o boot através da opção “Controle de energia > Bateria do Laptop” dentro do Painel de Controle do KDE e a configuração é salva no arquivo “.kde/share/config/kcmlaptoprc” (dentro do home).

O problema é que ele só é útil em notebooks. Se você simplesmente o deixar ativo na configuração, ele vai ser aberto sempre, mesmo em desktops, onde ele não tenha serventia alguma.

Uma forma que encontrei para tornar a detecção mais inteligente, fazendo com que ele seja habilitado apenas em notebooks, foi incluir uma função dentro do arquivo “/etc/X11/Xsession.d/45xsession” (que, como vimos, é o responsável pela abertura do X e carregamento do KDE), que verifica se o módulo “battery” está ativo (indício que o sistema está rodando num notebook, com bateria) e altera o arquivo de configuração, desativando o medidor de bateria quando necessário:

bateria=`lsmod | grep battery`
if [ -z $bateria ]; then
cd /ramdisk/home/kurumin/.kde/share/config/
sed -e ’s/Enable=true/Enable=false/g’ kcmlaptoprc > kcmlaptoprc2
rm -f kcmlaptoprc; mv kcmlaptoprc2 /kcmlaptoprc
fi

Em alguns casos mais específicos, você pode precisar incluir novas opções de boot.

Mudando a lingua padrão e traduzindo as mensagens de boot

Hoje em dia, quase todos os programas que usamos no dia-a-dia incluem suporte a internacionalização.

No caso do KDE, as traduções para todos os aplicativos base são agrupadas nos pacotes “kde-i18n”, como em “kde-i18n-ptbr” ou “kde-i18n-es” (espanhol), que podem ser instalados via apt-get. Os pacotes não conflitam entre si, de forma que você pode manter vários deles instalados e definir qual será a língua padrão dentro do Kcontrol, junto com a configuração do teclado e outros detalhes.

O suporte a inglês norte-americano vem instalado por padrão e é usado quando configurado, ou quando nenhum outro pacote de internacionalização estiver instalado.

Os demais programas, são configurados através do pacote “locales“. Neste caso, cada programa inclui diretamente as traduções disponíveis e você determina qual será utilizada por padrão e quais outras ficarão instaladas. As demais podem ser removidas automaticamente usando o comando “localepurge“, o que economiza um bocado de espaço.

Para alterar a configuração do locales, use o comando:

# dpkg-reconfigure locales
Para remover os arquivos de internacionalização que não estão sendo usados, execute o:

# localepurge

Além dos aplicativos, existem também as mensagens do sistema, exibidas durante o boot quando o sistema roda a partir do CD-ROM.

Para traduzi-las, você precisa ir diretamente nos dois scripts executados durante o boot, o “linuxrc“, que fica dentro da imagem compactada de boot (o arquivo “boot/isolinux/minirt26.gz”) e o arquivo “/etc/init.d/knoppix-autoconfig”, dentro da imagem principal.

Para chegar ao “linuxrc”, acesse a pasta “/mnt/hda6/knxmaster/boot/isolinux”. Descompacte o arquivo minirt26.gz, crie uma pasta temporária e monte-a dentro da pasta. O “linuxrc” fica logo no diretório raiz. Ao terminar, faça o processo inverso, desmontando e compactando a imagem novamente:

# cd /mnt/hda6/knxmaster/boot/isolinux/
# gunzip minirt26.gz
# mkdir tmp/
# mount -o loop minirt26.gz tmp/
# kedit tmp/linuxrc
# umount tmp/
# gzip minirt26
Para traduzir as mensagens nos dois arquivos, pesquise dentro do arquivo por “echo”, usado para escrever a grande maioria das mensagens exibidas na tela.

Mudando o usuário padrão

O usuário padrão do Knoppix é o “knoppix”, que foi trocado pelo usuário “kurumin” nas versões recentes do Kurumin.

Os passos básicos para trocar o usuário padrão do sistema ao remasterizar o CD são:

1. Edite o arquivo “/etc/passwd”, troque o “kurumin” e o “home/kurumin” pelo nome e o diretório home do novo usuário

2. Edite o arquivo “/etc/shadow” e novamente troque o “kurumin” pelo novo usuário. Este é o arquivo de senhas, que pode ser visto e editado apenas pelo root.

3. Troque o login também no “/etc/sudoers”, que é o arquivo com a configuração do sudo.

4. É preciso trocar o nome do usuário também no arquivo “/etc/kde3/kdm/kdmrc” (para manter o autologin do KDE) e no arquivo /etc/X11/Xsession.d/45xsession.

5. Não se esqueça de mudar todas as ocorrências do login no arquivo “/etc/group” e no arquivo “linuxrc”, dentro da imagem compactada carregada durante a etapa inicial do boot (o arquivo “boot/isolinux/minirt.gz”, que vimos a pouco). Existem também referencias a serem trocadas no script “/etc/init.d/knoppix-autoconfig”

Estas alterações trocam o usuário no sistema, mas falta também fazer as modificações no “/usr/local/bin/kurumin-install”, que é o instalador, assim como em mais alguns scripts dos ícones mágicos. Use o kfind para localizar os arquivos que precisam ser modificados com mais facilidade, procurando por linhas que contenham a string “kurumin”.

 

Criando um DVD de recuperação

Ao alterar os scripts de inicialização, você pode mudar radicalmente o comportamento do sistema, fazendo com que ele execute ações específicas durante o boot. Isso permite criar todo tipo de solução, como CDs de demonstração que rodam programas específicos, CDs de diagnóstico, mini-distribuições com conjuntos personalizados de programas, e assim por diante.

Vamos a um exemplo de como criar um DVD de recuperação, que restaura automaticamente uma imagem previamente criada usando o Partimage, de forma a restaurar o sistema originalmente instalado na máquina, como nos micros de grife. Este DVD de recuperação não se limita a restaurar instalações do Linux: você pode restaurar também instalações do Windows, ou instalações com dois ou mais sistemas em dual boot. A única limitação é a capacidade da mídia usada. Dependendo do tamanho da imagem, o sistema de recuperação pode ser gravado num mini-DVD, ou até mesmo num CD-R.

Comece instalando e configurando o sistema normalmente no micro alvo. Depois de terminar, use o Partimage para gerar uma imagem de cada partição do HD, junto com o backup da MBR e da tabela de particionamento.

Coloque todos os arquivos que serão usados dentro da pasta “knxmaster/” na sua partição de trabalho. Você pode colocar tudo dentro de uma sub-pasta para manter as coisas organizadas, como “knxmaster/image/”. Lembre-se de que os arquivos colocados na “knxmaster/” não são compactados ao fechar a imagem. Por isso, não se esqueça de ativar a compactação do Partimage ao gerá-los.

O próximo passo é fazer com que o DVD passe a restaurar a imagem automaticamente durante o boot, sem intervenção do usuário. A idéia é que o sistema de recuperação seja o mais simples possível, de forma que seja possível restaurar a imagem rapidamente em caso de problemas.

Uma dica é que, ao invés de fazer um DVD de recuperação que chega “chutando o balde”, formatando o HD e deletando todos os arquivos, você pode fornecer os micros com o HD dividido em duas partições: uma com o sistema e outra para dados. O DVD de recuperação pode então restaurar apenas a partição do sistema, sem mexer na partição de dados, dando também a opção de fazer uma restauração completa.

Para que o DVD restaure a imagem durante o boot, precisamos alterar o conteúdo do script “knxsource/KNOPPIX/etc/init.d/knoppix-autoconfig“, dentro da partição de trabalho.

Como vimos, este é o script responsável por toda a etapa inicial do boot, onde o hardware é detectado e o KDE carregado.

O que vamos fazer é colocar os comandos para gravar a imagem e reiniciar o micro no final deste arquivo. Isso fará com que o sistema entre em loop. Ele começa o boot, faz a gravação da imagem de recuperação e em seguida reinicia a máquina, sem nem chegar a abrir o KDE. Você pode incrementar este script adicionando mais opções.

O comando que chama o partimage e regrava a imagem sem perguntar nada ao usuário é:

partimage -f action=2 -b restore /dev/hda1 /cdrom/image/sistema.img.000
shutdown -h now
O Partimage possui várias opções de linha de comando, que você pode estudar através do “man partimage”. O “-b” faz com que o processo todo seja feito automaticamente, sem pedir confirmação e o “-f action=2” reinicia o micro depois da gravação. O “/dev/hda1” é a partição onde a imagem será escrita, enquanto o “sistema.img.000” é o arquivo de imagem colocado dentro da pasta knxmaster. Note que ao dar boot via CD, todo o conteúdo da pasta “knxmaster/” fica acessível através da pasta “/cdrom”, mantendo a mesma estrutura de diretórios.

O “shutdown -h now” abaixo da primeira linha é só pra garantir que o micro vai mesmo reiniciar depois de terminar a gravação. Na verdade ele nem chega a ser usado, pois o próprio comando do Partimage se encarrega de reiniciar no final do processo.

Você pode adicionar as linhas próximo do final do arquivo, logo abaixo das linhas abaixo, que marcam o final da parte de detecção e configuração inicial do sistema:

echo “6″ > /proc/sys/kernel/printk
# Re-enable signals
trap 2 3 11

O final do arquivo ficará assim:

echo “6″ > /proc/sys/kernel/printk
# Re-enable signals
trap 2 3 11

partimage -f action=2 -b restore /dev/hda1 /cdrom/image/sistema.img.000
shutdown -h now

# … seguido pelo restante do script.

Para uma restauração completa do HD, incluindo a MBR e a tabela de particionamento, os comandos seriam:

dd if=/cdrom/image/hda.mbr of=/dev/hda
sfdisk –force /dev/hda < /cdrom/image/hda.sf
partimage -f action=2 -b restore /dev/hda1 /cdrom/image/sistema.img.000
shutdown -h now
… onde o “hda.mbr” é o arquivo com a cópia dos primeiros 512 bytes do HD, gerado usando o dd e o “hda.sf” é a tabela de particionamento, gerada pelo sfdisk; ambas as coisas incluídas na pasta “image/”, junto com a imagem principal.

Note que esta restauração completa vai restaurar o particionamento original do HD, apagando todos os dados. É importante exibir um aviso e pedir duas ou mais confirmações antes de realmente começar o processo. Você pode exibir as mensagens e confirmações usando o dialog, já que elas serão exibidas com o sistema em modo texto.

Caso o HD tenha mais de uma partição (mesmo que vazias), você deve gerar e restaurar a imagem de cada uma usando o partimage.

Depois da modificação, feche o novo ISO, grave o DVD e faça o teste dando boot no micro alvo. Você pode também testar dentro de uma máquina virtual do VMware.

No caso da idéia de oferecer a opção de restaurar apenas a partição do sistema ou fazer a restauração completa, você pode usar um script como o abaixo, que pergunta e executa os comandos apropriados:

dialog –msgbox “Bem vindo o DVD de recuperação do sistema.” 8 50

dialog –yes-label “Sistema” –no-label “Completa” –yesno “Você deseja apenas restaurar a instalação do sistema, ou fazer uma restauração completa, apagando todos os dados do HD? \n
Responda ‘Sistema’ para restaurar o sistema ou ‘Completa’ para fazer a restauração completa.” 10 50

if [ "$?" = "0" ]; then
partimage -f action=2 -b restore /dev/hda1 /cdrom/image/sistema.img.000
shutdown -h now
elif [ "$?" = "1" ]; then
dialog –yesno “Isto vai restaurar o particionamento original, apagando todos os
dados do HD! Tem certeza que quer continuar?”
if [ "$?" = "0" ]; then
dd if=/cdrom/image/hda.mbr of=/dev/hda
sfdisk –force /dev/hda < /cdrom/image/hda.sf
partimage -f action=2 -b restore /dev/hda1 /cdrom/image/sistema.img.000
shutdown -h now
else
shutdown -h now
fi
fi
O Partimage copia apenas os dados dentro da partição para a imagem e ainda compacta tudo. Isso faz com que seja possível colocar uma partição com cerca de 3 GB ocupados (suficiente para uma instalação completa do Ubuntu, Fedora ou Mandriva, ou uma instalação do Windows XP, incluindo alguns programas extras e atualizações) dentro de uma imagem de pouco mais de 1 GB. Mesmo incluindo a imagem do Kurumin, você ainda fica com bastante espaço livre no DVD.

Outra possibilidade é deixar uma partição no final do HD reservada só para armazenar a imagem. As partições Linux não são enxergadas pelo Windows, de modo que o usuário em muitos casos nem vai perceber. Neste caso você precisaria apenas fazer algumas modificações naquelas duas linhas que vão no arquivo /etc/init.d/knoppix-autoconfig. Se você estiver usando a partição “hda5″ para armazenar o backup e ela estiver formatada em ReiserFS, as linhas ficariam:

mount -t reiserfs /dev/hda5 /mnt/hda5
partimage -f action=2 -b restore /dev/hda1 /mnt/hda5/winXP.img.000
reboot
Ao gerar versões especializadas, você pode reduzir o tamanho da imagem principal do sistema, deixando mais espaço livre ou tornando-o mais leve, removendo os pacotes e componentes que não serão utilizados, o que pode ser feito através do próprio apt-get.

A forma mais rápida de remover grandes grupos de pacotes (todo o KDE, todas as bibliotecas do Gnome, todos os programas gráficos, etc.) é procurar por “pacotes âncora”, ou seja, pacotes que são dependências de grandes grupos de pacotes. Removendo o pacote inicial, você remove de uma vez todos os pacotes que se apóiam sobre ele.

Para remover de uma vez quase todo o KDE e aplicativos, por exemplo, remova o pacote “kdelibs-data”:

# apt-get remove kdelibs-data

Para remover todos os aplicativos do Gnome e outros aplicativos baseados na biblioteca GTK2 (útil caso você queira fazer uma personalização com apenas programas do KDE), remova o pacote “libgtk2.0-0″ (note que o número da versão varia), como em:

# apt-get remove libgtk2*

Muitos aplicativos aparentemente “independentes”, como o Firefox, Thunderbird, Acrobat Reader e Mplayer utilizam o GTK2 e são removidos juntamente com ele, por isso analise bem a lista de pacotes que serão removidos antes de continuar.

Para remover de uma vez todos os programas gráficos, remova o pacote “xlibs-data”. Esta medida extrema pode ser útil em casos específicos, onde é usado apenas algum utilitário de modo texto específico, como no nosso exemplo do DVD de recuperação com o partimage.

# apt-get remove xlibs-data

 

Criando seus própios pacotes .deb

Em muitas situações, é preciso instalar softwares compilados manualmente, adicionar firmwares ou arquivos diversos necessários para ativar determinados componentes, expandir a funcionalidade de alguns programas específicos, modificar o conteúdo de pacotes já instalados no sistema, ou mesmo instalar novos scripts e utilitários em geral.

Embora a solução mais simples seja sair copiando diretamente os arquivos e modificando o que for necessário, esta não é exatamente uma boa idéia do ponto de vista da manteneabilidade. Com o tempo, você vai esquecer parte das alterações feitas, fazendo com que o sistema fique cheio de arquivos e configurações que não são mais usados, ou que conflitem com outros componentes instalados.

A melhor forma de adicionar novos componentes é sempre através de pacotes, instalados através do apt-get ou dpkg. Quando o componente não é mais necessário, você simplesmente remove o pacote e todos os arquivos relacionados a ele são apagados, de forma rápida e limpa. Em algumas situações, pode ser necessário também modificar o conteúdo de um pacote existente, seja para corrigir dependências marcadas incorretamente, ou mesmo para corrigir eventuais problemas com os arquivos contidos nele, modificando o conteúdo de pacotes gerados através do checkinstall, por exemplo.

Os pacotes do Debian, nada mais são do que arquivos compactados, que contém a árvore de arquivos e diretórios que serão instalados e um conjunto de arquivos de controle, que contém informações sobre o pacote e (opcionalmente) scripts que são executados antes e depois da instalação ou remoção. Quando o pacote é instalado, o apt-get ou dpkg simplesmente descompacta o arquivo e copia os arquivos para o diretório raiz, mantendo a mesma estrutura de pastas usada no pacote.

A moral da história é que é muito mais pratico instalar programas através de um pacote .deb do que seguir uma receita no estilo “descompacte, copie o arquivo, x para a pasta y, depois edite o arquivo k”. É um formato muito mais prático para disponibilizar programas e atualizações.

Ao criar seus pacotes, o primeiro passo é criar uma pasta contendo a estrutura de diretórios e arquivos que fazem parte do pacote. Ferramentas como o checkinstall e o dpkg-deb fazem isso automaticamente.

Tome cuidado para não incluir arquivos que façam parte de outros pacotes, pois (além da mensagem de erro exibida ao instalar), ao remover seu pacote, todos os arquivos referentes a ele são deletados, deixando o sistema desfalcado. Caso seu programa precise de arquivos externos, prefira sempre colocar os pacotes que os provém como dependências.

Dentro da pasta com os arquivos do pacote, existe também uma pasta DEBIAN (em maiúsculas mesmo), que armazena os arquivos de controle. O principal (cuja presença é obrigatória em qualquer pacote .deb) é o arquivo “control” onde vão as informações de controle do pacote.

Este é o arquivo “control” do pacote mozilla-firefox:

Package: mozilla-firefox
Version: 1.5.dfsg+1.5.0.1-1
Section: web
Priority: optional
Architecture: all
Depends: firefox
Installed-Size: 96
Maintainer: Eric Dorland <eric@debian.org>
Source: firefox
Description: Transition package for firefox rename
Package to ease upgrading from older mozilla-firefox packages to the
new firefox package.
.
This package can be purged at anytime once the firefox package has
been installed.
Destes campos, os únicos realmente obrigatórios são “Package” (que contém o nome do pacote, que não pode conter pontos ou outros caracteres especiais), “Version” (a versão), “Archteture” (a plataforma a que se destina, geralmente i386), Maintainer (o nome e e-mail do mantenedor do pacote, no caso você), “Depends” (a lista de dependências do pacote, com os nomes dos pacotes separados por vírgula e espaço) e “Description”, onde você coloca um texto dizendo resumidamente o que ele faz.

O campo “version” é um dos campos importantes, pois é por ele que o apt-get vai se orientar na hora de instalar o pacote. Se você lançar uma atualização do pacote mais tarde, o campo deve ser alterado. Um pacote com versão “1.1″ é visto como uma atualização para o pacote de versão “1.0″, por exemplo.

Tome cuidado ao usar o campo “Depends”, pois marcar as dependências incorretamente pode trazer problemas para quem vai utilizar seu pacote. Deixar de marcar pacotes que são necessários, vai fazer com que muita gente instale seu pacote sem ter alguns dos outros componentes necessários, fazendo com que ele não funcione. Por outro lado, incluir um número grande de dependências vai fazer com que seu pacote seja problemático de instalar, ou mesmo seja removido em futuras atualizações do sistema, quando algum dos outros pacotes de que depende ficar indisponível, ou mudar de nome.

Ao indicar uma dependência, você pode exigir uma versão mínima, como em:

Depends: konqueror (>= 4:3.5.0-1), python

Neste exemplo, o pacote exige a presença do Konqueror 3.5.0-1 ou mais recente, junto com qualquer versão do Python, o que é muito diferente de usar:

Depends: konqueror (= 4:3.5.0-1), python (= 2.3.5)

Neste caso, você está exigindo versões específicas dos dois pacotes, o que faz com que seu pacote seja automaticamente removido caso um dos dois seja atualizado para uma versão mais recente.

Se o usuário realmente precisar do seu pacote, vai acabar forçando a reinstalação, ou vai tentar reinstalar as versões antigas do Konqueror e/ou Python, o que vai acabar levando a problemas muito mais graves. Ou seja, a menos que absolutamente necessário, jamais exija uma versão específica; use sempre o “>=” para indicar uma versão mínima, ou apenas o nome do pacote, para deixar a versão em aberto.

Você pode adicionar também os campos “Section” (que diz a seção, dentro do gerenciador de pacotes em que o pacote será classificado) e “Priority” (o nível de prioridade do pacote, entre extra, optional, standard, important e required). Normalmente, qualquer pacote “não essencial” é marcado como “extra” ou “optional”.

Este é mais um exemplo de arquivo control, usado no pacote dos ícones mágicos do Kurumin:

Package: icones-magicos
Priority: optional
Version: 6.0
Architecture: i386
Maintainer: Carlos E. Morimoto <morimoto@guiadohardwarwe.net>
Depends: kommander, xdialog
Description: Painéis e scripts do Kurumin.
Para criar um pacote manualmente, contendo, scripts, firmwares, documentação ou arquivos diversos, crie uma pasta contendo todos os arquivos que serão copiados, reproduzindo a estrutura de pastas da forma como serão copiadas para o diretório raiz, crie a pasta “DEBIAN” e inclua o arquivo control com as informações sobre ele.

Depois de preencher o arquivo “DEBIAN/control” e verificar se todos os arquivos estão nos lugares corretos, use o comando “dpkg-deb -b” para gerar o pacote. Basta fornecer o diretório onde estão os arquivos do pacote e o nome do arquivo que será criado, como em:

# dpkg-deb -b IconesMagicos/ icones-magicos_6.0.deb

Ao examinar o arquivo gerado usando o Kpackage ou outro gerenciador, você verá que a descrição os arquivos correspondem justamente ao que você colocou dentro da pasta.

Você pode também alterar um pacote já existente, o que é especialmente útil para “arrumar” pacotes gerados automaticamente através do checkinstall, corrigindo a localização de arquivos ou alterando a descrição ou lista de dependências do pacote.

Para extrair um pacote, use o comando “dpkg -x”, informando o pacote e a pasta destino, como em:

# dpkg -x mozilla-firefox_1.5.dfsg+1.5.0.1-1_all.deb firefox/

Este comando extrai apenas os arquivos do programa, sem incluir os arquivos de controle. Para extraí-los também, crie a pasta “DEBIAN” dentro da pasta destino e use o comando “dpkg -e”, como em:

# dpkg -e mozilla-firefox_1.5.dfsg+1.5.0.1-1_all.deb firefox/DEBIAN/

A partir daí, você tem a árvore original do pacote dentro da pasta. Depois de fazer as alterações desejadas, gere o pacote novamente, usando o “dpkg -b”:

# dpkg -b firefox/ mozilla-firefox.deb

 

fonte: Guia do Hardware.net