Ressuscitando um “laptossauro”

laptossauro.jpgPor causa do meu projecto do Híbrido, fui buscar um fóssil ao armário. É um portátil com CPU 486 a 33MHz 75MHz, 16MB de RAM, e uns fantásticos 300MB 340MB de disco. Não tem bateria, nem CD-ROM, nem qualquer interface de rede. Mas gosto dele assim, o que se há-de fazer?😉

daqfossil.jpg

Para o acompanhar, tenho também uma placa de aquisição de dados PCMCIA “Advantech DACpad-71A” (a.k.a. PCIA-71A), com 8 entradas analógicas de 12bits de alta sensibilidade e 4 entradas e saídas digitais TTL. É da mesma época, e ainda bem, pois isso significa que ocupa uma quantidade de recursos ridícula, e ainda por cima o hardware está muito bem descrito no manual, permitindo construir um “driver” se for necessário.

 

Tenciono usar estas duas peças como controlador laboratorial do meu motor eléctrico de tracção construído em casa. 75MHz devem chegar perfeitamente para controlar um motor trifásico, talvez até com alguma “fuzzy logic” lá para o meio…😉

Agora tenho um problema: que raio de sistema operativo vou meter em 300MB de disco????

Aqui há uns tempos atrás, experimentei pela piada uma distribuição Linux única no seu género: é apenas um livro. Chama-se “LFS” (Linux From Scratch) e consiste apenas num livro de instruções.

Esse livro ensina passo a passo como construir um sistema Linux, desde o download do código-fonte de cada um dos componentes até à configuração, compilação, e instalação dos mesmos. Desde o nada, até ter um sistema utilizável. Muito didáctico. Uma das vantagens é que podemos construir um sistema precisamente à nossa medida, tão pequeno ou grande quanto quisermos…

Apesar de ter sido uma experiência interessante, é uma trabalheira que não quero repetir!!!🙂 Felizmente, há um outro projecto baseado nesse, o “ALFS” (Automated LFS) que supostamente produz o sistema automaticamente quando lhe alimentamos o livro do LFS.Para complicar mais ainda a minha situação, o portátil é um 486 e a minha máquina é x86_64…. ou seja, vai ter de ser uma “cross-compilation”. Mais uma vez eles já pensaram nisso: também existe um livro “CLFS” (Cross-LFS) para estes casos. Portanto, é só alimentar o CLFS ao ALFS, e o sistema aparece sozinho… certo?😉

Bom, depois de uma longa jornada cheia de peripécias, lá consegui que o ALFS regurgitasse um sistema correcto (depois de algumas machadadas na Makefile). A vantagem deste método é que temos controlo total sobre a produção do sistema, e, uma vez a funcionar, fica automatizado. Não vou aqui demorar-me sobre os pormenores, digo apenas que há dois pontos falhados no ALFS que tive de corrigir à mão: o processamento do pacote “linux-2.6.4” (falta o “unpack” respectivo), e o “chroot” que não está imune à arquitectura da máquina anfitriã, envenenando o sistema de compilação “cross” e também o sistema final com binários incompatíveis com 486. Acabei por usar o célebre “uname_hack“, pois o “setarch” não chegou.

No entanto, o sistema produzido automaticamente (na minha directoria “target”) inclui todo o ambiente de “cross-compiling” e tem ainda um tamanho demasiado grande para os meus requisitos:

vasco@thechair: du -sch target
1,2G target

Removendo os “andaimes”da construção, deixamos apenas o sistema final:

vasco@thechair: mkdir collateral
vasco@thechair: sudo mv target/cross-tools collateral/
vasco@thechair: sudo mv target/sources collateral/
vasco@thechair: sudo mv target/jhalfs collateral/
vasco@thechair: sudo du -sch target/
434M    target/

Ok, assim faz mais sentido; o sistema final tem pouco mais de 430MB de tamanho.

A seguir, há que aplicar um pouco de liposucção aos binários:

vasco@thechair: find target/{,usr/}{bin,lib,sbin} -type f -exec strip --strip-debug '{}' ';'
vasco@thechair: du -sch target/
354M   target/

Mais uma passagem com o bisturi:

vasco@thechair: find target/{,usr/}{bin,sbin} -type f -exec strip --strip-all '{}' ';'
vasco@thechair: du -sch target/
351M   target/

E estamos nos 351MB. Bom, parece que não dá mais que isto. Mas eu ainda preciso de tirar 100MB. Agora é mesmo cortar na carne.🙂

A “/usr/share” parece um bom sítio para fazer limpeza…

