Compilacion en masa

En la entrada Emergiendo expliqué como generar un entorno de compilación cruzada basado en Gentoo para poder compilar cosas para nuestro disco duro, pero luego, en FTP-ando, eché todo por tierra al no poner binarios creados por mí. Ahora ya he sido capaz de compilar, así que, para los impacientes, aquí está el paquete con las últimas versiones de CTorrent (3.2.2), BFTP (2.6) y YAOD (0.7.2). Las instrucciones de instalación son las mismas que en el artículo anterior (FTP-ando). Como gran ventaja, algunos fallos de BFTP han desaparecido, y encima la tasa de transferencia ha subido a 3MBytes/seg.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Pasando ya a la chicha, la razón de que haya tardado tanto es que la cosa no es tan sencilla, por varias razones:

  • Para empezar, el disco duro tiene su propia versión de la uClibc, por lo que la única manera de garantizar que un programa funcione correctamente es compilarlo contra esa misma versión.
  • Por otro lado, en algunas versiones del compilador GCC cambia el fomato binario de las bibliotecas en C++, por lo que también es conveniente utilizar la misma versión de compilador GCC: para garantizar que la interfaz binaria entre la aplicación y las bibliotecas es la misma.
  • Por último, muchos paquetes no se pueden instalar en un sistema mediante compilación cruzada porque su configure hace cosas raras, como comprobar si GCC compila correctamente un programa de prueba… programa que estará en arquitectura MIPS y, por tanto, no correrá en un Intel, abortando el proceso de compilación.

Y si ya la cosa se veía complicada, encima nos encontramos con que Gentoo no tiene la versión de GCC utilizada en nuestro disco duro (la 3.4.4), y que algunas versiones de uClibc (entre ellas la 0.9.28.3, la de nuestro disco duro) no compilan con según qué compiladores o versiones de binutils. El resultado era desalentador.

La primera idea que consideré para resolver el problema fue meter un sistema Gentoo completo en el disco y ejecutar en él las aplicaciones usando chroot. Por desgracia esta solución es muy ineficiente porque necesita mucho espacio en disco y porque las aplicaciones sólo tendrían acceso a los directorios contenidos dentro del chroot, pero nunca a los de fuera.

La segunda idea consistía en intentar generar un conjunto nativo de compilador GCC, binutils y biblioteca uClibc con las versiones correctas a partir de fuentes oficiales. Por desgracia, el proceso es demasiado complejo y tampoco funciona con todas las versiones de GCC, binutils y uClibc que interesaba.

La tercera idea era usar BuildRoot, el entorno de generación de compiladores cruzados de BusyBox. Por desgracia, una vez más, no sólo no tenía las versiones necesarias, sino que tampoco compilaba cualquier combinación.

Por último, la cuarta, que ha sido la que decidí emplear, consiste en compilar estáticamente los programas deseados utilizando un compilador nativo en el propio disco duro multimedia. De esta manera, al no depender de ninguna biblioteca de enlazado dinámico, el programa funcionará en cualquier sistema, ahorrándonos el problema de la incompatibilidad de versiones. Además, al no importar la versión de binutils, GCC ni uClibc, podemos utilizar versiones más modernas, que siempre tendrán mayor seguridad y fiabilidad. Por último, al compilarse en el sistema de manera nativa, no habrá problemas con ficheros configure que hagan cosas «raras». Como inconveniente, necesita más memoria que un programa compilado dinámicamente.

Sin embargo, seguía con el problema de conseguir un toolchain para MIPS que funcionase correctamente, cosa compleja porque en Gentoo hay nueve versiones de GCC, cuatro de binutils y tres de uClibc (sin contar revisiones), y no todas las combinaciones compilan. Además, no bastaba con el toolchain, sino que también necesitaba instalar en nativo Bash, GCC, binutils, uClibc, make y el entorno básico con BusyBox. ¿Por donde empezar? Por desgracia la versión más reciente no compilaba, y no podía probar las 108 combinaciones posibles… O al menos, no a mano, así que hice un pequeño script en python que probase a compilar todas las posibles combinaciones. Lo dejé una noche, y el resultado fue que sólo compilaba con el GCC 3.4.6-R2 y GCC 4.1.2, las Binutils 2.18-R4, 2.19.1-R1 o 2.20, y sólo con uClibc 0.9.30.1-R1. En el resto de casos, o fallaba la generación del toolchain para compilación cruzada, o fallaba la compilación de las utilidades nativas.

Una vez descubiertas las versiones, sólo fue necesario generar un toolchain adecuado para compilación cruzada:

crossdev --target mipsel-unknown-linux-uclibc --without-headers --gcc 4.1.2 --binutils 2.20 --libc 0.9.30.1-r1
emerge-wrapper --init

Luego, compilar e instalar las aplicaciones básicas necesarias para poder compilar (lo he cortado por razones de espacio, pero es una única línea):

