Liberar, activar y hacer jailbreak a un iPhone Edge con firmware 3.1.3

Por motivos de trabajo ha caído en mis manos un iPhone de primera generación (algunos lo llaman iPhone Edge) con el que, en primera instancia, intenté hacer las cosas “a la Apple”. Para ello, restauré el teléfono con iTunes, deshaciéndome del jailbreak que tenía instalado e instalando el firmware más moderno para esta versión, el 3.1.3.

Lamentablemente, al ser un iPhone traído allende los mares, está atado al operador AT&T, y además necesita ser activado, por lo que al final tuvimos que volver al jailbreak (ah, ironía, cómo te gusta repartir patadas en el culo :D ), ya que la activación y liberación sin hacer un jailbreak previo es, como poco, no trivial.

Hacerlo no es nada difícil una vez conoces los pasos, pero al ser un modelo antiguo, me costó bastantes prueba y error hasta dar con la fórmula. Básicamente hay que hacer tres cosas:

  1. Obtener el software redsn0w (en mi caso usé la versión 0.92, el resto de instrucciones son para esta versión).
  2. Obtener el firware 3.1.2 para iPhone Edge.
  3. Usar redsn0w con el firmware 3.1.2 (iPhone1,1_3.1.2_7D11_Restore.ipsw).

La clave es no usar el firmware que tienes instalado, el 3.1.3 (iPhone1,1_3.1.3_7E18_Restore.ipsw), pues si lo haces obtienes un bonito mensaje: Unable to recognize specified IPWS. Una vez sabes esto, hacer el jailbreak, y liberar el iPhone es coser y cantar.

SyntaxError: invalid syntax usando equery en Gentoo

Usando Gentoo, me encontré con el siguiente error al lanzar el mandato equery:

$ sudo equery belongs somefile
  File "/usr/bin/equery", line 271
    print pp.path(" /" + c[0])
           ^
SyntaxError: invalid syntax

Tras darle unas vueltas y no encontrar gran cosa en Internet Google :D , acabé pensando que podía tener que ver con el intérprete de python instalado. No estoy seguro de cómo llegué a esa conclusión, pero supongo que ayudaron el hecho de ver que equery está escrito en python, que mi sistema tenía instalados varios intérpretes (concretamente los más actuales de la versión 2 y 3 del mismo), y que otra máquina con Gentoo usaba otro intérprete y no sufría el problema.

Para resolverlo, lo primero es buscar pistas. Al trabajar con varias versiones, lo normal es que el ejecutable sea un enlace a la versión elegida. Así que fue cuestión de ver a dónde apuntaba dicho enlace y buscar el paquete involucrado.

$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 14 jul 14 12:21 /usr/bin/python -> python-wrapper
$ equery belongs /usr/bin/python-wrapper
[ Searching for file(s) /usr/bin/python-wrapper in *... ]
app-admin/eselect-python-20100321 (/usr/bin/python-wrapper)
$ equery files app-admin/eselect-python
[ Searching for packages matching app-admin/eselect-python... ]
* Contents of app-admin/eselect-python-20100321:
/etc/env.d/python/.keep_app-admin_eselect-python-0
/usr/bin/python-wrapper
/usr/share/eselect/modules/python.eselect

Parece que eselect es la herramienta que usa portage para decidir qué versión se usa cuando un paquete tiene varias instaladas. Por lo que se ve arriba, cada paquete instala sus propios módulos para informar a eselect de qué versiones hay disponibles, etc. A partir de aquí, jugando un poco con el mandato eselect, encontrar la forma de cambiar la versión no es difícil:

$ eselect
Usage: eselect   
...
$ eselect python
Usage: eselect python  
...
$ eselect python list
Available Python interpreters:
  [1]   python2.6
  [2]   python3.1 *
$ sudo eselect python set python2.6

Y, efectivamente, eso resuelve el problema y equery vuelve a funcionar :) .

Could not find compatible GRE between version 1.9.1.8 and 1.9.1.8 al arrancar Firefox

Ayer, al emerger el mundo (qué épico suena) en Gentoo, me encontré con que Firefox no arrancaba. Tras lanzarlo desde una terminal me daba el siguiente error:

$ firefox
Could not find compatible GRE between version 1.9.1.8 and 1.9.1.8.

Parece que Firefox anda buscando una versión de GRE que esté entre la 1.9.1.8 y la… 1.9.1.8. Vamos, que tiene que ser la 1.9.1.8 :D . El siguiente paso lógico sería buscar el paquete gre, pero el resultado es algo desalentador :) :

$ equery list gre
[ Searching for package 'gre' in all categories among: ]
* installed packages
[I--] [  ] sys-apps/grep-2.5.4-r1 (0)
[I--] [  ] x11-proto/bigreqsproto-1.1.0 (0)

También podemos probar con eix, pero el resultado es aun peor (me lo ahorro por la longitud de la salida). Sin embargo, tras hacer una búsqueda en /etc (un buen lugar para empezar a buscar), vemos que al menos tiene ficheros de configuración:

$ sudo find /etc/ -name 'gre*'
/etc/gre.d

Para los que venimos de Debian, el siguiente paso es consultar una guía de comparación de mandatos de gestores de paquetes, un recurso útil que nos da el equivalente a un dpkg -S y buscar a qué paquete pertenece ese fichero:

$ equery belongs /etc/gre.d/
[ Searching for file(s) /etc/gre.d in *... ]
net-libs/xulrunner-bin-1.8.1.19 (/etc/gre.d)
net-libs/xulrunner-1.9.1.8 (/etc/gre.d)

Sabiendo que xulrunner es nuestro sospechoso, basta con ver qué versiones hay disponibles:

$ eix xulrunner
[I] net-libs/xulrunner
Available versions:
(1.8)    1.8.1.19
(1.9)    *1.9.0.11-r1 1.9.0.14 1.9.1.6 1.9.1.8 1.9.2-r5 ~1.9.2.2-r1
{+alsa custom-optimization dbus debug elibc_FreeBSD gnome ipv6 java libnotify python sqlite startup-notification system-sqlite wifi xinerama}
Installed versions:  1.9.2-r5(1.9)

Y comprobar que la versión que queremos es la 1.9.1.8, estando instalada la 1.9.2-r5. Para bajar de versión, nada más fácil que enmascarar la que está instalada y volver a emergerla:

$ sudo echo "=net-libs/xulrunner-1.9.2.3-r1" >> /etc/portage/package.mask
$ sudo emerge xulrunner
$ firefox

Problema resuelto, y oye, siendo el primero de este estilo al que me enfrento por mi cuenta, sienta bien :D .

Mandato PS con salida “personalizada”

Una opción del mandato ps de los sistemas operativos tipo Unix que no suele estar muy bien documentada y que en mi opinión es tremendamente útil es la que permite personalizar la salida del mandato para que muestre la información que te interesa de cada proceso.

La opción es -o, y acepta como argumentos una gran cantidad de posibilidades, que normalmente se encuentran descritas en la página del manual como standard format specifiers (o directamente no se encuentran :D ).

Un ejemplo de cómo lucen normalmente las órdenes de tipo ps que suelo lanzar en mis terminales:

$ ps fax -o user,uid,pid,ppid,pgrp,%cpu,%mem,rss,vsize,size,tname,etime,start_time,args
USER       UID   PID  PPID  PGRP %CPU %MEM   RSS    VSZ    SZ TTY          ELAPSED START COMMAND
root         0  3434     1  3434  0.0  0.1   552   5404   464 ?        12-22:14:08 Feb23 /usr/sbin/sshd
root         0 14466  3434 14466  0.0  0.5  2572   8124   512 ?              36:04 12:13  \_ sshd: deigote [priv]
deigote   1000 14469 14466 14466  0.0  0.2  1440   8280   668 ?              36:01 12:13      \_ sshd: deigote@pts/2
deigote   1000 14470 14469 14470  0.0  0.6  3344   6548  2172 pts/2          36:01 12:13          \_ -bash
root         0 16310 14470 16310  0.1  0.2  1196   4292   472 pts/2          00:06 12:49              \_ su -
root         0 16311 16310 16311  0.0  0.3  1688   4740   364 pts/2          00:03 12:49                  \_ -su
root         0 16315 16311 16315  0.0  0.2   992   4148   580 pts/2          00:00 12:50                      \_ ps fax -o user,uid,pid,ppid,pgrp,%cpu,%mem,rss,vsize,size,tname,etime,start_time,args

Y, de hecho, un par de alias que suelo tener siempre definidos, entre otros, son:

alias ps='ps fax -o user,uid,pid,ppid,pgrp,%cpu,%mem,rss,vsize,size,tname,etime,start_time,args'
alias psg='ps | head -n 1 && ps | grep'