vasco@thechair: du -sch target/usr/share/*
468K    usr/share/aclocal
152K    usr/share/aclocal-1.10
1,4M    usr/share/autoconf
1,1M    usr/share/automake-1.10
80K     usr/share/awk
264K    usr/share/bison
4,0K    usr/share/doc
20K     usr/share/et
1,6M    usr/share/file
20K     usr/share/getopt
1,6M    usr/share/gettext
3,8M    usr/share/groff
8,9M    usr/share/i18n
4,0K    usr/share/info
1,9M    usr/share/libtool
34M     usr/share/locale
4,0K    usr/share/man
4,0K    usr/share/misc
12K     usr/share/ss
20K     usr/share/tabset
6,3M    usr/share/terminfo
36K     usr/share/texinfo
19M     usr/share/vim
5,5M    usr/share/zoneinfo
85M     total

É a documentação, claro. Bom, não tenciono precisar dela neste sistema. Se tiver dúvidas, posso puxar um “man” noutra máquina. Toca a remover esse texto todo. Eu podia comprimi-lo, e a coisa continuava a funcionar, mas tenho mesmo de ser radical.

vasco@thechair: rm -rf target/usr/share/doc/*
vasco@thechair: rm -rf target/usr/share/man/*
vasco@thechair: rm -rf target/usr/share/info/*
vasco@thechair: du -sch target/*
2,9M    /bin
1,6M    /boot
4,0K    /dev
1,4M    /etc
4,0K    /home
21M     /lib
12K     /media
4,0K    /mnt
4,0K    /opt
4,0K    /proc
8,0K    /root
4,0M    /sbin
4,0K    /srv
4,0K    /sys
20K     /tmp
250M    /usr
64K     /var
280M    total

Ok, 280MB ainda não são os 250MB que eu tinha previsto, mas já dá para começar.🙂 Se realmente precisar, posso também remover tudo o que não é necessário dentro de “usr/share/locale” e ainda poupo mais 30MB.

Ora cá está um sistema Linux sem “X”, completo com ambiente de compilação, cabendo em 280MB. Não está mal, para um sistema totalmente actual e não baseado em “busybox“.🙂

~ por Vasco Névoa em Março 28, 2008.

10 Respostas to “Ressuscitando um “laptossauro””

  1. Assumo que os binários estejam “stripped”, certo?

    Se calhar não perdias assim tanto em ir para um sistema “baseado em busybox”, e ficavas com bastante mais espaço de disco para dados… como tu bem sabes, hoje em dia mesmo um linux embebido já vive de 16MB de RAM, imagino como não vai ser esse laptossauro…. ainda para mais sem espaço para memória virtual (ou seja, um sistema embebido ;)).

    • Hola,

      my nombre es Rebecca, soy una estudiante de biologia de alemana. Estoy trabajando con el Advantech DACpad-71A, desafortunadamente no tengo el instrucciones para el manejo. Para lo necessito muy acuciante! So, quiero saber si tu tienes el instrucciones para el manjo y si hay alguna posibilidad que me puedes darlo? Puedes fotocopialo or digitalizarlo??? Lo siento para mi malo espanol…Si prefieres puedo escribirte en ingles tambien…Puedes ayudarme mucho mucho…

      Gracias,
      Rebecca!

  2. MINIX está fora de questão?
    http://www.minix3.org/

  3. Sim, o stripping foi feito logo nas 2 primeiras operações do artigo… (parece que ninguém tem mesmo paciência para ler o que escrevo… pá, caguei, eu sou mesmo assim!😉 )

    Acho que és capaz de ter razão; mas como não encontrei nenhum sistema de produção de “Embedded OS” tão fácil de usar e rápido de obter resultados como o LFS, fiquei mesmo por aqui. Por outro lado, quero poder compilar qualquer tipo de SW nesta máquina, e por isso quero o kernel e SW de última geração nela. A maior parte dos embebidos estão presos ao Linux 2.4, e duvido que a uLibc e afins sejam tão flexíveis assim… Ah, e esta máquina tem swap, sim sr.!… outros 16MB!!!🙂

  4. Eh pá, pois, sorry, eu ler commandos só se tiver mesmo que ser :)!

    O kernel 2.6 já vem com os “patches” para “embedded” (tá tudo entre aspas que não sei as designações correctas).

    Já que tiveste o trabalho de montar o cross-compiler na tua outra máquina, também o deves poder usar para compilar outro software; digo-te isto na mesma porque mesmo não indo tu agora mudar isso para um kernel embedded, pode ser que ainda te venha a dar jeito (com 20-16MB livres de espaço, é capaz de ser muuuuito dificil compilares qualquer coisa não-trivial nessa máquina…).

  5. A título de curiosidade podes dar uma vista de olhos ao DSL (http://damnsmalllinux.org/).
    -> fully functional desktop in a small footprint of 50MB.
    Claro que podes optar por não correr o X (com o X os requisitos mínimos de RAM são 20MB) – http://damnsmalllinux.org/wiki/index.php/Minimum_Hardware_Requirements

  6. Tive de recompilar o kernel porque me esqueci de incluir o suporte para discos IDE e sistema de ficheiros EXT2 embutido… hehehe… e como não tem uma imagem “initrd”, o tipo não conseguia montar o rootfs.🙂
    Aproveitei então a oportunidade para remover ainda mais tralha do kernel, de tudo aquilo que a máquina não suporta (USB, PCI, networking, etc) e lá libertei mais 30MB em módulos.🙂

  7. Mouro: era mesmo o DSL que lá estava, antes deste.🙂 Não foi muito à bola com o HW do bicho… mas funcionava.

    O meu objectivo era mesmo ter uma máquina compatível com qualquer SW moderno, e poder compilar pequenas aplicações. Por isso o DSL não dava. Tinha de ser uma distro configurável.

  8. Paulo A. Silva: hehehe, tive de resgatar o teu comentário das garras do spam filter…

    Sim, Minix podia ser uma opção. Obrigado pela sugestão! Com essa fizeste-me lembrar a discussão “micro/macro-kernel” dos tempos da criação do Linux.

    Poderei um dia enveredar por aí, mas por agora sinto-me muito confortável a desenvolver SW no quentinho do Linux.😉 Já começo a conhecer as manhas ao kernel, e não tenho tempo para divergir demasiado (projectos já tenho muitos!)🙂

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

 
%d bloggers like this: