Bueno, llevo ya una temporadita con el iPod Touch mas contento que unas castañuelas desde que lo compré (allá antes de las pasadas navidades) y desde que tengo la version 1.1.3 jailbreak siempre he tenido un problema a la hora de hacer un reinicio del hardware: la entrada del iPod Touch en recovery mode, esa imágen que obtenemos cuando compramos un iPod que consta del cable del mismo y una flecha apuntando al icono del iTunes, diciendonos que conectemos el iPod al iTunes.
El reinicio de hardware solo se da ante dos ocasiones:

1. Te quedas sin batería.
2. Haces un apagado forzado manteniendo pulsados los dos botones.

Contrariamente a lo que mucha gente piensa, el ‘apagado’ que se consigue manteniendo pulsado el botón de encendido no es un reinicio del hardware real si no que al parecer el iPod Touch entra en un modo de hibernación, de manera que al encenderlo de nuevo no entra en modo de recuperación.

Otra diferencia entre el apagado real y la hibernación en el iPod Touch es que tarda mucho menos en arrancar desde la hibernación que desde el apagado real.

Volviendo al tema principal, es fácil arrancar el iPod Touch desde el modo de recuperación con programas como el iBrick que con un simple toque de ratón teniendo conectado el iPod Touch al ordenador nos quita el modo y nos consigue arrancar el iPod.

El problema de este método es que dependemos del ordenador, por lo que si por cualquier motivo sufrimos un reinicio del hardware en cualquier situacion lejana a un PC con iBrick (estás en clase y derrepente se te cuelga el iPod por una aplicación experimental) te tienes que esperar a poder conectar el iPod a algun ordenador para arrancarlo.
Existe una forma de arreglarlo, aunque personalmente pienso que es un poco chapuza ya que no indaga en el motivo real de la entrada del iPod en el modo de recuperación si no que hace un bypass del modo de recuperación, es usando una aplicación de linea de comandos que viene dentro del mismo directorio de iBrick (si no lo tienes puedes descargarlo de aqui) llamada iphoneinterface.exe.

Desde Windows, ejecutamos el iphoneinterface.exe con un doble click habiendo conectado el iPod Touch en modo recuperación previamente (obvio) y nos aparecerá el siguiente mensaje:

s_iPhoneInterface
s_Logging in restore.log: 0
s_I NEED A WAY TO EXIT THIS MODE
s_To exit, you need to do a full restore
r_recovery

Es importante que nos aparezca la última línea que dice r_recovery ya que nos indica que se ha detectado un iPod en modo de recuperación.

Ahora se le tiene que decir a la ‘bios’ del iPod que arranque siempre de forma automática:

setenv auto-boot true

y despues guardar los cambios y arrancar:

saveenv
fsboot

Con lo que despues de ejecutar las 3 instrucciones la consola quedaría así:

s_iPhoneInterface
s_Logging in restore.log: 0
s_I NEED A WAY TO EXIT THIS MODE
s_To exit, you need to do a full restore
r_recovery
setenv auto-boot true
s_setenv auto-boot true: 0
r_recovery
saveenv
s_saveenv: 0
r_recovery
fsboot
s_fsboot: 0
r_recovery

Realmente a mi con el comando fsboot no me arrancó el iPod, le hice otro hard reset manteniendo pulsados ambos botones y al encenderlo de nuevo ya me arrancaba bien y sin problemas.

La verdad es que soy algo paranoico respecto a tener servicios cara a internet, por ello todos tienen sus jaulas, y UnrealIRCd no iba a ser menos.

UnrealIRCd tiene una opcion en include/config.h que al menos en teoría debería de autoenjaularse, pero no parece funcionar bien, por lo que he decidido ejaularlo a la antigua.

Para ello a la hora de compilar le defino un directorio temporal (donde quiero mi configuración y binario, /Unreal) y tras compilar y hacer make install, se creará la carpeta /Unreal (ojo, sin los certificados, hay que copiarlos a mano) con el unreal listo para correr, pero como soy una persona dentro de lo normal ordenada, muevo la carpeta de / a /chroot/ircd, quedando /chroot/ircd/Unreal.

El siguiente paso consiste en copiarle las librerías adecuadas a la jaula para que funcione bien el binario. Para ello:

# cd /chroot/ircd; mkdir lib
# ldd /chroot/ircd/Unreal/ircd
linux-gate.so.1 => (0xffffe000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xa339e000)
libnsl.so.1 => /lib/tls/libnsl.so.1 (0xa3388000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xa3384000)
libc.so.6 => /lib/tls/libc.so.6 (0xa324c000)
/lib/ld-linux.so.2 (0xa33d7000)
# cp /lib/libcrypt.so.1 lib/
.. (seguimos copiando librerías)
# cp /lib/libc.so.6 lib/

Ahora viene el directorio /etc de nuestra jaula. Para ello he creado en mi sistema el usuario ircd y creado en /chroot/ircd/etc sendos archivos passwd con solamente la linea de usuario ircd y group con la linea de grupo para posteriores permisos. También he copiado los archivos localtime y resolv.conf desde /etc a /chroot/ircd/etc.

Por último, es necesario para el correcto funcionamiento de UnrealIRCd (al menos con soporte ssl) el dispositivo /dev/urandom:

# mkdir dev; cd dev
# mknod -m 0644 /chroot/ircd/dev/urandom c 1 9

Con todo esto la jaula ya debería de estar preparada para ser lanzada. No hay que olvidarse de configurar correctamente el unrealircd.conf ni de los permisos:

# chown -R ircd:ircd /chroot/ircd

Para correr el ircd, yo recomiendo usar chrootuid, que es como chroot pero que rueda el programa deseado como un usuario específico:

# chrootuid /chroot/ircd ircd /Unreal/ircd

Si todo funciona correctamente el UnrealIRCd ya debería de estar corriendo perfectamente enjaulado.

Hace exactamente un año que encontré en el rastro esta pedazo de controladora RAID SCSI en el rastro y que la instalé en mi server con una configuración RAID5 redundante de 3 discos de 9.1Gb 10.000 rpm y hoy por casualidad, trasteando con un juguete que pronto publicaré he conseguido acceder (por fin, llevaba tiempo peleandome) a la ‘administración en vivo’ de la controladora, es decir, poder conectar, desconectar discos, crear gestionar y eliminar contenedores y un sin fin de tareas sin necesidad de apagar/reiniciar el ordenador.

Para ello después de mucho surfear por las infinitas páginas que contiene la web de soporte de Dell conseguí encontrar la utilidad mágica, afacli, disponible desde la web de Dell desde aqui.

La utilidad viene empaquetada como rpm, pero por suerte alien realiza una conversión estupenda del paquete a deb. Quien utilice Redhat o distribuciones con el gestor de paquetes rpm no necesita hacer la conversión a deb. Es necesario tener libncurses4 para que funcione la utilidad de gestión de la controladora.

Una vez instalado nos topamos con el problema de que la utilidad busca la controladora como /dev/afa0, pero este dispositivo por defecto no suele existir en las máquinas linux, por lo que hay que crearlo manualmente. Para ello el paquete que hemos instalado incluye un script llamado MAKEDEV.afa que se ha instalado en /dev y que procederemos a ejecutar de la siguiente manera:

# cd /dev
# MAKEDEV.afa afa0

Si este procedimiento fallara (normalmente por no encontrar menciones al dispositivo que busca, ‘afa’) bastaría con editar el script MAKEDEV.afa y cambiar la linea #2 (variable devname) por:

devname=”aac”

De modo que el script pueda reconocer el dispositivo (usa un cat /proc/devices) y crear así el dispositivo con mknod. Si todo ha ido bien, tendremos un bonito /dev/afa0 que será perfectamente reconocido por afacli y ya podremos gestionar la controladora en vivo sin necesidad de reiniciar el equipo.

P.D: Este artículo es válido tanto para PERC2 como PERC3/Di (probado en ambos).

Pues bien, hace poco he conseguido parchear el kernel con éxito ya que realmente no me apetecía ponerme a compilar un kernel desde cero de nuevo.

El parche para las versiones 2.6.17-2.6.24.1 se puede encontrar aqui.

El parche básicamente añade el siguiente código a nuestro $LINUX_SRC/fs/splice.c:

if (unlikely(!access_ok(VERIFY_READ, base, len))) break;

Tan asombrosa la solución como el xploit.

Pues bien, como ya dije anteriormente, el HyperX tiene un switch que nos permite seleccionar que bios arrancar, pero con el inconveniente de que este conmutador se haya en el propio modchip, por lo que si en cualquier momento quisieramos cambiar de bios, tendríamos que abrir la Xbox y darle al conmutador.

La verdad es que es una escena jodida si trasteas mucho con la consola como me sucede a mi, por lo que he decidido poner el conmutador fuera, muy a mano para cambiarlo en cualquier momento y muy escondido para evitar dañar la estética de la consola.

Este es el conmutador que he empleado, uno normal de palanquita y dos posiciones. Está pegado a esa rendija en concreto porque en el plastico de la caja principal hay espacio para el conmutador. En otras rendijas no se puede montar.

Esta es la vista inferior del conmutador, bien centradito.

Y esta es la vista frontal. Como se aprecia, el conmutador de BIOS estará a mano bajo el logotipo de M$ (vaya ironía) y solo sobresaldrá un poco, no dañando así la estética de la consola.

Este es mi modchip, el HyperX. Le he desoldado con cuidado el conmutador que venía soldado en la plaquita y en su lugar le he soldado los 3 cables que provienen del conmutador que está instalado en el frontal.

A la hora de realizar el montaje he seguido este orden:

1. He soldado 3 cables largos al conmutador que iba a instalar en el frontal.
2. He pegado con pegamento de cianocrilato el conmutador al frontal de forma que la palanquita asome hacia afuera por una de las rendijas de ventilacion y no roce/tropiece con el plastico de la carcasa.
3. He montado el frontal y pasados los cables todos por el mismo agujero, el que originalmente estaba para los cables del panel frontal (botonera y leds).
4. Con el modchip fuera de la consola para un trabajo mas seguro y cómodo he desoldado el conmutador original que venía con el modchip (nunca se sabe que puede pasar, como caerse una gota de estaño en la circuitería de la consola jodiendola con un corto).
5. He solado los 3 cables provenientes del conmutador que he instalado en el frontal al modchip en el lugar donde estaba antes el conmutador que venía de serie.

Antes de cerrar la consola, es conveniente conectarla a la TV para comprobar que el modchip y el mod del conmutador frontal funcionan adecuadamente.