Identificar sockets en uso en 3.. 2.. 1..

Normalmente uso

# netstat -tnap

pero debo decir que

# lsof -i -P +c 0 +M

resulta sumamente útil también.

Visto en alias.sh

FLISOL 2012 – Festival Latinoamericano de Instalación de Software Libre

Como ya viene siendo una sana costumbre, el Grupo de Usuarios de Software Libre de la Universidad Nacional de Luján está organizando la edición local de la 8va edición del Festival Latinoamericano de Instalación de Software Libre (FLISoL), el evento simultáneo de difusión de Software Libre más grande en Latinoamérica.

El FLISOL se realiza desde el año 2005 y su principal objetivo es promover el uso del software libre, dando a conocer al público en general su filosofía, alcances, avances y desarrollo. Para tal fin, las diversas comunidades locales de software libre (en cada país, en cada ciudad/localidad), organizan simultáneamente eventos en los que se instala, de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes. Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.

El FLISOL 2012 se llevará a cabo el sábado 28 de abril. Por quinta? sexta? séptima? vez, el UNLUX organizara la actividad en la ciudad de Luján. La jornada está dirigida a todo público, sin importar el nivel de conocimientos técnicos que se posea, y comprenderá la instalación de software libre en los equipos que acerque el público, así como también habrá charlas de variado tenor.

Agendando…

Más Info en el sitio web del UNLUX y en www.installfest.info/FLISOL2012/Argentina/Lujan

Recuerden que además, el sábado siguiente -5 de Mayo- tenemos ¡PyDay en la UNLu!

Bashismos

Esto surgió mientras un amigo depuraba un script de backup. Supongamos que creamos un script denominado ./myscript con el contenido siguiente:

echo parametro1 es $1
echo parametro2 es $2

Y luego lo ejecutamos alternativamente con los intérpretes Dash y Bash:

mauro@yoda$ dash
$ . ./myscript
parametro1 es
parametro2 es
$ . ./myscript foo bar
parametro1 es
parametro2 es
mauro@yoda$ bash
$ . ./myscript
parametro1 es
parametro2 es
$ . ./myscript foo bar
parametro1 es foo
parametro2 es bar

¿Se nota la diferencia?

Efectivamente, al utilizar el comando “.” (dot o source) Dash no pasa ningún argumento al script, mientras Bash sí lo hace. ¿Bug o Feature? Según parece, es una implementación estricta del estándar POSIX. En cualquier caso, hasta que nos dimos cuenta, fue un dolor de cabeza.

Random wallpaper changer

La semana pasada dediqué unos minutos a buscar algún software sencillo para rotar el fondo de pantalla aleatoriamente en GNOME, porque los que tengo ya me aburren, y se me ocurrió que ir rotándolos al inicio o cada cierto tiempo estaría piola. Lamentablemente no pude encontrar nada en Gnome que me permita indicar un directorio con imágenes y vaya cambiándolas cada tanto. Curiosamente XFCE sí lo tiene y si no me equivoco KDE también lo permite desde hace bastante.

El repositorio de Debian posee aplicaciones para cambiar el fondo de pantalla, pero no encontré ninguno que me satisfaga, sea porque no realiza rotación automática, porque no está disponible en la release estable, porque el método de funcionamiento es un tanto complejo para lo que hace, o bien porque requiere un montón de dependencias para funcionar (mono, anyone?).

Lo que pido es muy sencillo, dar una carpeta con archivos de imágenes, un tiempo de duración de cada fondo y listo, no más que eso; ni siquiera hace falta un diálogo de configuración. Como sé que, afortunadamente, los entornos de escritorio en Linux se llevan bien con la línea de comandos, no tardé mucho en encontrar la forma de cambiar el fondo de Gnome desde consola. Y de allí a cambiarlo automáticamente es un paso, por lo que terminé con un pequeño script en bash que denominé, en un alarde de creatividad, wallchanger, que no es sino una versión floreada de algo extremadamente sencillo:

#!/bin/sh
while true; do
    CHOSEN=`find /usr/share/backgrounds -iname \*.jpg -print | shuf -n 1`
    gconftool-2 -s -t string /desktop/gnome/background/picture_filename $CHOSEN
    sleep 300   # 5 min
done

La versión completa soporta además algunos parámetros útiles tales como cambiar la carpeta de imágenes, el tiempo de presentación de cada una, o el entorno de escritorio sobre el cual realizar el cambio:

Usage: wallchanger [-g|-x] [-f FOLDER] [-o MODE] [-w NN]
  -g          set GNOME wallpaper
  -x          set XFCE wallpaper
  -f FOLDER   choose from wallpapers in FOLDER
  -o MODE     set wallpaper mode [scaled|zoom|centered|...]
  -w NN       change wallpaper every NN seconds

Como siempre, por si a alguno le es útil, dejo el enlace de descarga: wallchanger

Waiting for /dev to be fully populated…

Desde hace algunos meses me venía mordiendo un bug extraño en la máquina de trabajo donde a partir del kernel linux 2.6.39 e incluyendo la versión 3.0.0 el sistema se bloqueaba al inicio (el clásico freeze on boot) justo después del mensaje

Waiting for /dev to be fully populated

Y luego de eso, nada. Curioso, ya que con 2.6.38 el arranque iba de lo más normal, además que el equipo es un clon de los más comunes:

Procesador: Intel(R) Pentium(R) D CPU 2.80GHz
Motherboard: Intel Corp. D102GGC2
VGA: ATI Technologies Inc RC410 [Radeon Xpress 200]
Memoria: 1 GB

Obviamente a esa altura del arranque no hay muchos dispositivos disponibles, por lo que logs como para diagnóstico no tenía ninguno, así que por un tiempo desistí la investigación y me mantuve con el 2.6.38, ya que había que trabajar.

El primer sospechoso fue naturalmente udev, al fin y al cabo era el emisor del último mensaje que veía en pantalla. Diagnosticar problemas con udev es, digamos, un poco tedioso. Si leen el manual de udev encontrarán que en /etc/udev/udev.conf puede establecerse la variable udev_log en err, info o debug para definir la prioridad de los mensajes que serán mostrados en pantalla. Una vez hecho el cambio basta con reiniciar el equipo para ver los mensajes de información o diagnóstico correspondientes.Pero recientemente, aprovechando un día que llegué demasiado temprano, le dediqué unos minutos a este inconveniente que ya me tenía incómodo.

Desde ya es todo un pergamino de eventos el que va sucediendo en el arranque. Tantos eventos (y sin logging ni forma de recuperar los que ya pasaron) que me resultó imposible encontrar un patrón extraño o una pista siquiera de qué es lo que estaba sucediendo. Opté entonces por el clásico diagnóstico del pobre: conociendo dónde almacena udev las reglas (/lib/udev/rules.d/), fui desactivando las reglas y reiniciando el sistema tras cada cambio. Si el sistema continuaba el arranque luego del mensaje “Waiting for /dev …” entonces las reglas activadas eran inocentes; si no, alguna de las reglas activadas es la culpable. En algunos inicios no tenía gráfica, en otros no tenía disco, y en la mayoría ni siquiera teclado.

Una especie de búsqueda dicotómica me llevó, en pocos reinicios, a encontrar el archivo presuntamente culpable: 80-drivers.rules. Incluso llegué a determinar que la línea responsable era la séptima. Sin embargo el avance no fue mucho, ya que esta línea carga un montón de módulos en el kernel entre los cuales estan los de teclado y ratón: se ampliaba la lista de sospechosos.

Hasta acá, apenas si moví un paso, pero al menos llegaba a arrancar y controlar el sistema mediante SSH. Entonces un gran compañero de laburo (hat tip a Leandro), iluminado por el conocimiento (o quizá cansado de mis improperios) me recomendó: “¿y si probás cargando los módulos que faltan, uno a uno?”.

Entonces iniciamos el diagnóstico del pobre parte II. Haciendo un diff casero entre el lsmod del equipo iniciando con kernel 2.6.38 y uno iniciando con kernel 2.6.39 (sin 80-drivers.rules) llegamos a una lista de unos doce o quince módulos faltantes. Allí, tan cerca, login ssh y a probar cada uno de los módulos… pcspkr, evdev, psmouse, snd_hda_intel, todos cargaban bien… parport, fuse, ok… processorchan! ahí se tildó todo.

AHA! El módulo processor! Pero ¿qué función cumple ese módulo? O mejor, ¿por qué sigue andando el sistema sin él?. Bueno, resulta que es el ACPI Processor Driver, que no es realmente necesario pero maneja cuestiones útiles tales como los estados de energía del procesador. Si lo recuerdan ACPI ya nos viene dando dolores de cabeza desde hace bastante.

Ya con esos datos, una búsqueda en Google reveló un dato fundamental, aunque se ve que no es nuevo: en ciertos equipos el sistema se cuelga a menos que uno cargue el módulo processor con el parámetro nocst=1.

Así que, de momento, agregué la línea

processor.nocst=1

a los parámetros de inicio del sistema y con eso estoy andando actualmente. ¿A qué se debe el bug? Ni idea, habría que hacer un bisect entre las versiones de kernel 2.6.38 y 2.6.39 para determinar cual es el commit jodido. En cualquier caso, queda como tarea para vacaciones…

Reiniciando [rebooting]

Matthew Garrett es un biólogo (ahá) y reconocido hacker de Linux que lidia normalmente con complejas cuestiones de bajo nivel, pegadas al hardware, tales como ACPI, EFI, power management, y otras, que normalmente publica sus desventuras en el campo digital en un blog en livejournal. Muchos de sus artículos me han resultado realmente sorprendentes en cuanto a los intrincados detalles que pueblan los componentes de hardware desarrollados por diversos fabricantes.

Esta última semana publicó un artículo sobre el sencillo problema de cómo reiniciar correctamente una computadora. Me he tomado la libertad de traducir mejor dicho, interpretar ilegalmente, el post en cuestión. Para aquellos que se sientan cómodos con el inglés, les recomiendo el artículo original.


Reiniciando

Se podría pensar que es fácil reiniciar una PC, ¿no? Pero también podría pensarse que es fácil convencer a la gente de que al menos hacer un esfuerzo para ser amable con los demás es una propuesta de beneficio mutuo, y miren lo bien que nos ha funcionado.

Linux tiene un montón de maneras diferentes de reiniciar un sistema x86. Algunas de ellas son exclusivas para 32 bits y por eso las voy a ignorar porque, honestamente, que estás haciendo de tu vida [si estás trabajando en 32 bits]. Además, son horribles. Entonces, esto nos deja con cinco de ellas:

  • kbd – reiniciar a través del controlador de teclado. La IBM PC original tenía la línea [el cable] de reinicio de la CPU asociada a la controladora del teclado. Escribiendo la apropiada cantidad mágica de pulsos en la línea y la máquina se reinicia. Todo esto es muy sencillo, salvo por el hecho de que las máquinas modernas no tienen controladores de teclado (en realidad son parte del controlador embebido) e incluso las máquinas más modernas ni siquiera pretenden tener un controlador de teclado. Ahora, los controladores embebidos ejecutan software. Y, como todos sabemos, el software es terrible. Pero, aún peor, el software del controlador embebido está escrito por autores de BIOS. Así que claramente cualquier pretensión de que esto funcione es una especie de ficción complicada. Algunas máquinas son muy exigentes con el hardware, exigiendo que esté en el estado exacto que Windows lo programaría. Algunas máquinas funcionan 9 de cada 10 veces y luego se bloquean debido a algún raro problema de temporización. Y otras simplemente no funcionan en absoluto. ¡Hurra!
  • triple – intentar generar una falla triple. Esto se realiza cargando una tabla vacía como vector de interrupciones, y luego llamando a int(3). Falla la interrupción (no hay IDT), falla el manejador de fallos (no hay IDT) y la CPU entra en un estado que debería, en teoría, desencadenar un reinicio. Salvo que no parece haber un requerimiento de que esto suceda, y esto simplemente no funciona en un montón de máquinas.
  • pci – en realidad no pci. Tradicionalmente, el acceso al espacio de configuración PCI se logra escribiendo un valor de 32 bits al puerto io 0xcf8 para identificar el bus, el dispositivo, la función y el registro de configuración. El puerto 0xcfc luego contiene el [valor del] registro en cuestión. Pero si se escribe el par apropiado de valores mágicos en 0xcf9, la máquina se reiniciará. Espectacular! Y no estandarizado de ninguna manera (ciertamente no es parte de la especificación PCI), por lo que chipsets diferentes pueden tener diferentes requisitos. Booo.
  • efi – Los servicios EFI en tiempo de ejecución proporcionan un punto de entrada para reiniciar la máquina. Incluso a veces funciona! Siempre y cuando los servicios de tiempo de ejecución EFI estén funcionando, lo que puede ser una exageración.
  • acpi – Las versiones recientes de la especificación ACPI permiten especificar una dirección (por lo general en espacio de memoria o E/S de sistema) y un valor a escribir ahí. La idea es que escribir el valor a la dirección reinicia el sistema. Resulta que eso, a menudo, falla. También es imposible representar el método de reinicio PCI a través de ACPI, porque el método de reinicio PCI requiere un par de valores y ACPI sólo da uno.

