crux@macumba:/var/blog$

Más temprano me puse a investigar quienes son todos los candidatos posibles para las elecciones de mañana. Buscando un poco en mi amigo Google llegué a ésta página en MDZ online que explica cómo llegar a esa información en el sitio del Poder Judicial de la Nación, de quien depende la Justicia Nacional Electoral.

Ahí se pueden ver todos los candidatos oficializados y también sus plataformas políticas (aka “la sanata que inventan para que los dejen participar”); incluso se pueden ver los presupuestos de financiamiento de las campañas!!

Lo mejor de este lugar es que no tiene ninguna clase de “tendencia”, ya que pude ver varios sitios de noticias que ni siquiera se gastaban en mencionar a los candidatos después del tercero en las encuestas.

Usen la cabeza mañana (bah, en un rato) que para eso la tienen. Al menos busquen una justificación en su interior para ir y votar a alguien, y no voten en blanco sólo porque les es más cómodo y está de moda.

Just my 2 cents.

Por mucho tiempo quise tener consola con framebuffer en los servers donde corro Xen para poder “ver más” cuanto tengo que solucionar algún problema en el mismo server y no via ssh. Hace poco lo encontré perdido por ahí en un post dónde hacían comentario al código fuente del hypervisor y todo. No recuerdo la URL pero para que me sirva a mí de recordatorio y a todos Uds. les cuento cómo conseguirlo: agreguen “vga=gfx-1024×768x16″ (sin las comillas) como parámetro para el hypervisor en su bootloader. Fácil, no?

Por si alguno está perdido todavía les copio las líneas relevantes de mi grub:

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=vga=gfx-1024×768x16
…
kernel /boot/xen-3.2-1-i386.gz vga=gfx-1024×768x16
…

Les aclaro que eso es con un Xen 3.2 y en un Debian.

ACTUALIZACIÓN:

Adjunto unas imágenes de la consola de mi notebook corriendo Xen en 1280×1024x32 :mrgreen:

Hola mis queridos lectores. Empiezo una nueva historia en este blog que está relacionada con mi cumpleaños y, como no podía ser de otra manera, con la ñoñez informática.

El pasado jueves 25/9 además de ser mi cumpleaños me tocó ir a dar clases a la universidad. La clase consistía en una práctica forzosa de LVM y después de algunas fallas en la computadora que iba a servir de conejillo de indias terminamos enchufando el disco de esa máquina a mi notebook. La idea era instalar un Debian en ese disco, con RAID por soft (md) y LVM.

Todo concurrió de forma tranquila aunque yo miraba atento los comandos ejecutados por los alumnos durante el proceso de instalación. Al estar no sólo el disco externo sino también el mío conectados temía que pudiera haber un accidente y perdiera datos.

Al finalizar la instalación vino la pregunta del debian-installer sobre dónde instalar GRUB y un almuno (del cual preservaré su nombre para que no reciba represalias ) dio ENTER sin más y mi GRUB2 desapareció de mi MBR.

Nada grave dije en voz alta y para mis adentros también. Más de una vez he tenido que recuperar eso y estoy “canchero” para hacerlo. Pero grande fue mi sorpresa un par de días después cuando intentando el procedimiento estándar encontré varias trabas.

Arranqué con Knoppix e hice la magia estándar para poder ver los volúmenes LVM. Pero no, no anduvo. Hasta que me di cuenta que mi disco está 100% encriptado así que empecé a buscar por la internet hasta dar con la solución. Cuando la encontré pude montar la imagen e intenté hacer un chroot para poder reinstalar mi GRUB2. Al tercer terco intento me di cuenta que algo no andaba. Y claro! Todo mi sistema es de 64 bits y Knoppix es de 32!!! Así que ahí vino la segunda búsqueda. Un live-cd que fuera de 64 bits y trajera soporte para LVM. Por suerte también lo encontré, y se llama GRML. Creo que el título de la página lo dice todo: Linux Live-CD for sysadmins / texttool-users / geeks. Ya lo había usado alguna otra vez porque está basado en Debian y anda muy bien. Compacto y con lo necesario para arreglar cualquier moco y sin algunas cosas innecesarias que trae Knoppix ya que son para otro target.

Lo bajé, lo grabé en un DVD+RW y lo arreglé. Ahora les resumo los pasos completos para el arreglo así quedan para referencias futuras.

↓ Abre la encriptación de esa partición.
# cryptsetup luksOpen /dev/sda2 encfs
↓ Escaneamos en busca de grupos de volúmenes LVM
# vgscan
↓ Activamos los grupos de volúmenes encontrados
# vgchange -a y
↓ Montamos lo que corresponda. La partición root y probablemente un /boot
# mount /dev/mapper/myvg-mylv /mnt/tmp
# mount /dev/sda1 /mnt/tmp/boot
↓ Montamos el /proc bindeado para que funcione la instalación de GRUB2
# mount -o bind /proc /mnt/tmp/proc
↓ Hacemos el chroot
# chroot /mnt/tmp /bin/bash
↓ Reinstalmos GRUB2 en el MBR
# grub-install (hd0)
→ Presto!

Ah! Y antes de olvidarme les comento que GRML trae como shell a zsh, así que
fanas intolerantes de bash abstenerse.

Y los que quieran un poco más de información sobre cryptsetup diríjanse a esta página que está buena como introducción.

It’s been a little over two months since I accomplished this and wanted to share it as I hadn’t found it anywhere over the net. It took me a while but finally it’s here! Enjoy!

To get everyone in context I’ll say that I had some Xen VMs which used LVM volumes as disk images living in one machine and I suddenly needed them on another one. After searching for some tried and tested solution I found none. So the only option I could see was to do some kind of dump (probably dd involved with bzip2) and bring them over to the other machine. Be it by network, DVD or external disk. Haven’t done it before, and it sure would have taken some effort on my part. Downsides: dangerous precise movements required and nothing new learned. This was a no-op

Luckily an alternative came to my mind. I could use AoE [1] (ATA over Ethernet not Axis of Evil nor Age of Empires!!!) and some LVM wizardry. Upsides: dangerous precise movements required and cool stuff learned. This was the way to go!

Just for the sake of clarity some definitions and requirements first. All the stuff below was done on two Debian Etch 4.0 boxes. Both of them having Xen for virtualization and LVM2 for storage administration. You’ll need an AoE enabled kernel (Debian’s kernels are from 2.6.11+). You’ll also need the aoetools package in the destination machine at least. Let’s call ORIG and DEST the machines and VG = Volume Group, PV = Physical Volume and lv = Logical Volume. If that’s mumbojumbo to you then keep away from the next commands!

Now to the recipe:

Enable AoE server on ORIG

root@orig-host# vbladed 0 0 eth1 /dev/md1

That should export any block device you want over eth. In my case a whole RAID device (md1) was exported through eth1 with major 0 and minor 0. Consider that Ethernet protocol is layer 2 and is non-routable. Another thing is that AoE provides no security inherently, so I enabled it manually for this and disabled it afterwards. If you are going to use it otherwise make sure you design a security scheme to go with it.

Enable AoE support on DEST

root@dest-host# modprobe aoe

Then search for AoE devices and make sure it found some

root@dest-host# aoe-discover
root@dest-host# aoe-stat

That should output something like “e0.0 250.000GB eth0 up”. At this point you should have a new block device available on the client box named /dev/etherd/e0.0. You can do anything to that block device as if it was a locally attached device. Cool!

Now we have to disable the ORIG-VG and make it unknown to the ORIG LVM system

root@orig-host# vgchange -an ORIG-VG
root@orig-host# vgexport ORIG-VG

Tip from experience: it’s better to have a dedicated VG for storing VMs images so we don’t have any downtime in the real box. I had the root filesystem on the same VG and had to switch to runlevel 1 just in case :???:

Search for new PVs on DEST and add them to LVM

root@dest-host# pvscan

Merge the two volume groups into one

root@dest-host# vgmerge DEST-VG ORIG-VG

Move LVs from ORIG-PV to DEST-PV. This is the step that’s gonna take forever or not depending on your network speed and the amount of data to move. I don’t have my exact figures but I recall it taking a couple of hours.

root@dest-host# pvmove -n some-lv /dev/etherd/e0.0 /dev/md1

Note this time /dev/md1 is the destination RAID device which belongs to DEST-VG, not the one on ORIG box stated before.

Once it finishes we want to make things go back to normal. So we disable the VG so we can do the split (James Brown style baby!) Then we re-enable the VG

root@dest-host# vgchange -an DEST-VG
root@dest-host# vgsplit DEST-VG ORIG-VG /dev/etherd/e0.0
root@dest-host# vgchange -ay DEST-VG

Now we have to disable the ORIG-VG and make it unknown to the DEST LVM system

root@dest-host# vgexport ORIG-VG

Back to the ORIG box we re-add the “lost” VG and re-activate the VG

root@orig-host# vgimport ORIG-VG
root@orig-host# vgchange -ay ORIG-VG

And that should be it! I’ll stop writing now since it’s a long post already. Hope somebody finds this useful and/or inspiring. Good luck!

[1] http://www.howtoforge.com/ata_over_ethernet_debian_etch

Esta mañana estaba en el laburo intentando crear un pernodrive booteable. Después de algunos intentos fallidos decido empezar de nuevo: “dd if=/dev/zero of=/dev/sda” … me agacho para ver si el LED del pendrive parpadeaba y no … vuelvo a mirar el monitor y lo más rápido que pude apreté Ctrl-C. La salida de dd indicaba que había alcanzado a llenar de ceros los primeros ~150MB del disco rígido. Eso incluyó el Master Boot Record (MBR) y la tabla de particiones.:oops: (Nota para los distraídos: el dispositivo correcto hubiera sido /dev/sdb)
Después de sufrir un corto pero efectivo ataque de pánico que me dejó catatónico mi cerebro volvió a la vida :idea: y empecé a pensar como hacer para arreglar ese pequeño inconveniente. El sistema seguía funcionando a la perfección. Los datos que tenía con certeza eran que el disco tenía dos particiones, una sda1 con un /boot de ~1GB y una sda2 con LVM de ~250GB. Casi seguro que los datos que se rompieron fueron las imágenes de kernels y demás yerbas del /boot. Eso no es crítico para que el sistema siga andando, sólo para que vuelva a arrancar.
Salí corriendo a buscar un disco rígido externo que hay por ahí en la oficina y le creé una partición del tipo LVM. Inspirado por este 1, 2, 3, 4 del LVM-Howto me puse a laburar. Creé el volumen físico en el disco externo con pvcreate y se lo asigné al grupo de volúmenes con vgextend. Después hice que los volúmenes lógicos que tenía (root, home y data) se pasaran al disco externo con pvmove. Esto demoró un buen rato y mientras estuve rezando para que no fuera a fallar nada más mientras que hacía esto. Al menos estaba seguro que la tabla de particiones estaba en la memoria del kernel, pero no estaba seguro que LVM no fuera a intentar nada raro mientras hacía esos pases mágicos. A propósito, y se me acaba de ocurrir, habrá alguna manera de saber con detalle suficiente cuál es la idea que tiene el kernel sobre la tabla de particiones? Ya voy a investigar, pero si alguno que lea esto lo quiere comentar no me enojo.
Una vez que terminó de mover todos los datos saqué el disco interno del grupo de volúmenes con vgreduce. También desmonté todas las particiones de ese disco y las volví a crear aproximadamente a como eran con fdisk. Reinstalé el paquete linux-image-2.6 y puse el GRUB de nuevo en el MBR. Para finalizar hice todos los pasos anteriores del LVM pero al revés, moviendo los datos desde el disco externo al disco interno nuevamente.
Crucé los dedos y reinicié. Y todo volvió a estar como antes!
Moraleja: LVM es una herramienta muy poderosa, pero aún más lo es dd

Hoy como tantos otros días llegué al trabajo y abrí Iceweasel, la alternativa aún más libre a Firefox … y como tantos otros días dirigí mi mano derecha hasta el mouse para poder posicionar el puntero en la barra de búsqueda dónde (casi) siempre está mi buscador amigo ya seleccionado. Es una de las pocas cosas que hago en el navegador que me requieran del mouse.
Lo único que no hice como todos los días fue reflexionar sobre lo que hacía. Entonces me decidí a buscar el atajo de teclado que me salvara del ratón. Lo encontré y lo comparto con Uds:

Ctrl+K Pone el cursor en la barra de búsqueda
Ctrl+Flecha arriba y Ctrl+Flecha abajo Cambian el buscador
Ctrl+L Pone el cursor en la barra de direcciones

Espero les sirva.

Desde que voodoo, mi desktop, está liberada de todo servicio “permanente” su uso se ha ido pareciendo cada vez más a una desktop . Esto significa que cuando me voy a ausentar de su lado por un rato medianamente prolongado la apago. Al haberme enfrentado al proceso de booteo con mayor regularidad descubrí que es medio tedioso. Esto me llevó a investigar nuevamente, aunque después de mucho rato, la posibilidad de hibernar. Estoy usando uswsusp, ya que viene incluído en el kernel y al menos para suspender a disco (aka hibernar) me anda bárbaro. A continuación les presento una serie de tips & tricks que usé para conseguir mi objetivo.

:arrow: Los malditos drivers de nvidia…

Con la combinación Xorg 7.2, Beryl 3.0svn, Linux kernel 2.6.20 y drivers de nvidia 9755, y algunas versiones anteriores también, tengo un problema recurrente al cambiar entre X y las terminales virtuales. Puedo ir y volver sólo una vez, a la segunda me quedo con el display totalmente en negro y el teclado sin respuesta, aunque la PC sigue viva y se puede entrar por ssh . Al volver de la hibernación tenía los mismos sńtomas. Descubrí que si tengo Beryl desactivado este problema no sucede, así que el primer workaround fue conseguir des/activar Beryl con cada hibernada. En el archivo /etc/hibernate/common.conf agregué:

OnSuspend 01 killall -s SIGUSR2 beryl-manager && sleep 5
OnResume 50 killall -s SIGUSR2 beryl-manager

Con la señal SIGUSR2 hacemos que Beryl se alterne con el Window Manager que tengamos seteado de fallback, en mi caso Openbox.
El resto de la semántica de la configuración la pueden aprender con man hibernate.conf

Un tip para los drivers de nvidia que conseguí por ahí fue el de cargar el módulo con el parámetro NVreg_Mobile=1, pero yo al menos no noté ninguna diferencia :???: .

:arrow: …la conexión a Internet…

El otro “problema” a resolver es el asunto de la conectividad. voodoo depende de macumba que le hace de bridge via WiFi. Además le presta algo de espacio vía NFS4. Según la documentación de uswsusp el módulo madwifi está en la lista negra por no soportar bien la suspensión. Yo desde que lo he usado no he tenido ningún problema, sin tener que des/cargar el módulo. Pero si ha sido totalmente necesario reiniciar el subsistema de networking para que el vínculo wireless vuelva a autenticarse (con WPA2) y para que se remonten los NFS. Lo arreglé fácil con el siguiente agregado en /etc/hibernate/common.conf:

AutoIfDownAndUp ath0

:arrow:…y Gaim (aka Pidgin)

Cada vez que volvía desde la hibernación había alguna de todas las cuentas de diferentes protocolos de IM que uso en Gaim que quedaba tecleando. Investigando descubrí que Network Manager es la manera oficial de que Gaim se entere si hay conexión o no. Pero para mí no cumplió con su promesa de Pain-free networking y así como vino se fue.
Después robé un poco de por aquí y por allá y terminé armando un par de scripts (dbus-hack.sh y recon.py) que también llamo desde /etc/hibernate/common.conf:

OnResume 01 su -l -c /home/crux/Cosas/gaim/dbus-hack.sh crux &

Y después de todo eso voodoo ya está lista para hibernar. Me basta con escribir “sudo hibernate” en la consola. Me queda armar un icono en algún lado del escritorio/paneles para no tener que escribirlo, pero no sé si lo haré algún día. Espero que estos tips le sean de utilidad a alguien.