Ext4 superblock failure y la cola del Diablo

Domingo, ciudad de Guayaquil, todo dispuesto para salir a conocer una ciudad que en las guías de viaje suena intererante y bonita. Se me ocurre prender la compu para ver si ese email que mandé la noche anterior, recién llegado después de 14 horas de viaje (5 de espera en el aeropuerto de Santiago) y deseando únicamente ducha y colchón, había sido contestado.

"No pusheé", fué lo primero que pensé, o me lo dije, en voz inaudible, como eufemismo de un gran insulto y síntesis de "Martincito querido, ya sabés que el booteo está tardando mucho, el material para el taller_ que tenés que dar mañana está en esa computadora y tiene al menos 10 horas de trabajo offline que está en la última versión online: no podés ser tan pelotudo y tener tan mal orto a la vez". Mi voz interior sí que sabe resumir.

Por suerte, no perdí la calma. Apreté el 1 en el teléfono: "sí señor", el Bussiness Center queda en el 4 piso". Ahí fui y habia computadoras con las que pude contactarme con Houston.

Grulic, Perrito, Mariano, Rudi, y especialmente mi cuñado que trabaja en Ontrack y era algo así como un Messi sentado en mi banco de suplentes para este partido que yo no hubiese querido jugar, fueron los primeros con quienes me comuniqué.

Mandé este mensaje:

Gente, les mando una de Murphy y el diablo y toda la mala leche junta. Estoy en Ecuador invitado a dar un curso-taller de Python y Django.

Rodo venía fantastico , hasta que hoy enciendo la laptop y no y no entra el sistema operativo!.

Entro en modo recuperacion (ubuntu 11.10) y se clava en el fsck hasta que me aparece un menucito que me deja entrar a una consola root. Lo peor sucedió /home/ no monta , pero el / parece estar sano. Ambas son una particion ext4

Si intento montar a mano o un fsck, el output dice muchas cosas que suenan mal pero no tengo puta idea qué significan:

STATUS { DRDY }
ERROR { UNC }
configured for UDMA/133
failed command READ DMA
exception Emask 0x0 Sact 0x0 Serr 0x0 action 0x0
res 51/40... Emask 0x9 (media error)

Por favor, iluminenmé sobre cómo proceder.

Ernesto contestó. Primero intentar hacer un un live-usb con algunas herramientas de diagnostico: Ubuntu-rescue-remix podría funcionar, pero las maquinas del Bussiness center no me dejan instalar algun programita para pasar la ISO al pendrive.

Empiezo a deseperar ya pensar si no conviene aprovechar el tiempo que me llevará intentar un salvataje con alta probabilidad de fracaso para rehacer el trabajo inaccesible.

Desactivar journal, no. Forzar montado, no. No se qué otra cosa, no.

Ernesto pregunta si me animo a ir por el camino duro.

Cómo estás de fresco ara leer hexadecimal ? hexdump y dd, la navaja suiza. que necesitamos

Intentamos algunas cosas, calculadora en mano, pero la mayoría de los intentos de acceso al disco caen en el mismo bucle de errores horribles. Mucho calor en Guayaquil.

Le digo a Ernesto (domingo, dia de descanso) que no se preocupe, que intentemos eso último que se le ocurrió pero que si no funciona voy a ponerme a trabajar de nuevo. Mientras tanto, el Dios en el que no creo me pone este link en el camino de resultados de Google.

"Ernesto, prabamos esto?" y no alcanzó a contestar antes de que esté poniendo los primeros comandos

$ sudo mke2fs -n /dev/sda3

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Me la juego con el primer backup:

sudo e2fsck -b 32768 /dev/sda3

Cientos de Y Enter para mensajes estilo "está roto, desea repararlo?" (no había una opción "Sí a todo", como si uno fuese capaz de arrepentirse a mitad de camino)

Anduvo. Uff. Dos simples comandos. El Ingeniero Lobo festeja desde Londres, Skype mediante, que podía volver a limpiar su moto sin quedar mal con su cuñado con mala pata. Me dijo antes:

Si no hubiese sido una situadion del tipo mañana ya no me sirven los datos yo te hubiera recomendado en contra de herramienta como e2fsck. Esos programas sólo se encargan de asegurar que el filesystem esté íntegro, pero si para eso tienen que cortarlo a la mitad lo hacen sin dudar. Son como doctores de guerra: te dejan vivo, pero sin una pierna y un brazo.

Querido Guayaquil: prometo visitar tu Malecón la próxima, push por adelantado.

Notas rápidas de una mudanza

