Instalando Windows desde un pen

Por una serie de circunstancias, este fin de semana necesité instalar un Windows XP en mi portátil, y una tarea tan aparentemente sencilla se convirtió en una tortura. ¿Por qué?

Lo que todo el mundo pensará es que basta con meter el CD en la unidad, reiniciar, y listo. Pero mi portátil es un EEE PC sin lector de CDs. Así que lo siguiente que se piensa es en utilizar un lector de CDs por USB… pero no tenía ninguno a mano, y no me apetecía comprar uno sólo para una vez.

Una opción era utilizar WinToFlash, una utilidad que permite meter el instalador en un pendrive; por desgracia sólo funciona en Windows… y no tengo ningún windows a mano. Incluso intenté hacerlo desde una máquina virtual, pero no funciona: es muy exigente y quiere un pincho «de verdad», no le sirve un disco duro, y la emulación de pinchos USB en KVM da problemas (ya ni hablemos de VirtualBox…).

También intenté utilizar UnetBootin, que está disponible para Linux, pero desgraciadamente no sirve para el instalador de XP.

Sin embargo, a tozudo no me gana nadie, y al final conseguí instalarlo con mucha paciencia, así que aquí está el método, por si a alguien más le puede ser de utilidad.

Lo primero, avisar que el proceso de instalación será mucho más lento de lo normal, así que tomadlo con mucha paciencia y una buena infusión.

Ingredientes necesarios:

Lo primero, copiamos cualquier dato importante que tengamos en nuestro pincho USB a otro lado, porque vamos a tener que formatearlo.

Antes de comenzar la instalación, necesitamos disponer de una partición primaria reservada para el nuevo disco. En caso de que no la tengamos, la mejor opción consiste en crear, mediante UnetBootin, un pincho USB de Ubuntu, arrancar con ella el portátil y utilizar GParted para reducir el tamaño de una de las particiones actuales y dejar sitio para la nueva. Sobre como hacer esto hay  abundante material en Internet, así que no profundizaré.

Cuando ya tengamos una partición primaria en el disco, etiquetada con sistema de archivos FAT32 (importante) y situada antes que cualquier otra partición primaria de tipo FAT en el disco, procedemos a particionar el pincho USB. Lanzamos GParted, borramos todas las particiones que hubiese, creamos una partición extendida, y dentro una unidad lógica, etiquetándola como de tipo FAT32.

Una vez hecho esto, arrancamos UnetBootin, escogemos la imagen de CD fdfullws.iso, y la volcamos en el pincho. Cuando esté listo, copiamos en el pincho todos los archivos del CD de instalación de Windows.

Ahora estamos listos para hacer la instalación de FreeDOS: reiniciamos el ordenador con el pincho, y cuando pregunte, iniciamos con HYMEM y EMM386. Nos saldrá un prompt de DOS, en el que teclearemos D:. Gracias a que el pincho tiene solamente una partición extendida, C: se corresponderá con la partición primaria del disco duro, y D: será el pincho en sí. Si hubiésemos utilizado una partición primaria en el pincho, como éste aparece como primer disco haría que C: fuese el pincho en sí, con lo que no podríamos instalar correctamente FreeDOS.

Ahora tecleamos setup para iniciar la instalación de FreeDOS. Instalamos todo (excepto las fuentes, que no son necesarias), y salimos de nuevo al prompt. Ahora copiamos también todo el CD de instalación de Windows al disco duro mediante xcopy:

    xcopy /E d:*.* c:

Ahora tenemos que asegurarnos de que podremos iniciar el sistema correctamente, para lo que tecleamos

    sys c:
    fdisk /mbr

El primero asegura de que el sistema de arranque de FreeDOS está instalado en C:; el segundo borra el MBR (lo que incluye a GRUB; luego lo recuperaremos) y pone en su lugar el código de arranque básico de DOS.

Reiniciamos el ordenador y debería arrancar FreeDOS. Ahora tecleamos:

    ./i386/winnt.exe

lo que lanzará el instalador de Windows XP. Nos dirá que la caché de disco no está instalada y que podemos cancelar el proceso. No lo haremos; eso sí, la copia de archivos se demorará durante un par de horas (y no sirve la caché que incluye el propio FreeDOS: no funciona). Nos tomaremos un buen café hasta que, por fin, termine de copiar los archivos básicos y reinicie, continuando, ahora sí, por fin, la instalación como siempre.