Ahora, debo admitir que esto suena bastante deprimente. Pero la gente claramente vende computadoras con la expectativa de que van a reiniciarse correctamente, entonces ¿qué es lo que pasa?

Hace un tiempo hice algunas pruebas con Windows corriendo sobre qemu. Esta es una buena manera de evaluar el comportamiento del sistema operativo, porque uno tiene el control completo de lo que se entrega al sistema operativo y lo que el sistema operativo trata de hacer con el hardware. Y lo que descubrí fue un poco sorprendente. En ausencia de un vector de reinicio ACPI, Windows utiliza el controlador del teclado, espera un momento, lo intenta de nuevo y luego abandona. Si existe un vector de reinicio ACPI, Windows lo utiliza, luego prueba con el controlador del teclado, luego vuelve a utilizar el vector ACPI y prueba el controlador del teclado una vez más.

Esto resulta ser importante. Lo primero que significa es que genera dos escrituras en el vector ACPI de reinicio el sistema. El segundo es que deja un espacio entre ellas mientras toquetea el controlador de teclado. Y, sorprendentemente, resulta que en la mayoría de los sistemas el vector de reinicio ACPI apunta a 0xcf9 en el espacio de E/S del sistema. Incluso cuando la mayoría de las implementaciones nominalmente requieren escribir dos valores distintos, parece que este no es un requisito estricto y el método ACPI funciona.

[La versión del kernel Linux] 3.0 incluirá este comportamiento por defecto. Hace que varias máquinas funcionen (algunas Apple, por ejemplo), mejora las cosas en otras (algunas Thinkpad parecen quedarse tiesas durante largos períodos de tiempo, de otra manera) y con un poco de suerte evitará la necesidad de añadir más peculiaridades específicos al código de reinicio. Todavía hay algunas divergencias entre nosotros y Windows (mayormente en cuán seguido escribimos en el controlador de teclado), que se puede limpiar si resulta que hace alguna diferencia en cualquier lugar.

Ahora. De vuelta a los bugs de EFI.

– mjg59

Diez sistemas operativos en una netbook

Mi buen amigo Efraim es de esos informáticos que la tienen muy pero muy clara. Es de los administradores que hacen su trabajo con seriedad, pero de forma casi imperceptible para que las redes de las organizaciones sigan funcionando a pesar de las barbaridades que se ven en los desarrollos que corren sobre ellas (y de esas anécdotas hay para hacer un libro). Tiene, eso sí, la costumbre de exprimir al máximo todo hardware que pasa por sus manos; de hecho más de una vez lo he encontrado dejado procesando equipos una semana entera para entrenar redes neuronales.

Entre esos arranques -que a mi no se me ocurren ni por casualidad- se preguntó que tal andaría una netbook con diez sistemas operativos corriendo a la vez. Nueve Ubuntu(s), para ser preciso, virtualizados con KVM + KSM sobre un Debian que actúa de host, y todos al mismo tiempo y todos en una netbook. Contrario a lo que uno hubiera esperado, la verdad se la bancó muy bien, manteniendo responsivo el escritorio, como pueden ver por la captura de pantalla (de paso, con compiz). Allí está ingresando en uno de los virtualizados, mientras los restantes aún muestran la pantalla de inicio de sesión.

Por supuesto que no es cualquier netbook; de todas las que hay en el mercado, esta belleza de Asus [ver reviews 1 y 2] tiene un procesador de 64 bits y virtualización por hardware, lo que hace posible semejante comportamiento.

Tres soluciones al hilo

Desde hace varios días vengo anotando algunas dificultades que he tenido con linux y el hardware y que soluciones aporta la gente en foros, blogs y otros espacios (que afortunadamente google indexa). Como es de costumbre, para quedar tranquilo prefiero, antes de olvidarlas, dejarlas registradas acá.

1. En Debian/Ubuntu de 64 bits (amd64) no incia Skype, o bien el nuevo plugin de Google Talk para linux se instala pero no funciona, dando el siguiente (o similar) mensaje de error:

Inconsistency detected by ld.so: dl-open.c: 611: _dl_open: Assertion 
`_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

Esto probablemente surge debido a una incompatibilidad entre arquitecturas de las librerías de pulseaudio y puede solucionarse quitando el permiso de lectura en los archivos de 32 bits de tal librería, como se detalla en los comentarios de este post de skype. Con el plugin de google talk ocurre lo mismo, salvo que no estalla sino que “no permite usar el chat de voz y video” aunque esté instalado correctamente. Los pasos son sencillos:

# chmod a-r /usr/lib32/libpulse.so*
# chmod a-r /usr/lib32/libpulse-simple.so*

Hecho esto, es cuestión de cerrar y volver a abrir la sesión de usuario para que salgan andando ambos programas.

2. Siguiendo con temas de sonido, en equipos Dell Studio 1558 y similares con Debian/Ubuntu no funcionan las salidas de auriculares y/o el micrófono incorporado en las aplicaciones de captura de sonido (léase skype, google-talk, etc.).

En el blog stfunoob y en sathyaphoenix dan como solución especificar un parámetro adicional en la carga del módulo que controla la placa de sonido. En estas portátiles, específicamente, conviene hacer:

# echo "options snd-hda-intel model=dell-m6-dmic" > /etc/modprobe.d/alsa-dell.conf

y reiniciar el equipo o volver a cargar los módulos de sonido, lo que sea más sencillo. Con eso es posible utilizar el micrófono incorporado en la laptop en aplicaciones de voip y con la calidad que corresponde.

3. Y también en portátiles Dell Studio 1558 y similares, el cargador de arranque GRUB2 se instala correctamente, pero falla luego del reiniciar en Windows Vista/7 e impide iniciar cualquiera de los sistemas operativos instalados, dejando el equipo inutilizado con el siguiente mensaje de error:

GRUB loading.
no module name found
Aborted. Press any key to exit.

Inicialmente es posible recuperar el inicio restaurando el cargador desde un disco de Ubuntu, de rescate de Debian (el mismo disco de instalación tiene un modo “rescue”) o bien utilizando SuperGrubDisk para volver a grabar el cargador en el MBR.

Lo que ocurre aquí es una incompatibilidad entre la aplicación de copia de seguridad Dell DataSafe Backup, según está registrado en varios foros y en los bugs 441941, 482757 y 551721 de Ubuntu. Con cada reinicio de Windows, la aplicación sobreescribe cierta parte inicial del disco corrompiendo el arranque de GRUB. Hay varias alternativas de solución:

a. Generar y grabar los discos de recuperación de Dell y luego eliminar la aplicación DataSafe Backup, según lo documentado en este blog, y finalmente reinstalar GRUB2.

o bien, si no desean desinstalar el programa de backup,

b. Instalar el cargador de arranque BURG.

o bien, si no queda otra,

c. Agregar una entrada para el sistema operativo linux en el gestor de arranque de Windows Vista/7 utilizando EasyBCD.

Bien, como siempre, espero que les sea de utilidad como para mi lo han sido estas soluciones aportadas por la comunidad.

Como la vida misma

 Original de The Bizarre Cathedral por Ryan Cartwright.

ata3: SRST failed (errno=-16)

Recientemente ingresó a la rama experimental de Debian el kernel 2.6.33, y aprovechando la novedad, uno de los cambios que recomiendan en la distribución es dejar los viejos drivers ide y comenzar a utilizar libata tanto para dispositivos Serial ATA (SATA) como Parallel ATA (PATA).

En la mayoría de los equipos en los que lo instalé, la transición a libata no me ha dado inconvenientes mayores más que los cambios de nombre en dispositivos (en discos, de /dev/hd* a /dev/sd*, y en dvd/cd de /dev/hd* a /dev/sr*), que normalmente no necesitan modificaciones por el usuario siempre que se utilicen etiquetas o uuid para identificar las particiones.

Sin embargo en el equipo de escritorio encontré que el arranque demoraba demasiado y devolvía errores tales como:

...
ata2: SATA link down (SStatus 0 SControl 300)
ata3: link is slow to respond, please be patient (ready=0)
ata3: SRST failed (errno=-16)
ata3: link is slow to respond, please be patient (ready=0)
ata3: SRST failed (errno=-16)
ata3: link is slow to respond, please be patient (ready=0)
ata3.01: link status unknown, clearing UNKNOWN to NONE
...

continuando luego con el inicio tradicional. En tales situaciones, utilizando libata, el sistema no reconocía la unidad de dvd. Utilizando los viejos drivers ide, sin embargo, el sistema iniciaba bien y la unidad era reconocida correctamente.

Algunos foristas recomiendan cambiar parámetros de kernel, como libata.dma y otros. Sin embargo, la única solución que me ha dado resultado fue establecer las unidades PATA en modo cable-select, como lo apuntan en el 2do post de este bug report de Ubuntu. Sólo eso basta para que el sistema inicie y detecte correctamente los dispositivos.

Curioso, cuanto menos.

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress