Ayer estaba en la biblioteca estudiando para un examen de control digital y necesitaba usar octave para hacer algunas pruebas. Descubrí con horror que iba mal cuando se quedó colgado al pedirle las raíces de un polinomio:

octave:1> v = roots([1 3 2 0 2])

Tuve que interrumpir la operación con el típico Ctrl+C porque, además, el octave estaba usando en ese momento el 100% de CPU según top. Lo sorprendente es que al volver a intentar la misma operación, en vez de colgarse, me mostró este error:

octave:1> v = roots([1 3 2 0 2])
error: dgeev failed to converge
error: evaluating assignment expression near line 65, column 9
error: evaluating if command near line 62, column 5
error: evaluating if command near line 59, column 3
error: called from `roots’ in file `/usr/share/octave/2.1.73/m/polynomial/roots.m’
error: evaluating assignment expression near line 1, column 3

El problema no sólo aparecía con la función roots, sino con muchas otra de las que necesitaba, que quizá usaban ésta en su código. Un poco de investigación al llegar a casa me hizo saber que el problema estaba en que había compilado la versión de octave ofrecida como estaba por Gentoo sin Blas entre sus uses. En el Changelog de octave decía que en la versión más reciente (2.1.73-r2), Blas había dejado de ser opcional.

Desenmascaré entonces esta versión de octave y comenzó la instalación de blas-atlas, que es una de las implementaciones de ¡Blas disponibles. Pero duró poco, la instalación se detuvo con un mensaje en pantalla que decía que tenía que ejecutar la instalación en modo interactivo. Seguí los pasos indicados pero, independientemente de las opciones que escogiese en el proceso, la compilación fallaba.

En un hilo del foro de Gentoo donde había un usuario quejándose del mismo problema que yo, el desarrollador encargado del ebuild de octave en Gentoo aconsejaba desenmascarar las últimas versiones de blas-atlas y blas-lapack (además de dos de sus dependencias que también estaban enmascaradas). Hecho esto repetí el intento de instalación y esta vez no sólo me hizo menos preguntas que antes sino que aparentemente estaba funcionando.

El proceso de compilación de blas-atlas es largo, y por la salida que ofrece en ocasiones parece que ha entrado en un ciclo infinito. Pero no pierdas la calma, que no es así; cada iteración es diferente y no se ciclan, así que resiste la tentación de cancelar. No puedo decir cuanto tardó porque me fui a dormir, pero esta mañana, cuando le pregunté a octave de nuevo por las raíces del mismo polinomio de ayer, me respondió esto rápidamente:

octave:1> v = roots([1 3 2 0 2])
v =
-1.79051 + 0.55231i
-1.79051 - 0.55231i
0.29051 + 0.69660i
0.29051 - 0.69660i

Una advertencia, aunque aparece en pantalla antes de empezar: Si tienes un procesador que ajusta su velocidad a las necesidades del software, desactiva esta opción y deja una velocidad fija de procesador durante la compilación, porque blas-atlas hace pruebas de rendimiento para optimizarse y una velocidad variable del procesador puede traer resultados no deseados.

Eso es todo, Jake out.

No obstante, la frecuencia de estas comprobaciones puede configurarse. Pueden incluso ser desactivadas. Una rápida lectura a la página de manual del programa tune2fs me llevó a la solución:
jake@aurora:~$ sudo tune2fs -i 100d -c 100 /dev/sda5
tune2fs 1.39 (29-May-2006)
Se pone la cuenta de montajes máxima a 100
Setting interval between checks to 8640000 seconds

Con esto, las comprobaciones sobre la partición /dev/sda se harán cada 100 veces que se reinicie el ordenador (antes estaba a 20) o bien cada 180 días, lo que ocurra antes.

Time-of-day clock stopped

Al reiniciar volvía a aparecer la misma pantalla y no podía tan siquiera acceder a la BIOS.

El servicio de atención al cliente de Dell no era una opción, pues no está operativo los sábados. Un poco de investigación me llevó a un informe de errores con título Ubuntu corrompe el reloj de tiempo real en algunos portátiles Dell. Allí decía que quitando la pila de la BIOS y volviendo a ponerla se resolvía el problema. Esta me pareció una solución interesante, pero eso fue antes de saber que la pila está debajo del teclado y que tenía que desarmar medio portátil para llegar a ella. Por suerte, Dell pone a disposición de sus clientes una fabulosas instrucciones, con fotos y detalles de cuidado, para desmontar cada modelo de portátil de la marca e identificar las distintas partes (son los llamados manuales de servicio, que sólo están disponibles en inglés). En mi caso, seguí las instrucciones específicas para cambiar la pila de la BIOS del Inspiron 640m. Claro que, después de efectuar esta operación, tuve que volver a configurar todos los parámetros de la BIOS para dejarlos como los tenía antes de la crisis.

