domingo, noviembre 05, 2017

A veces "dd" requiere un poco más de colaboración

domingo, noviembre 05, 2017

Hace tiempo hice un blog relacionado con una tablet (que compré sólo y exclusívamente para tenerla con Linux y Gnome, un proyecto que al final, después de medio millar de caídas y cambios de pantalla táctil dejé abandonado) en el que aprendí mucho sobre este tipo de tecnologías (tablets con arquitectura intel x86).

La verdad es que en aquel entonces tenía muchas más ganas que hoy, pero el conocimiento que tenía era bastante menor que el que tienes ahora.

Por suerte, hay días en los que las ganas de volver con ese proyecto no son pocas, y he ido avanzando en aquello. En esta ocasión he querido jugar con Android x86 rooteandolo a mano, disponiendo de las imágenes Android originales (como backup), pero este backup no está realizado por mí, sino publicado por el fabricante (en este caso Teclast, como en la anterior ocasión).

Después de un error humano, en el que un script que lancé comando a comando parecía estar incompleto, mi partición de system estaba dañada, y he aquí el problema, cuando intenté hacer dd if=system.img funcionó, pero no como estoy acostumbrado a ver. La imagen que se había desplegado estaba corrupta y no era legible.

El comando file me abrió las puertas a ver qué pasaba y descubrí el problema, el cual radicaba en que estaba utilizando un formato diferente al que hace dd (binario).

Entonces recordé en el pasado, cuando no existían las herramientas de cocinado de roms actuales en las que el proceso es prácticamente automático, que para convertir las imágenes originales del formato "android" a un formato que pudiera montar realizaba una conversión previa. Me refiero al comando "simg2img" y "simg2img".

simg2img system.img system.img.tmp && resize2fs -M system.img.tmp
 
Finalmente pude hacer mi dd como estaba acostumbrado, a veces conviene recordar los pequeños detalles, unos detalles que olvidamos con el paso del tiempo pero que resuelven todos los problemas.


Bit
Hide Me!