emerge-mipsel-unknown-linux-uclibc  =binutils-2.20 =gcc-4.1.2 =uclibc-0.9.30.1-r1 bash make gzip bzip2 
unzip tar gnuconfig m4 sys-apps/texinfo gawk coreutils sed grep shadow procps net-tools iputils 
debianutils cpio attr sys-apps/acl kbd nano less diffutils

Vemos que instalamos las mismas versiones de binutils, gcc y uclibc que las usadas para generar la cadena de compilación cruzada. Instalamos coreutils y demás en lugar de busybox (o system) porque las utilidades de éste son versiones recortadas y dan problemas con algunas compilaciones. También instalamos tar, gnuconfig, m4 y texinfo, los cuales serán necesarios para instalar autoconf, automake y libtool. La razón de no instalar estos últimos directamente es que la instalación de Perl por compilación cruzada no funciona; tendremos que hacerlo luego a mano.

Por último, creamos los directorios /proc, /dev y /sys en /usr/mipsel-unknown-linux-uclibc, y ya podemos comprimir ese directorio utilizando

tar -cpvf buildchain.tar /usr/mipsel-unknown-linux-uclibc

copiarlo en el disco duro, en /tmp/hdd/volumes/HDD1, descomprimirlo, y lanzar un entorno de compilación utilizando este script, que automáticamente montará mediante bind los directorios del sistema y utilizará chroot para cambiar al nuevo entorno. Ahora nos bajamos Perl, lo descomprimimos y lo compilamos con

sh Configure -de
make
make install

Cabe recordar que el procesador de este disco duro es MUY LENTO, por lo que es posible que necesite toda la noche para compilarlo. Por otro lado, podemos tener problemas con las fechas de los archivos, por lo que es fundamental cambiarlas utilizando el comando touch * en cada directorio. Esto se puede hacer más cómodamente con la línea