Esta fotografía la tomé durante el proceso, justo después de haberle quitado la pila a Aurora. El rectángulo azul indica la posición de la pila.

Esta experiencia ha servido con creces para que me plantee probar otras distribuciones. Tengo ahora Gentoo en el punto de mira, y es más que probable que sea la próxima.

Asimov tiene una tarjeta de sonido incluida en la placa, que nunca uso, porque tengo una Sound Blaster 128 PCI que sí uso. Dapper nunca reconoció la primera, pero Edgy sí, y ahora había tomado el control del sonido del sistema. Yo quería poner la Sound Blaster como principal, pero teniendo ambas disponibles.

Encontré la solución en este hilo del foro de Ubuntu. Ejecuté:

jake@asimov:~$ cat /proc/asound/modules
0 snd_via82xx
1 snd_ens1371

Como puede verse, la tarjeta VIA, incluida en la placa base, estaba la primera.

Edité entonces la configuración de Alsa en /etc/modprobe.d/alsa-base. Ojo aquí, pues, por alguna razón que desconozco, en el foro se indica otro nombre de archivo que en mi caso no existía, y la configuración de Alsa la encontré en /etc/modprobe.d/alsa-base, como he dicho.

jake@asimov:~$ sudo vi /etc/modprobe.d/alsa-base

Añadí estas dos líneas al final:

options snd-ens1371 index=0
options snd-via82xx index=1

Fíjate en que el guión bajo (_) de antes se sustituye aquí por un guión (-). El parámetro index indica en el orden en que se tomarán las tarjetas en el sistema (empezando por cero). Para que estos cambios se hiciesen efectivos en el sistema, ejecuté:

$ sudo update-modules

Y reinicié la máquina. Al volver a entrar, mi tarjeta principal ya era la Sound Blaster:

jake@asimov:~$ cat /proc/asound/modules
0 snd_ens1371
1 snd_via82xx

Normalmente no grabo estas isos hasta que necesito llevarlas a algún otro lugar, y no era el caso. De modo que seguí estos pasos para evitar grabar el CD.

Primero copié la imagen iso en /media

$ sudo cp ubuntu-6.10-alternate-i386.iso /media

Luego creé el directorio /media/edgycd y añadí esta línea al /etc/ftab

/media/ubuntu-6.10-alternate-i386.iso /media/edgycd iso9660 loop

De este modo puedo montar la iso como si estuviese poniendo el CD con solo hacer:

$ sudo mount /media/edgycd

Siguiendo las instrucciones de Este comentario hice esto una vez montado:

$ gksu sh /media/edgycd/cdromupgrade

Y ahí comenzó directamente la actualización, preguntándome si quería descargar de la red los paquetes que no estuviesen en el CD-ROM. Por supuesto, respondí que sí.

Pasó un buen rato descargando e instalando paquetes. Acepté todas las modificaciones que me mostró y al final reinicié.

Los gráficos de arranque: Usplash

En el menú de selección de grub escogí el kernel para 386 y en el siguiente paso la pantalla se puso en negro y me mostró un error de frecuencia. El monitor de Asimov es un TFT LG FLATRON L1750SQ, de 17″ que soporta 1280×1024@75Hz. Me enteré de que se trataba de un problema de los gráficos que se muestran durante el arranque y encontré la solución aquí. Funcionó a la primera, ya me aparecía la imagen de inicio. Venía a decir (traduzco)

Intenta esto en la línea de comandos:
$ sudo nano /etc/usplash.conf

Debería parecerse a esto:

# Usplash configuration file
xres=1024
yres=768

Si haces cambios, asegúrate de que ejecutas luego este comando:
$ sudo update-initramfs -u

Los kernels anticuados de Dapper

Los kernels que tenía instalados en Dapper eran los dos últimos disponibles en los repositorios oficiales de la rama 2.6 para i386 y k7. En Edgy, las versiones especializadas, como k7 o 686 han sido sustituidas por una sola llamada generic. Al parecer la razón es que no merecía la pena el esfuerzo de mantener desarrollos paralelos porque al final las diferencias no eran notables. Como yo no había personalizado mi kernel en Dapper, podía borrarlos con tranquilidad una vez comprobado, eso sí, que los nuevos funcionaban bien.