En determinado punto nos indicará que la unidad está en formato FAT32 y si queremos convertirla a NTFS. En teoría el cambio no supone la pérdida de los datos, pero por si acaso yo preferí hacer la conversión después de instalar todo, y, efectivamente, se puede hacer sin riesgo.

Recuperando GRUB

Ahora que ya está instalado Windows nos queda recuperar GRUB para poder arrancar de nuevo Linux. Para ello volvemos a particionar el pincho, dejando una única partición primaria, instalamos en ella un CD Live de Ubuntu u otra distribución preferida y arrancamos desde él.

Una vez hecho, abrimos un terminal y procedemos a montar la partición raíz de nuestro sistema Linux, así como enlazar los pseudo sistemas de archivos /proc, /dev y /sys. Finalmente, usamos chroot para entrar en nuestro viejo sistema. Si la partición raíz está en /dev/sda1 y tenemos el directorio /tmp disponible para montar en él lo que queramos, haríamos:

    mount /dev/sda1 /mnt
    mount -o bind /proc /mnt/proc
    mount -o bind /dev /mnt/dev
    mount -o bind /dev/pts /mnt/dev/pts
    mount -o bind /sys /mnt/sys
    sudo chroot /mnt /bin/bash

Ahora ya estamos dentro de nuestro sistema como root,  y podemos proceder a reinstalar GRUB. En Ubuntu es tan sencillo como

    dpkg-reconfigure grub-common

el cual reconfigurará GRUB para añadir automáticamente el nuevo windows instalado. En otras distribuciones de Linux es necesario utilizar un editor para modificar el fichero de configuración de GRUB y luego ejectuar grub-install /dev/sda para reinstalarlo en el MBR.

¡Y listo!

InkScape no tiene quien le escriba

Desde que actualicé a la última versión de Ubuntu, InkScape me estaba dando problemas a la hora de añadir tipografías: cada vez que intentaba escribir algo se negaba a cambiar a la fuente o tamaño que yo le decía, y me mostraba una alerta junto a la fuente, que siempre volvía, una y otra vez, a Bitstream Vera Sans, escogiese la que escogiese.

 

Tras rebuscar y rebuscar, encontré en un foro de Ubuntu que el problema es, precisamente, que dicha fuente (que es la que InkScape utiliza por defecto) no está instalada, y por un bug, no deja cambiar a ninguna otra.

La solución fue instalar el paquete ttf-bitstream-vera con un sencillo:

sudo apt-get install ttf-bitstream-vera

(aunque los que odien la línea de comandos pueden usar Synaptic, obviamente 😀 )

Enlace dinamico

Acabo de lanzar la versión 8.0 de FPT_BT4LXMedia. La primera novedad es la nueva versión de Transmission, la 2.21. La segunda es que, por fin, los ejecutables utilizan enlazado dinámico.

Como recordareis, las versiones anteriores utilizaban enlazado estático porque no conseguía que arrancasen desde el disco, a pesar de utilizar LD_LIBRARY_PATH para apuntar al directorio con las nuevas bibliotecas. Para los que no sepan qué es eso, es una variable de entorno que permite añadir nuevas rutas en donde buscar bibliotecas de enlace dinámico, y éstas tienen prioridad sobre las «normales» del sistema. Así, si tengo un programa enlazado con una versión concreta de libc, diferente de la del sistema, puedo instalarla en otro directorio (por ejemplo, /tmp/libs) y lanzar el programa con:

LD_LIBRARY_PATH=/tmp/libs mi_programa

Por desgracia, esto no funcionaba en mi disco duro. Tras investigar mucho, descubrí que el problema estaba en el enlazador dinámico en tiempo de arranque. Resulta que el núcleo sólo es capaz de arrancar, por sí solo, binarios que estén enlazados estáticamente. Para los dinámicos lo que hace es delegar en /lib/ld-linux.so (o /lib/ld-uclibc en la biblioteca uClib). A pesar de llevar extensión .so, este fichero es realmente un programa (enlazado estáticamente, claro) diseñado para cargar en memoria el programa dinámico deseado, analizar qué bibliotecas necesita, cargarlas en memoria si aún no están, realizar toda la operación de enlazado y, finalmente, lanzar el código.

Por desgracia, la versión del enlazador dinámico de la gentoo que utilizo para desarrollar es más reciente que la de mi disco duro, lo que hacía que recibiese un error cada vez que intentaba ejecutar un programa compilado directamente. Para complicar aún más las cosas, la ruta del enlazador dinámico está especificada en cada ejecutable de manera inamovible, estableciéndose dicho valor durante la compilación. Y por si fuera poco, el enlazador de Busybox no permite su ejecución directa, por lo que tampoco podía hacer un simple /lib/ld-uclibc mi_programa.

Ante todo esto, la única solución que me quedó fue la de copiar el enlazador dinámico del entorno de desarrollo en una carpeta diferente y, al compilar bftpd, transmission y ctransmission, especificar la ruta deseada. Esto se hace en la etapa final de enlazado mediante la opción -Wl,–dynamic-linker=path/al/enlazador. De esta manera bastó con copiar el enlazador y el resto de bibliotecas a /tmp/hdd/root/libs y lanzar los programas con

LD_LIBRARY_PATH=/tmp/hdd/root/libs mi_programa

Con esto espero ahorrar algo de memoria. También haré algunas pruebas para ver si los programas funcionan bien con la versión de la uClib del propio disco duro, en cuyo caso podría ahorrar aún más.

FBZX vuelve a la carga

Estos meses estoy trabajando como loco, así que poco tiempo he tenido para corregir cosas. Tengo una cola de mejoras pendientes para Devede que crece día a día, pero hasta que tenga lista la primera versión del nuevo proyecto no me quiero poner con otra cosa.

Pese a todo, he sacado un poco de tiempo para corregir un pequeño bug en el sistema de sonido de FBZX: al utilizar ALSA no definía el tamaño del buffer, sino que asumía que el asignado por defecto era adecuado. Hace unos años funcionaba porque ese valor era de unos 4Kbytes, pero algo han hecho (al menos en Ubuntu) y lo han aumentado mucho, por lo que el emulador iba a trompicones (utiliza el sistema de sonido para ajustar la velocidad). Con OSS o PulseAudio funciona bien, por eso el error pasó desapercibido. La nueva versión 2.4.2 lo corrige.

Entre signos anda el juego

Una de las frases preferidas de mi madre es Está el viejo muriendo, y está aprendiendo; y como en la gran mayoría de los refranes, hay una grandísima verdad oculta en ella.

Y es que estos días estoy peleándome con el micro ARM de un TomTom, y me encontraba con que el código que iba perfectamente en mi PC daba un fallo rarísimo en el GPS: al imprimir el carácter ‘/’ no lo hacía bien; pero sólo ese, el resto los renderizaba perfectamente. Después de mucho depurar, descubrí que el fallo era debido, nada menos, que al signo de una variable. Y es que, a pesar de utilizar el mismo compilador (GCC) para ambos casos, resulta que un char a secas en PC es signed, como todo el mundo asume, pero en ARM es unsigned, por lo que un valor que tenía que ser -1 se convertía en 255 (la segunda parte del problema es que luego operaba con ese valor y con otro de 32 bits, con lo que, al añadirle los 24 bits restantes, no expandía el bit de signo). Una vez añadido el modificador correspondiente, todo pasó a funcionar perfectamente.

Así pues, nunca deis por supuesto el signo de una variable. Consejo de amigo.

Desplazando bits

Hace mucho tiempo, cuando empecé a programar en C, leí una curiosa advertencia sobre los operadores de desplazamiento de bits, los famosos >> y <<. Se afirmaba allí que, al desplazar una variable con ellos, los bits que salían se perdían (lógico, siendo un desplazamiento), pero que los bits que entraban por el lado opuesto tenían un valor indefinido, que podía ser cero o uno según la implementación.

Es cierto que todos los programadores asumen que lo que entra es cero siempre; pero pese a todo, yo, que tiendo a ser demasiado cauto, opté por añadir siempre una máscara AND para poner a cero los bits entrantes y así evitarme sorpresas.

Sin embargo, hace unos días, mientras optimizaba unas rutinas que hacen uso de desplazamientos, decidí investigar más a fondo el tema, porque a fin de cuentas una máscara consume ciclos de reloj, así que si había alguna forma de evitarla siempre sería una mejora. Y lo que descubrí me dejó gratamente sorprendido, porque en realidad el valor de los bits que entran no depende del compilador, sino que está perfectamente definido en el estándar.