find -type d -exec touch {}/* ;

que hará un touch * de manera recursiva en cada directorio. Una vez hecho esto, instalamos autoconf, automake y libtool (no olvidarse de touch en cada uno), y ya tendremos nuestro sistema de desarrollo completo con el que podremos compilar cualquier utilidad. Sólo hay que tener en cuenta algunos detalles:

  • El procesador del disco duro no es gran cosa, así que la compilación tarda BASTANTE tiempo
  • Es fundamental añadir la opción -static en las opciones de enlazado. En algunos programas es posible hacerlo añadiendo LDFLAGS=-static justo antes de ./configure (ejemplo: para configurar ctorrent, la línea sería LDFLAGS=-static ./configure); otra opción es lanzar primero ./configure y luego editar el Makefile para añadirlo donde se defina LDFLAGS. Como opción final, se puede compilar normalmente y, cuando termine, copiar y pegar las líneas de enlazado (suele ser la última) y añadir -static a mano antes de ejecutarla.
  • Es muy recomendable eliminar el parámetro -g durante la compilación, pues lo que hace es añadir información de depuración totalmente innecesaria, además de impedir que el compilador pueda aplicar muchas optimizaciones. Para hacer esto no queda más remedio que editar manualmente el fichero Makefile (no olvidar que puede haber varios Makefiles en otros subdirectorios. Hay que editarlos todos). También es bueno utilizar el comando strip en el ejecutable final para eliminar los últimos restos de datos de depuración
  • Algunos programas están preparados para versiones de autoconf o automake anteriores a la que hemos instalado. En ese caso basta con hacer un autoreconf para regenerar los ficheros. Este debe hacerse después de autogen.sh si lo hubiera. Una vez hecho esto ya se puede ejecutar ./configure y make.
  • Es necesario ajustar las fechas de los archivos porque, si no, Make se lía y no sabe qué compilar. Para ello basta con ejecutar el comando touch * en todos y cada uno de los directorios del programa a compilar (la línea find -type d -exec touch {}/* ; lo hará de manera recursiva por nosotros). No recomiendo cambiar la hora del disco duro porque, por alguna razón, las veces que lo hice el sistema se volvió inestable, llegando a colgarse incluso.
  • En algunos programas, libtool «se vuelve loco» y empieza a lanzar copias de sí mismo indiscriminadamente, llegando a ahogar al procesador y colgando el disco duro. Si, cuando va a enlazar el código, un PS nos devuelve una gran cantidad de procesos libtool, hay que matarlos rápidamente y enlazar «a mano» el código.

Para aquellos que no quieran pasar todo el trabajo, pueden bajarse el entorno de compilación completo aquí. Basta con descomprimir el .zip, copiar el .tar en el directorio /tmp/hdd/volumes/HDD1 del disco duro y descomprimirlo mediante

tar -xpvf buildchain_1.0.tar

entrar en el directorio con cd buildchain, montar los sistemas de archivos virtuales (proc, dev y sys) con ./mount.sh y lanzar un chroot con ./launch.sh. Una vez se haya terminado, salir y desmontar los sistemas de archivos virtuales con ./umount.sh.

El koala kármico

Hace unos días ya que salió la nueva Ubuntu 9.10, Karmic Koala, y hay que reconocer que no supone un cambio muy agresivo con respecto a la versión anterior, por lo que podría decir que ni me gusta ni me disgusta.

Bueno, miento; sí hay un detalle que no me gusta nada: los iconos de los botones y del menú de sistema han desaparecido por completo. Al principio pensé que era un bug en PyGTK, porque en DeVeDe no mostraba ya los iconos en los botones de Añadir, Eliminar, Arriba… Sólo lo mostraba en Previsualización porque lo había puesto «a mano», al no haber un botón de stock adecuado. Sin embargo, luego descubrí que, por alguna extraña razón, en el nuevo Gnome 2.28 se han desactivado por defecto dichos iconos. La verdad es que no me gusta la idea, porque creo que combinar un icono con un texto ayuda a hacer las aplicaciones más intuitivas.

Afortunadamente es muy sencillo dejar todo como estaba; basta con abrir un terminal, escribir gconf-editor (seguido de la tecla Return), ir a / -> desktop -> gnome -> interface y activar las dos claves siguientes:

Y listo, volveremos a tener iconos en el menú de sistema y en los botones de las aplicaciones.

Aniversario

Pues resulta que justo hoy, jueves 22 de octubre, hace nada menos que diez años que abandoné por completo OS/2 e instalé de manera definitiva Linux como mi sistema de trabajo. Para los que crean que voy de farol, aquí está la prueba.

No fue una decisión hecha a la ligera, sino que ya llevaba una temporada sopesándola. La razón definitiva fue el rumor (que acabó por confirmarse) de que IBM abandonaba OS/2: no tenía ningún sentido seguir con un sistema que, aunque mucho mejor que Windows 95/98 y que el Linux de aquella época, no tenía ningún futuro.

En realidad, no era la primera vez que usaba Linux. De hecho, ya llevaba casi cuatro largos años jugando con él, primero con una Slackware 3.0 que regalaron en la PC Actual, luego una Slackware 96, y finalmente una RedHat, que fue la que me convención para quedarme. Al principio utilizaba como gestor de ventanas WindowMaker, aunque poco después me pasé a Gnome 1.4. En aquellos tiempos mi mantra era «recompila tu kernel». ¿Te fallaba un programa? «Recompila tu kernel». ¿No te reconocía un periférico? «Recompila tu kernel». ¿Mi niño no me come? «Recompila tu kernel».

Con RedHat estuve un par de años hasta que la infame RedHat 7.0 me hizo perder la paciencia y varios archivos, al empeñarse en activar el UltraDMA de mi disco duro a pesar de que el chipset tenía un bug que podía provocar pérdidas de datos.

Decidí entonces darle una oportunidad a Debian, de cuyo gestor de paquetes APT me habían hablado maravillas. Tenía unos CDs de Potato (2.2), pero en aquel momento la versión estable era Woody (2.3). Como no tenía de donde bajarme rápidamente la nueva versión, decidí instalar la vieja y actualizar por Internet… ¡con un Modem de 56K! Locuras de juventud… 🙂 Con ella estuve unos años, hasta que, unos años después, me cambié a Ubuntu, en parte porque era la única manera de tener un Gnome a la última sin riesgo de que un casque en los paquetes por usar Debian SID te deje dos días sin sistema. Y con ella me quedé, aunque sí es cierto que un par de años después hice un par de tímidos intentos con Gentoo, los cuales, sin embargo, no llegaron a buen puerto: necesitaba 24 horas sólo para compilar el sistema básico más Gnome en mi Duron 1300, y era un peñazo cada vez que quería añadir un programa.

FTP-ando

Actualizado; el enlace a los binarios estaba mal.Tras curiosear y probar, ya he conseguido meter un nuevo cliente de BitTorrent y un servidor de FTP en mi disco duro, aunque, por diversas razones (que comentaré en otra entrada), el código proviene de la página del MediaPlayer RTD1261, en lugar de haber sido compilado con la Gentoo que comentaba en entradas anteriores.

El nuevo servidor BitTorrent es cTorrent, junto con la interfaz web yodctcs. Respecto al servidor FTP, se trata de bftpd. Básicamente he retocado las configuraciones para que todo funcione sin tener que meter ficheros en carpetas del directorio raíz (por ejemplo, en /etc o en /lib). La razón es que, por defecto, toda esa parte (que está almacenada en la Flash) se monta en modo sólo-lectura; pero aunque pudiese escribir, sería bastante arriesgado (un error y tendré un caro pisapapeles), por lo que mi intención es hacer cualquier cambio únicamente en el disco duro, en donde se pueda recuperar todo simplemente ejecutando la opción de formateo desde el menú principal.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Avisados estáis.

Lo primero es copiar el contenido del fichero con los binarios (este) en el disco duro multimedia, en concreto el fichero upgrade.tar. En él están todos los binarios y ficheros de configuración.

Una vez que lo tenemos (en /tmp/hdd/volumes/HDD1) entramos por telnet, lo movemos a /tmp/hdd/root y lo descomprimimos en esa carpeta con tar -xpvf upgrade.tar, de manera que se conserven los permisos de los ficheros. Dentro hay cuatro carpetas y un fichero script:

  • etc: contiene los ficheros de configuración del cliente BitTorrent y del servidor FTP
  • bftpd: contiene los binarios del servidor FTP
  • ctorrent: contiene los binarios del cliente BitTorrent cTorrent y de su interfaz web dctcs
  • lib: contiene las bibliotecas libgcc_s.so y libstdc++.so, necesarias para dctcs
  • btpd: reemplaza al script original.

El script btpd permite lanzar y parar todos los nuevos servicios de manera selectiva, relanzando aquellos procesos que queremos que estén lanzados si se caen, y matando los que no queremos si, por la razón que sea, se ejecutan (todo esto es posible porque el disco duro ejecuta regularmente este script, junto con el de samba, con el comando start). También monta, si se desea, la partición principal como EXT3. Por último, asigna a la variable de entorno LD_LIBRARY_PATH el valor /tmp/hdd/root/lib de manera que los programas lanzados desde él puedan utilizar las bibliotecas aunque éstas no se encuentren en los directorios por defecto (/lib, /usr/lib o /usr/local/lib). Es necesario editar este script (por ejemplo, con vi) para ajustar la configuración a nuestras necesidades. En concreto, si lo abrimos, vemos al principio lo siguiente:

# change here to set the services you want:
# 1: launch it
# 0: don't launch it

# main partition in EXT3 format
HD_EXT3=1

# old BitTorrent service
OLD_BT=0

# new BitTorrent service (cTorrent)
NEW_BT=1

# FTP server
FTP=1

Así, si queremos utilizar el cliente de BitTorrent original, tenemos que almacenar un 1 en OLD_BT. Si queremos utilizar el nuevo cliente BitTorrent, ponemos un 1 en NEW_BT. Si queremos activar el servidor FTP ponemos a 1 FTP. Y si hemos formateado en EXT3 la partición principal del disco duro, entonces tenemos que poner a 1 HD_EXT3 (si la tenemos en NTFS es imprescindible ponerla a 0). Una vez hecho esto, movemos dicho script a la carpeta script, reemplazando al viejo btpd. En el tar.bz2 incluyo la versión original, por si alguien se arrepiente.

Finalmente, lanzamos los nuevos programas mediante el comando ./btpd start y listo, ya tenemos acceso por FTP y un nuevo cliente BitTorrent.

Para acceder al cliente bittorrent hay que abrir con un navegador una conexión al puerto 8080 del disco duro multimedia. El usuario por defecto es admin, y la clave 123, pero se pueden cambiar editando el fichero /tmp/hdd/root/etc/dtcts.conf. Algunos cambios que hice en él con respecto al original de la página del otro disco duro fueron, por una parte, aumentar el buffer de recepción hasta 64Kbytes para conseguir la misma velocidad de transferencia (2,4MBytes/seg) que con SMB (con los 2Kbytes originales sólo se conseguían 200Kbytes/seg, diez veces más lento), así como eliminar toda la parte de registro (log) para no consumir disco duro inútilmente (quien quiera activarlo sólo tiene que echar un vistazo al fichero de configuración de demostración que viene en el paquete original de dtcts). Por último, cambié los nombres de las carpetas: en /tmp/hdd/volumes/HDD1/BT almacena los ficheros recibidos, igual que el viejo cliente BitTorrent, y en DOWNLOADS almacena los .torrent de los ficheros que se están descargando.

Respecto al servidor FTP, por defecto se puede entrar como anónimo, pero se puede cambiar la configuración en el fichero /tmp/hdd/root/etc/bftpd.conf.

La ciencia no necesita tijeras

Españoles eran Juan de la Cierva, Leonardo Torres Quevedo, Santiago Ramón y Cajal, Isaac Peral, Narcis Monturiol, Severo Ochoa y Alejandro Goicoechea. Son ejemplos de lo que es Investigación y Desarrollo hecha por españoles. Pero en esa pequeña lista son mayoría los que se tuvieron que ir fuera para conseguir, bien investigar en condiciones, bien desarrollar comercialmente sus diseños, y también hay varios que vieron muchas de sus ideas ridiculizadas y olvidadas hasta muchos años después. Por si fuera poco, poca gente de la calle podría citarlos, mientras que otros nombres, como Alexander Fleming o Thomas Alba Edison, son fácilmente reconocidos y nombrados. Nuestra universidad produce grandes cerebros gracias a parte de nuestros impuestos, pero luego esos cerebros tienen que irse fuera si quieren triunfar, con lo que el dinero que hemos invertido acaba revirtiendo en Alemania, Francia, Inglaterra o EE.UU. ¿Tiene sentido formar a nuestra gente para que sean otros los únicos que saquen provecho?

Y si ya la cosa estaba tan mal, ahora resulta que en España recortamos en un 15% el gasto en investigación, un gasto que ya era de por sí bastante exiguo. Por eso me uno a la iniciativa de La aldea irreductible: La ciencia española no necesita tijeras.

Las apariencias engañan

Estaba terminando de reinstalarle el windows a un amigo y decidí meterle el VLC para que pudiese ver películas. Como no recordaba bien la dirección de la página, me fuí a Google, busqué videolan y entré en el primer enlace. Y de pronto, el antivirus bloqueó la página con un aviso de sitio malicioso.

¿Mande?

Vuelvo a la página de Google y me fijo en las direcciones: la primera página es videolan.pro, y la segunda, la auténtica, www.videolan.org. Una búsqueda detallada del término me lleva a descubrir que en la primera página distribuyen una versión con adware (o sea, que incluye publicidad). Una visita a la URL (desde Linux, para evitar riesgos) muestra una página cuidada, con un aviso de una revista famosa calificando a VLC como «el mejor reproductor de vídeo del mundo», y que bien podría pasar por la auténtica, aunque un análisis más cuidadoso descubre que la versión que ofrecen es la 0.9.9, y que no está disponible ni el código fuente ni las versiones para MacOS y Linux.

Quiero pensar que al final no habría colado porque yo ya sabía que la versión actual es la 1.0.2, pero aún así no puedo evitar pensar que si a mí, que siempre intento tener cuidado de qué me bajo y de donde, casi me la cuelan ¿cuanto más se la colarán al usuario medio que sabe lo justo? Por eso creo que se debería potenciar más la asignatura de informática en las escuelas, pero orientándolas no sólo a utilizar un procesador de textos o un lenguage de programación, sino también a este tipo de cosas: protección de la privacidad, protección ante troyanos y virus, protección ante el adware… Es necesario que la gente sea consciente de estas cosas y que aprenda a defenderse de ellas.

Emergiendo

Actualizado. Hace unos días encontré una página sobre discos duros multimedia basados en procesador MIPS. Aunque no es sobre el mismo modelo que mi disco, sí tiene cosas lo suficientemente parecidas como para que funcione. Una de ellas es la idea de utilizar una Debian para MIPS mediante chroot para poder añadir cosas extra.

Aunque la idea es buena, por cuestiones personales prefería utilizar Gentoo, así que me bajé la stage3 para MIPS, la copié en el disco duro e intenté hacer un chroot. Pero como siempre, las cosas nunca son sencillas: decía que no podía ejecutar bash. Extrañado, copié el ejecutable a mi equipo de sobremesa y lo analicé con GHex, comparándolo con el ejecutable de BusyBox.

El problema resultó ser que los stages de Gentoo para MIPS están en formato big-endian, mientras que mi disco duro trabaja en little-endian (parece ser que los procesadores MIPS, aunque pueden trabajar con ambos formatos, no pueden utilizarlos a la vez, sino que se escoge a nivel hardware durante el arranque). Cuando un sistema trabaja en little-endian se dice que es un MIPSel.

Rebuscando encontré unos stages para MIPSel, pero eran del año 2005. Intenté usarlos y, aunque funcionaban, en cuanto intentaba actualizar el sistema al más reciente, fallaba (todo apuntaba a la versión de python, que era demasiado vieja para ejecutar el último portage). Seguí buscando y encontré que las estaciones de trabajo Cobalt trabajaban en little-endian, así que probé de nuevo con unos stages diseñados para ellas, pero seguía fallando.

Decidí entonces probar con la Debian de la página inicial, pero al hacer un dist-upgrade volvía a fallar.

Ante esto, decidí que sólo tenía dos opciones: o utilizaba sólo cross-compiling, o intentaba generar yo mismo un stage de Gentoo para MIPSel. Como no podía ser de otra manera, tiré por la segunda 🙂 Por supuesto, es la primera vez que lo hago, así que, aunque me ha funcionado, puede ser que haya metido la pata en algo, o que alguna cosa se pueda hacer mejor, así que los comentarios están abiertos para cualquier sugerencia o corrección.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Avisados estáis.

Lo primero que hice fue instalar una Gentoo para x86 en mi sistema. Pero como no quería formatear mi actual Ubuntu, decidí hacer una instalación virtual. Veamos como:

Para empezar, descargamos las versiones más recientes del stage3 y el portage de Gentoo, y las descomprimimos en un directorio (el portage se descomprime dentro del directorio /usr del stage3), en mi caso llamado gentoo:

mkdir /home/raster/gentoo
sudo tar -xjvf stage3-i686-20090915.tar.bz2 -C /home/raster/gentoo/
sudo tar -xjvf portage-lastest.tar.bz2 -C /home/raster/gentoo/usr/

La razón de utilizar sudo es que, si no, no podrá crear algunos ficheros especiales en el directorio.

A continuación montamos una copia de los sistemas de archivos especiales de Linux (/proc, /dev, /dev/pts y /sys), además de copiar el fichero resolv.conf para poder conectarnos a Internet. Sin ellos no podríamos hacer muchas cosas básicas:

sudo mount -o bind /proc /home/raster/gentoo/proc
sudo mount -o bind /dev /home/raster/gentoo/dev
sudo mount -o bind /dev/pts /home/raster/gentoo/dev/pts
sudo mount -o bind /sys /home/raster/gentoo/sys
sudo cp /etc/resolv.conf /home/raster/gentoo/etc/resolv.conf

Notar el parámetro -o bind en mount: lo que hace es coger un sistema de archivos ya montado y montarlo también en el nuevo directorio, de manera que esté disponible en ambos a la vez.

Por último, hacemos un chroot para entrar en el sistema:

sudo chroot /home/raster/gentoo/ /bin/bash

Ya estamos dentro de nuestra Gentoo, pero antes de empezar tenemos que cargar el entorno:

env-update
source /etc/profile

Con ésto ya podemos empezar a trabajar. Lo primero es actualizar todo el sistema a los últimos paquetes, para lo que hacemos:

emerge --sync
emerge --update --deep world

Y ya podemos empezar a crear nuestro stage. Lo primero es instalar crossdev, un paquete que automatiza la generación de entornos de compilación cruzada (la documentación oficial está aquí y aquí):

emerge portage-utils crossdev

A continuación, editamos el fichero /etc/make.conf y añadimos la línea PORTDIR_OVERLAY=/usr/local/portage (podemos utilizar el editor nano, o vi) y, opcionalmente, la línea MAKEOPTS=»-jX» (siendo X el número de procesadores más 1; yo, como tengo un doble núcleo, uso -j3). Por último, creamos el directorio /usr/local/portage, y ya podemos generar un compilador para MIPSel, linux, y uclibc:

crossdev -v --target mipsel-unknown-linux-uclibc

Las distintas combinaciones de procesadores, núcleos y bibliotecas están en la documentación de crossdev, en una tabla.

Se tirará un buen rato compilando, tras el cual podemos comprobar si todo fue correctamente con:

gcc-config -l

En mi caso devuelve:

[1] i686-pc-linux-gnu-4.3.2 *
[2] mipsel-unknown-linux-uclibc-4.3.4 *

Con este toolchain podremos compilar cosas de manera nativa pra el disco duro. Para probarlo escribimos el típico Hola mundo y lo compilamos con:

mipsel-unknown-linux-uclibc-gcc -o holamundo holamundo.c

lo copiamos al disco duro multimedia y probamos a ejecutarlo. Debería funcionar a la primera.

Una vez que tenemos el toolchain para compilación cruzada, vamos a crear nuestra stage. Para ello tenemos que instalar el paquete crossdev-wrappers, tal y como se explica en su página, e inicializarlo. Por desgracia, por defecto está enmascarado, así que tenemos que desenmascararlo para que podamos instalarlo. Para ello escribimos:

echo "sys-devel/crossdev-wrappers ~* *" >> /etc/portage/package.keywords/i686-unknown-linux-gnu

Asumiendo, por supuesto, que /etc/portage/package.keywords es un directorio. Si es un fichero, entontes sería

echo "sys-devel/crossdev-wrappers ~* *" >> /etc/portage/package.keywords

Ahora ya podemos instalar crossdev-wrappers:

emerge crossdev-wrappers
emerge-wrapper --init

Este paquete nos permite instalar cualquier paquete de Gentoo, pero compilándolo para el sistema para el que tenemos compilador cruzado, e instalando el sistema de archivos en un directorio aparte (por defecto en /usr/arquitectura; o sea, /usr/mipsel-unknown-linux-uclibc en este caso), que podremos comprimir con tar e instalar en el sistema destino. Pero antes de empezar a utilizarlo tenemos que configurarlo adecuadamente. Lo primero es editar el fichero /usr/mipsel-unknown-linux-uclibc/etc/make.conf y ajustarlo a nuestros intereses. En mi caso, por defecto estaba así:

CHOST=mipsel-unknown-linux-uclibc
CBUILD=i686-pc-linux-gnu
ARCH=mips

HOSTCC=i686-pc-linux-gnu-gcc
E_MACHINE=EM_MIPS

ROOT=/usr/${CHOST}/

ACCEPT_KEYWORDS="mips ~mips"

USE="${ARCH} zlib bindist make-symlinks minimal"

#MARCH_TUNE="-march=armv4t -mtune=arm9tdmi"     #arm-softfloat-linux-uclibc
#MARCH_TUNE="-march=armv5t -mtune=xscale"       #armv5teb-softfloat-linux-gnueabi

CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}usr/include/ -I${ROOT}include/"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-L${ROOT}lib -L${ROOT}usr/lib"

FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Be sure we dont overwrite pkgs from another repo..
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=${ROOT}tmp/

ELIBC="glibc"

PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/usr/portage/local/"

LIBDIR_${ARCH}="lib"
LIBDIR_amd64=lib64
MAKEOPTS=-j2

Hay varios cambios a realizar. Para empezar, hay que añadir MARCH_TUNE=»-march=4kec», de manera que optimicemos para el procesador específico de mi disco duro (esto hay que cambiarlo para el modelo específico del procesador del disco duro que se quiera utilizar). Por otro lado, hay que cambiar MAKEOPTS=-j2 por MAKEOPTS=-j3, porque yo tengo dos núcleos. Al final tenemos:

CHOST=mipsel-unknown-linux-uclibc
CBUILD=i686-pc-linux-gnu
ARCH=mips
MARCH_TUNE="-march=4kec"

HOSTCC=i686-pc-linux-gnu-gcc
E_MACHINE=EM_MIPS

ROOT=/usr/${CHOST}/

ACCEPT_KEYWORDS="mips ~mips"

USE="${ARCH} zlib bindist make-symlinks minimal"

CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}usr/include/ -I${ROOT}include/"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-L${ROOT}lib -L${ROOT}usr/lib"

FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Be sure we dont overwrite pkgs from another repo..
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=${ROOT}tmp/

ELIBC="glibc"

PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/usr/local/portage"

LIBDIR_${ARCH}="lib"
LIBDIR_amd64=lib64
MAKEOPTS=-j3

También hay que ajustar el perfil deseado. Por defecto nos ha puesto embedded, que es perfecto para nuestro caso; pero si queremos cambiarlo basta con borrar /usr/mipsel-unknown-linux-uclibc/etc/make.profile y enlazarlo al perfil deseado de los disponibles en /usr/portage/profiles.

Y ya sólo queda por compilar todos los paquetes que queramos, utilizando el comando emerge-mipsel-unknown-linux-uclibc. Así, el primero que, probablemente, queramos instalar será system.

emerge-mipsel-unknown-linux-uclibc system

que instalará BusyBox con todas las librerías de uClinux. Una vez hecho esto sólo tenemos que crear los directorios que faltan con:

cd /usr/mipsel-unknown-linux-uclibc
mkdir dev proc root sys

y ya tendremos un sistema de ficheros que podremos probar. Para ello basta con empaquetarlo con tar (no comprimirlo, porque al menos mi disco duro no tiene ni gzip ni bzip2), descomprimirlo en el disco duro, montar proc, dev, dev/pts y sys como al principio de esta entrada, copiar /etc/resolv.conf y hacer un chroot, aunque esta vez con /bin/ash, porque busybox no dispone de bash.

Otra cosa que podemos hacer es añadir en/usr/mipsel-unknown-linux-uclibc/etc/make.conf una línea USE con las opciones que nos interesen de cara a compilar (opciones que se pueden consultar aquí).

Tuneando discos

Esta semana hice varias pruebas del disco duro. Para empezar, probé varios formatos diferentes, y el resultado es que DivX lo soporta perfectamente, en SD, HD y FullHD. Parece que en FullHD (probado con Big Buck Bunny) se atasca una pizca en algún que otro momento, mientras que en HD y SD va todo como la seda.

Sin embargo, probé a cambiar el sistema de archivos por EXT3 en lugar de NTFS y parece que los atascos han desaparecido.

Respecto al tema de que se encendiese él sólo al encender la luz del salón, lo he solucionado cambiando la bombilla por otra de otra marca.

Formatear la partición de EXT3

Las razones por las que he cambiado la partición principal a EXT3 son dos: por una parte me da más confianza ese sistema porque, a fin de cuentas, es nativo de Linux y se conoce perfectamente, mientras que NTFS es un sistema que se conoce por ingeniería inversa; por otro lado, parece que consigo una pizca más de rendimiento (2,2MB/seg frente a 2,0MB/seg de NTFS), lo que deduzco que es lo que elimina los pequeños tirones que se notaban al reproducir DivX en FullHD.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Avisados estáis.

Para cambiar el sistema de archivos basta con seguir los siguientes pasos:

Si echamos un vistazo a como están montadas las particiones, vemos lo siguiente:

/ # mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
none on /proc type proc (rw,nodiratime)
devpts on /dev/pts type devpts (rw)
none on /sys type sysfs (rw)
/dev/mtdblock/2 on /usr/local/etc type jffs2 (rw,noatime)
none on /tmp type ramfs (rw)
/dev/rd/0 on /mnt/rd type vfat (rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1)
/dev/ide/host0/bus0/target0/lun0/part2 on /tmp/hdd/root type ext3 (rw)
/dev/ide/host0/bus0/target0/lun0/part3 on /tmp/hdd/volumes/HDD1 type NTFS (rw)

La partición /dev/ide/host0/bus0/target0/lun0/part2 (/dev/hda2) contiene parte del sistema operativo; en concreto los módulos SMB para acceso por red y el cliente bittorrent, mientras que /dev/ide/host0/bus0/target0/lun0/part3 (/dev/hda3) contiene la partición visible desde el exterior.

Antes de nada copiamos a otro lado todos los ficheros que tengamos en el disco (pues se borrará todo lo que contenga), desmontamos la partición, formateamos en EXT3, volvemos a montarla y creamos el directorio BT:

umount /tmp/hdd/volumes/HDD1
mke2fs -j /dev/ide/host0/bus0/target0/lun0/part3
mount /dev/ide/host0/bus0/target0/lun0/part3 /tmp/hdd/volumes/HDD1
mkdir /tmp/hdd/volumes/HDD1/BT

Vemos que, si apagamos el disco y lo volvemos a encender, la partición sigue montada, lo que parece sugerir que el sistema es capaz de montarla sea del tipo que sea. Por desgracia, en realidad esto no es así: cuando le damos al botón de apagado, el disco se hiberna en lugar de apagarse, por lo que, cuando se enciende, no arranca desde el principio sino que vuelve al estado en que estaba cuando se apagó. Sin embargo, si lo apagamos «de verdad» (por ejemplo desenchufándolo de la red eléctrica, o porque se va la luz), entonces, cuando volvamos a encenderlo, veremos que no ha montado la partición en EXT3.

Para solucionarlo vamos a modificar los scripts de arranque para que monte la partición automáticamente si es necesario. Para ello nos vamos a /tmp/hdd/root/scripts y vemos que hay varios ficheros. Nos interesan uno de éstos: o btpd o samba. Estos scripts se lanzan durante el arranque para arrancar los servicios de BitTorrent y Samba. En principio podría parecer que basta con añadir un nuevo script para que lo ejecute, pero no lo es: sólo ejecuta esos scripts durante el arranque. Así pues, lo que haremos será modificar uno de ellos para que, al encender el equipo, monte la partición correspondiente. Para ello editamos, utilizando vi, uno de ellos y añadimos al principio las líneas:

if [ -e "/tmp/hdd/volumes/HDD1/lost+found" ]
then
    echo "Particion EXT3 ya montada"
else
    mount /dev/ide/host0/bus0/target0/lun0/part3 /tmp/hdd/volumes/HDD1
    echo "Montando particion EXT3"
fi

Este código comprobará si existe el directorio /tmp/hdd/volumes/HDD1/lost+found (que siempre existe en cualquier partición EXT3), en cuyo caso la partición estará montada y no hará nada; pero si no existe, entonces es que no está montada, así que procederá a hacerlo.

La próxima entrada espero empezar a intentar programar cosas para él.

Casualidad o plagio

El día 30 de Julio, Palomitas y maiz publicó otro de sus geniales chistes.

Curiosamente, dos meses después (concretamente el 20 de septiembre), Cyanide and happiness publicó exactamente el mismo chiste.

[Editado]Tal y como comenta Palomitas y maíz en el primer comentario, pensar en un plagio puede ser algo exagerado, así que corto la frase original por la mitad y me quedo sólo con «Simple casualidad».

Entre fantasmas

Así me sentía yo desde que compré mi disco duro multimedia, porque ocurría que, a veces… ¡se encendía él solo! Me aseguraba de apagarlo por la noche, pero a la mañana siguiente iba al salón y estaba encendido.

Al principio pensé que era un bug del firmware, pero de casualidad, buceando en páginas sobre reproductores con chips similares al que lleva, encontré una (cuyo enlace no consigo encontrar de nuevo. Sigo buscando) en la que se afirmaba que dicho chip es sensible a las interferencias de las lámparas de bajo consumo… justo el tipo de bombilla que tengo en el salón.

Me costaba creerlo, así que tuve que hacer la prueba: fui al salón, que estaba a oscuras, y comprobé que el LED del disco estaba rojo (en reposo). Encendí la luz de la sala… ¡y él solito se encendió, el muy c****n!

Tras hacer varias pruebas, todo apunta a que es el parpadeo de la lámpara al encenderse, que hace creer al disco que se ha pulsado algún botón en el mando, porque si tapo el sensor no ocurre.

Cosas veredes, amigo Sancho…