Todas las pruebas anteriores las había hecho con el de i383 y cuando probé el generic no funcionó. Se quedaba todo parado en el arranque. Investigando un poco encontré la solución (otra vez) en este hilo del foro de Ubuntu, donde se explica que la actualización a Edgy no creó el script initramfs para el kernel genérico, de modo que el problema se resuelve creándolo manualmente:

jake@asimov:~$ sudo mkinitramfs -o /boot/initrd.img-2.6.17-10-generic
jake@asimov:~$ sudo update-grub

Antes de reiniciar, y como al menos ya tenía el de i386 que funcionaba bien, usé aptitude para quitar todos los núcleos anteriores. Busqué primero todos los kernels instalados:

jake@asimov:~$ sudo aptitude search linux-image | grep ^i
i linux-image-2.6.15-26-386 - Linux kernel image for version 2.6.15 on 386.
i A linux-image-2.6.15-26-k7 - Linux kernel image for version 2.6.15 on AMD K7 SMP/UP
i A linux-image-2.6.15-27-386 - Linux kernel image for version 2.6.15 on 386.
i A linux-image-2.6.15-27-k7 - Linux kernel image for version 2.6.15 on AMD K7 SMP/UP
i linux-image-2.6.17-10-386 - Linux kernel image for version 2.6.17 on i386
i linux-image-2.6.17-10-generic - Linux kernel image for version 2.6.17 on x86/x86_64
i linux-image-386 - Linux kernel image on 386.
i linux-image-generic - Generic Linux kernel image
i linux-image-k7 - Obsoleted by: linux-image-generic


La primera columna indica si un paquete está instalado (i) o no (p), pero con grep ^i se filtran las líneas que empiezan por i, de modo que sólo se muestran los instalados. Tomé los nombres de los que tenían número inferior a 2.6.17 y los eliminé todos con aptitude:

jake@asimov:~$ sudo aptitude purge linux-image-2.6.15-26-386 linux-image-2.6.15-26-k7 linux-image-2.6.15-27-386 linux-image-2.6.15-27-k7 linux-image-k7

Fíjate en que eliminé también el paquete dummy linux-image-k7 porque, debido a los mencionados cambios en la política de variantes del núcleo, ya no tenía sentido tenerlo instalado.

Cuando terminó la desinstalación, el aptitude se encargó de reconfigurar el grub para que se guardasen los cambios. Y entonces sí que era momento de reiniciar, para ver un grub limpio, y comprobar que el kernel genérico funcionaba correctamente.

En efecto, tras estos cambios, todo parecía estar en orden. El menú de grub se veía mucho más limpio y el kernel genérico se cargó sin problemas.

Edgy vs Mplayer

Mplayer es mi reproductor de vídeo favorito, por eso lo tenía instalado en Dapper. Pero Edgy decidió que mplayer no era bueno y lo desinstaló sin preguntarme. Yo, por otra parte, decidí que lo quería de vuelta y lo volví a instalar

Cuando instalo mplayer, normalmente suelo poner estos 4 paquetes:

• mplayer
• mplayer-skins
• mplayer-fonts
• mplayer-doc

Comprobé cuales de ellos no estaban instalados:

jake@asimov:~$ sudo aptitude search mplayer | egrep ' mplayer(\-doc\b|\-fonts\b|-skins\b| )'
c mplayer - The Ultimate Movie Player For Linux
i mplayer-doc - The Ultimate Movie Player For Linux (Docum
c mplayer-fonts - Fonts for mplayer
i mplayer-skins - Skins for the Ubuntu mplayer Package

Y ví que mplayer y mplayer-fonts aparecía como eliminado aunque con archivos de configuración presentes (es lo que indica la c). Parecía un problema de solución simple:

jake@asimov:~$ sudo aptitude install mplayer mplayer-fonts

Y efectivamente, lo fue. Ya podía volver a ver vídeos con mi reproductor favorito. Además, los archivos de configuración anteriores se mantuvieron tras la instalación, de modo que no tuve que configurar nada más nada.

Fin (o casi)

Después de resolver estos problemas y un pequeño percance con el sonido que ya comentaré en otro post, el sistema estaba actualizado y funcionando correctamente.