Cuando se utiliza el desplazamiento hacia la izquierda (<<), por el lado derecho siempre entran ceros. Ahí nunca hay problemas. Por otro lado, cuando se utiliza el desplazamiento hacia la derecha (>>) en una variable sin signo (por ejemplo, en un unsigned int), por la izquierda también entran siempre ceros.

Sin embargo, cuando utilizamos variables con signo (por ejemplo, short int) en un desplazamiento hacia la derecha, los bits que entren por la izquierda serán una copia del bit de mayor peso del valor original. Así, si teníamos un número negativo (su bit de mayor peso está a uno), al desplazarlo hacia la derecha seguirá siendo negativo, porque los bits entrantes serán unos; en cambio, si era un número positivo (su bit de mayor peso está a cero) los bits entrantes serán cero.

Supongo que la razón de hacerlo así es que, si se utilizan rotaciones para hacer divisiones, se conserva el signo.

Este código ilustra perfectamente lo dicho aquí:

#include <stdio.h>

void desplaza(unsigned int o) {

  signed int s1,s2;
  unsigned int u1,u2;

  s1=s2=u1=u2=o; // asignamos el mismo valor a las cuatro variables

  s1>>=4; // desplazamos cuatro veces cada una de ellas
  s2<<=4;
  u1>>=4;
  u2<<=4;

  printf("Con signo:ntdesplazamiento a la derecha   %08Xn",s1);
  printf("tdesplazamiento a la izquierda %08Xn",s2);
  printf("Sin signo:ntdesplazamiento a la derecha   %08Xn",u1);
  printf("tdesplazamiento a la izquierda %08Xnn",u2);
}

int main() {

  printf("nDesplazamiento de 4 posiciones.n");
  printf("Valor original: 0xA50000A5 (bit de mayor peso a uno).n");
  desplaza(0xA50000A5);
  printf("nValor original: 0x5A00005A (bit de mayor peso a cero).n");
  desplaza(0x5A00005A);

  return 0;
}

La salida es la siguiente, donde se aprecia claramente como el bit superior se replica en los desplazamientos a la derecha de las variables con signo, pero no en el resto de los casos:

Desplazamiento de 4 posiciones.
Valor original: 0xA50000A5 (bit de mayor peso a uno).
Con signo:
  desplazamiento a la derecha   FA50000A
  desplazamiento a la izquierda 50000A50
Sin signo:
  desplazamiento a la derecha   0A50000A
  desplazamiento a la izquierda 50000A50

Valor original: 0x5A00005A (bit de mayor peso a cero).
Con signo:
  desplazamiento a la derecha   05A00005
  desplazamiento a la izquierda A00005A0
Sin signo:
  desplazamiento a la derecha   05A00005
  desplazamiento a la izquierda A00005A0

Mejorando Transmission

Acabo de lanzar una nueva versión de FTP_BT4LXMedia. La gran novedad viene de la mano de CTransmission, un pequeño programa residente que gestiona las descargas, permitiendo limitar el número de ellas que estarán activas simultáneamente.

La razón de añadir este programa es que, debido a las limitaciones de memoria del media center, si se ponen varios ficheros a bajar de manera simultánea éste se satura, y la velocidad de descarga baja a valores ridículos. La solución consiste en bajarlos de uno en uno. Por desgracia, Transmission todavía no permite limitar el número de descargas simultáneas, por lo que he tenido que escribir este programa, que aprovecha las capacidades de control remoto para la tarea. Además, hace el mismo proceso para la subida: los activa de uno en uno hasta que alcanzan un ratio de compartición de 1.0, momento en que vuelve a repetir el ciclo hasta que todos tengan un ratio de 1.5; luego de 2.0, etc. Gracias a él, se pueden añadir todos los torrents que se deseen, y éstos se bajarán de manera ordenada y a la máxima velocidad posible.

Por supuesto, el programa es completamente configurable, y se pueden escoger otros límites mayores si se desea (en el caso del LX Media, lo óptimo es hacerlo de uno en uno, pero en otros equipos la cifra máxima puede ser mayor).

CTransmission es GPL, y se incluye el código fuente en el mismo paquete. Además, puede controlar clientes Transmission de manera remota, simplemente indicando su dirección IP y puerto.