Hace unos días abría este espacio prometiendo migrar contenidos y tratar de que se vea un poco más bonito.

Este post incluye algunas notas sobre lo que he hecho hasta el momento.

Github ♥ Nikola

Este blog que estás leyendo está hospedado en Github Pages , el servicio de hosting gratuito de contenido estático que ofrece Github.

A diferencia de cuando se usa Gh-pages para proyectos, donde se sirve el contenido del branch gh-page del proyecto en cuestión, para usar gh-pages por usuario hay que crear un repo llamado <username>.github.com (donde <username> es el tuyo) y lo que sirve en http://<username>.github.com es directamente el branch master (referencia)

Por este motivo creé otro branch (que sin mucha imaginación denominé writing ) donde tengo todo el mi "proyecto" hecho con Nikola

Allí escribo, intento mejorar mi theme, y corro nikola build.

El branch master es el de deploy y sirve todo lo que haya en la carpeta output/ del branch writing. Para hacer esto hay que ir a master, borrar todo y leer desde el árbol del otro branch con read-tree

git checkout master
git rm *    # sólo la primera vez
git read-tree writing:output
git commit -m 'deploying last build'
git push

Migrando desde Spip

Uno de los motivos que me llevaron a migrar desde Spip es que el markup que usa es ad hoc y muy feo. Algo así

{{{ Un intertítulo }}}

Esto es {{negrita}} y este [mi twitter->http://twitter.com/tin_nqn_]

Hasta ahí no se ve tan mal, pero es muy limitado cuando se trata de mostrar código, necesario en todo blog mas o menos técnico.

Para migrar esquivé la idea de convertir el markup de spip y opté por un scrapping, limpieza y conversión a restructuredText usando el mágico Pandoc (y la ayuda de PyQuery)

El script que hice está acá . No es perfecto, pero está lo importante: contenidos, imágenes, adjuntos, convertido a restructuredText bastante decente que mejoraré poco a poco a mano.

Estilos

Es mentira que a los ñoños no nos gustan las cosas (los blogs, entre otras) que se ven bonitos. Sucede, en realidad, que la mayoría de las veces no venimos con esa habilidad y el esfuerzo que nos implica intentarlo preferimos ponerlo en otra cosa. No gusta, pero no es lo más importante.

No obstante, yo quiero que este espacio sea lindo y legible. Y como hay muchos otros ñoños con sitios lindos y legibles que son tan amables de compartir sus estilos (y existe bootstrap, claro) voy a ir intentándolo, incrementalmente.

Por ahora tomé ideas y CSS de stevelosh.com [1] y de la documentación de Flask [2] basado en el theme Readable de bootswatch.com

Disqus

El blog viejo usaba Disqus, con un plugin que hice hace algun tiempo. Para migrar los comentarios utilicé el método de subir un CSV con el formato que genera el mismo script de migración:

URL_POST_X_OLD, URL_POST_X_NEW
URL_POST_Y_OLD, URL_POST_Y_NEW

En cuestión de minutos los (pocos) comentarios estaban migrados.

Redirección

Como mantuve el slug de los viejos artículos, una redirección 301 via .htaccess redirige del viejo blog al nuevo:

# nqnwebs.com blog rules
RewriteCond %{HTTP_HOST} ^nqnwebs [nc]
RewriteRule ^blog[/]?$ http://mgaitan.github.com/ [R=301]
RewriteRule ^blog/article/(.*)$ http://mgaitan.github.com/posts/$1.html [R=301]

¿Cómo se va viendo?

[1] https://bitbucket.org/sjl/stevelosh/src/6432040d5154/LICENSE?at=default
[2] https://github.com/mitsuhiko/flask-sphinx-themes/blob/master/LICENSE

Bievenidos al tren

Hola!

Este blog está en pleno proceso de mudanza y metamorfosis. Antes estaba en http://nqnwebs.com/blog y utilizaba SPIP. Por diversas razones que explicaré más adelante, estoy migrandolo a Nikola utilizando Github como plataforma de versionado y hosting.

Espero que pronto esto esté más bonito y con contenido. También que la mudanza y el cambio de herramienta (y paradigma) me ayude a escribir más.

De mercurial a git, limpieza mediante

Cuando decidí dar el salto desde Subversion a un DVCS estuve leyendo muchos posts comparativos entre las dos opciones más relevantes, Git y Mercurial. Había que elegir entre Mc Gyver o James Bond decía uno, entre Denzel Washington y Wesley Snipes y la comparación jocosa entre estos dos grandes softwares se volvió una especie de meme tácito.

Sabía que, a fin de cuentas, tenía que probarlos y ver cual encajaba mejor para mis necesidades de "solo developer". En el medio leí Hg Init del gran divulgador Joel Spolsky y, víctima de semejante labia, me sumergí para ese lado.

Mi flujo de trabajo era bastante básico pero suficiente y superador de subvesion. Comparado con lo que había probado de Git era mucho menos verbósico (no podía entender la necesidad de Git hacer add cada vez que quería commitear un archivo modificado) y Bitbucket daba no sólo hospedaje gratuito para repositorios públicos sino también para potenciales desarrollos privados (cosa que GitHub, su equivalente — siendo benévolo con bitbucket — para Git, no daba).

Con el tiempo empecé a compatir algunos proyectitos con otros desarrolladores y mi inexperiencia en Mercurial me empezó a jugar en contra. Y justo cuando necesitaba ponerme a aprender más profundamente Hg, entre a laburar, muy a gusto, en Machinalis (qué vago, nunca conté nada por acá) donde usamos Git para el control de versiones de los proyectos, implementando esta política de ramificación y mezcla.

Resultó entonces que en poquito tiempo ya sabía mucho más de Git que de Mercurial (con la ventaja de tenerlo a Daniel Moisset cerca para apagar algunos incendios que encendí las primeras semanas).

Para más señales, Atlassian, la empresa detras de Bitbucket y principal referente de Mercurial (junto con Selenic, la creadora), comenzó a ofrecer Git (sin descartar mercurial) como sistema DVCS (comiéndose alguna que otra gastada porque alguna vez comunicó una noticia parecida como broma del dia de los inocentes).

Asi que llegó el dia que decidí mudar un proyecto en Mercurial a Git. Atenti: las razones no son técnicas. No tengo suficiente conocimiento de Mercurial (ni de Git) para decir que uno es mejor que el otro por tales razones. Sólo es *mi experiencia*, que vino un poco por obligación. Y sí, también, siguiendo un poco a la manada. Proyectos de la envergadura de Django han migrado a Git (y, particularmente, a GitHub)

La limpieza

Soy de esos que se mudan seguido. "¿Asi que si te renuevo contrato me aumentas 30 % el alquiler e igual te tengo que pagar comisión sin que hagas nada? ¡Andá a cagar!" puedo imaginarme dialogando con algun agente inmobiliario.

Esta no era la excepción y debía mudar un repositorio mercurial que a su vez había sido mudado (en realidad, exportado desde el último commit, y arrancando de 0) desde subversion.

El detalle es que el repositorio original, y por ende el nuevo en mercurial, tenia un montón de datos de documentación que era, basicamente, todos los fuentes y muchos de los archivos generados del reporte escrito de mi tesis.

El primer changeset en el flamante mercurial consistió en borrar todo esa información innecesaria, pero que seguía allí, en el historial (uno 110Mb de datos que no necesitaba).

Así que ya que ahora iba a mudarme de nuevo, queria tirar a la basura todas esas cajas de papeles que había metido en un caja y, si bien no la veía, me ocupaban el placard.

Despues de darle vueltas, encontré una punta usando la extensión hg convert para obtener un subconjunto de repo original, por ejemplo, partiendo de un determinado cambio.

  1. Primero, activar la extensión editando ~/.hgrc:

    [extensions]
    convert =
    
  2. ¡Tirar las cajas del placard!

    $ hg convert --config convert.hg.startrev=1 repo_hg_orig/ repo_hg_liviano/
    

En mi caso yo queria todo desde la revision 1. Atenti: como explica, esto genera un repo totalmente nuevo, con ids distintos para los changesets, de modo que no se puede mantener "sincronizados" ambos con el mismo cambio (al menos no de manera directa).

La mudanza

Contra todo pronóstico fruto de mi prejuicio y desidia, migrar a git fue extremadamente fácil usando hg-fast-export.

  1. Obtener los scripts

    $ git clone git://repo.or.cz/fast-export.git
    
  2. Convertir!

    $ mkdir repo_git
    $ cd repo_git
    $ git init
    $ ~/fast-export/hg-fast-export.sh -r ~/repo_hg_liviano/ --force
    

¡Charánnnn...!

El flag --force era necesario en mi caso porque, como explica el readme.txt "hg-fast-export supports multiple branches but only named branches with exaclty one head each...".

El resultado fue un repo git que ocupa el 5% (5.6mb) que el mercurial original que sin perder la historia útil.

Parafraseando a Lito, si la historia la escriben los que ganan ... ¿ganamos ?