Preparación en la máquina virtual del sistema a generar con Draklive

• QEMU
• Instalación
• Repositorios
• Kernel
• Puliendo los detalles

A la hora de crear un sistema live a partir de un sistema ya instalado existen varias opciones: puede usarse un sistema instalado en otra partición, un sistema instalado en una máquina virtual... Incluso, posiblemente, con ciertos ajustes podría crearse a partir del propio sistema en que se ejecutase Draklive.

No obstante, la opción más sencilla es utilizar un sistema instalado en una máquina virtual. Hay que tener en cuenta que el sistema live generado contendrá todo lo que contenga el sistema de origen, por lo que lo mejor es una instalación específica para este propósito. De este modo, podemos asegurarnos una instalación limpia y ajustada a nuestras necesidades sin tener que "estropear" para ello un sistema real.

QEMU

Si se va a optar por usar un sistema instalado en una máquina virtual, lo primero es elegir qué máquina virtual utilizar. Las opciones que yo conozco y que están disponibles en Mandriva son VMWare, VirtualBox y QEMU.

De principio, VMWare para mí está descartada: es software privativo y hay alternativas libres (VirtualBox y QEMU) perfectamente capaces, así que VMWare no me interesa en absoluto (sí, tengo una chapita que pone "Talibán", y estoy orgulloso de ello :P ).

De entre los dos candidatos restantes, me quedo con QEMU, ya que VirtualBox también está descartado (sí, me estoy refiriendo a su versión libre). El problema que tiene VirtualBox para generar un sistema live a partir del instalado en ella es que el disco duro virtual, al menos actualmente y que yo sepa (Mandriva 2009.0), no puede montarse. O puede que sí según Copying from a VirtualBox drive on Linux, pero parece algo complejo.

Expliquemos un poco más esto. La máquina virtual debe "crear la ilusión" de que existen una serie de componentes hardware (procesador, tarjeta gráfica, memoria RAM, disco duro...). Para la mayor parte de éstos, la máquina virtual simplemente adapta el hardware real existente en el ordenador en que se ejecuta: la máquina virtual está formada por el mismo procesador, una cantidad limitada de toda la RAM disponible, una tarjeta gráfica virtual sencilla que abstrae a la tarjeta gráfica real...

En el caso del disco duro, la máquina virtual no tiene a su disposición todo el disco duro. En cambio, trabaja con un único archivo en el disco duro real, llamado archivo de imagen. Dicho archivo representará al disco duro virtual, de forma que éste sólo podrá tener tanta capacidad como se haya reservado para el archivo de imagen.

Existen diversas maneras de organizar la información en el archivo de imagen, cada una con sus ventajas e inconvenientes. En el caso de QEMU, los datos pueden guardarse en el archivo "a pelo" (raw), o bien de forma más sofisticada con el formato qcow/qcow2 (entre otros).

En el modo raw cada bit del disco duro virtual es un bit del archivo de imagen. Es decir, es una imagen exacta del disco duro virtual, lo que implica que incluso el espacio vacío en el disco duro virtual estará representado bit a bit en el archivo de imagen y, por tanto, ocupará espacio. Por ejemplo, si un disco duro virtual es de tamaño 4 GB pero sólo hay 200 MB con datos, el archivo de imagen ocupará 4 GB igualmente.

El formato qcow es más sofisticado, y un archivo de imagen en ese formato únicamente ocupa tanto como datos haya ocupados en el disco duro virtual. Por ejemplo, si un disco duro virtual es de tamaño 4 GB pero sólo hay 200 MB con datos, el archivo de imagen ocupará 200 MB únicamente.

Parece obvio que la mejor opción sería utilizar el formato qcow. Sin embargo, hay un problema: al igual que las imágenes usadas por VirtualBox, las imágenes en formato qcow tampoco pueden montarse. Se está desarrollando una forma de poder montarlas, pero aún no es funcional. Así que si queremos montar una imagen, ésta deberá estar en formato raw.

Pero, ¿para qué hay que montar las imágenes? Pues para que Draklive pueda acceder a los datos que contienen. Dado que los archivos de imagen contienen los mismos datos que un disco duro, en la práctica es como si estuviésemos montando un disco duro real y el sistema que contiene. Eso sí, aunque hasta ahora se habló de montar las imágenes, al igual que con los discos duros reales, lo que montaremos serán las particiones de las imágenes (dado que la imagen contiene la misma información que un disco duro real, también contiene particiones).

Así pues, la máquina virtual que utilizo es QEMU (aunque utilizar una u otra es indiferente, siempre y cuando puedan montarse los archivos de imagen que utiliza para el disco duro). QEMU está disponible en el repositorio main, en los paquetes qemu y dkms-kqemu (éste para el módulo de aceleración, harto recomendado). Para más información sobre cómo usar QEMU y trabajar con las imágenes, puede consultarse Manual: Usando QEMU. Y si preferimos configurar las opciones con las que arrancar la máquina virtual de forma gráfica, en el repositorio contrib también está el paquete qemu-launcher.

El tamaño del archivo de imagen que utilicemos dependerá de la cantidad de paquetes que tengamos pensado instalar, y éstos a su vez del tamaño que ocupará el sistema live comprimido en el medio (CD, DVD, USB) donde se grabará. Como ejemplo, un sistema que instalado ocupa 2,4 GB al comprimirlo pasará a ocupar en torno a 800 MB, y un sistema que instalado ocupa 3,5 GB, al comprimirlo pasará a ocupar en torno a 1,2 GB. Es decir, la compresión conseguida es aproximadamente un tercio del tamaño original (aunque, igual que comprimiendo cualquier cosa, dependiendo de qué (no cuánto) tengamos instalado esta proporción puede ser mayor o menor).

Un buen tamaño con el que empezar son 4 GB (3,5 GB para el sistema y 500 MB para swap), que siempre podemos ampliar si se nos queda pequeño. Para esto último, lo primero es ampliar el tamaño del archivo de imagen:

dd if=/dev/zero of=imagen.img seek=N obs=1MB count=0

donde imagen.img es el nombre del archivo de imagen, y N el tamaño en megas de la nueva imagen. Si se desea especificar el tamaño en gigas, debe cambiarse obs=1MB por obs=1GB.

Una vez que nuestro disco duro virtual tiene más tamaño, simplemente arrancamos la máquina virtual usando el CD de arranque de GParted, redimensionamos la partición extendida para que ocupe el espacio libre, movemos la partición swap, redimensionamos de nuevo la partición extendida para que el espacio libre pase al principio, redimensionamos la partición de / para que ocupe el espacio libre y listo. Por qué hay sólo una partición de / y una de swap (y no hay partición para /home, por ejemplo) puede verse en el siguiente apartado.

Instalación

La instalación de Mandriva en la máquina virtual puede realizarse de la forma que prefiramos (desde DVD, desde LiveCD, por red...) y con cualquiera de los sabores de Mandriva (Free, Powerpack, One...). Podríamos incluso (haciendo los ajustes necesarios) copiar un sistema con Mandriva dentro del disco duro de la máquina virtual. La cuestión es tener una Mandriva arrancable mediante QEMU. Cómo conseguirlo es lo de menos, ya que no afectará al proceso posterior.

Una buena opción es realizar la instalación mediante Mandriva One. ¿El motivo? Principalmente, dado que Mandriva One es un LiveCD, ya lleva una selección de paquetes bastante cuidada de forma que la mayor parte de las necesidades estén cubiertas utilizando para ello un espacio reducido (ya que tiene que entrar en un CD). Por ello es una buena base a partir de la cuál personalizar el sistema para usarlo en modo live.

Además se utilizará la versión de 32 bits, lo que permitirá utilizar el sistema live en sistemas de 32 bits puros así como en arquitectura de 64 bits compatible con 32 bits (como los AMD de 64 bits).

Aunque como se dijo el realizar la instalación de un modo u otro no tendrá repercusión en posteriores etapas, en alguno de los siguientes apartados sobre la preparación del sistema se comentarán puntualmente casos específicos relacionados con Mandriva One. No obstante, en líneas generales todo lo que se comentará a continuación es aplicable independientemente de cómo fuese instalado el sistema.

A la hora de realizar la instalación, únicamente se hará una partición raíz y otra para swap. En una instalación real generalmente se realizarían más particiones (por ejemplo, para /home o /usr/local), pero en este caso, para el uso que se le dará, con una partición raíz es suficiente.

Cabe destacar que a la hora de generar el sistema live, las particiones existentes en la máquina virtual son irrelevantes. Es decir, si tuviésemos una partición para / y otra para /home, eso no quiere decir que, por ejemplo en el lápiz USB, vayamos a tener una partición para / y otra para /home.

Las particiones en la máquina virtual únicamente se tendrán en cuenta cuando haya que montarlas en un directorio del disco duro real para formar la jerarquía de directorios a partir de la cuál generar el sistema live. Con todo esto, puede verse que hacer más o menos particiones en la máquina virtual al final únicamente afectará a cuántas particiones habrá que montar para generar el sistema live.

Repositorios

Una vez instalado el sistema, lo siguiente que hay que hacer, como si de una instalación normal se tratase, es configurar los repositorios y hacer las actualizaciones de paquetes pertinentes.

La forma más conveniente para esto sería usar repositorios en FTP/HTTP, o en su defecto en CD/DVD. También pueden usarse repositorios locales (que, como es lógico, deberán estar en el disco duro de la máquina virtual, no en el disco duro real), aunque si se opta por esta opción deberán eliminarse antes de generar el sistema live, o éste también contendría dicho repositorio local (lo que posiblemente ocuparía más espacio del disponible en el medio en que se grabase el sistema live).

En versiones de Mandriva anteriores a la 2008.1 hay que decidir entre usar los hdlist normales o los synthesis. Cada cuál sabrá qué prima más: que ocupen poco espacio (synthesis) o que contengan toda la información (hdlist). La diferencia de tamaño total entre usar synthesis o hdlist con las ramas release, updates y backports de main y contrib son alrededor de 100 megas (es lo que tiene que haya tantos paquetes en los repositorios :) ).

No obstante, como caso general, para un sistema live es más aconsejable usar los synthesis, ya que se supone que dejamos el sistema base listo para nuestras necesidades cuando lo generamos, y la instalación de nuevos paquetes en dicho sistema live será algo poco común. Y eso en un LiveUSB. En el caso de los LiveCDs, la instalación de nuevos paquetes será algo anecdótico, ya que al ser un LiveCD cualquier cambio realizado en el sistema se perderá al apagarlo, y generalmente no tendrá mucho sentido instalar nuevos paquetes.

Otra opción por la que se puede optar es utilizar los hdlist mientras se estén haciendo los preparativos, y cuando esté todo listo, eliminar los hdlist y sustituirlos por synthesis antes de generar el sistema.

Ahora bien, a partir de Mandriva 2008.1 incluida se prescindió de los hdlist, utilizándose únicamente los synthesis complementados con la información extendida de los paquetes obtenida al vuelo desde los repositorios cuando era necesaria. Así pues, ya no es del todo necesario obtener esa información antes de crear el sistema live, siempre y cuando éste se vaya a ejecutar en un ordenador que disponga de Internet, claro está.

Kernel

Esta sección es aplicable a Mandriva 2008.1 y anteriores. A partir de Mandriva 2009, se unificaron el kernel desktop y laptop en desktop, y desktop586 es capaz de soportar hasta 4 Gb de RAM, por lo que las consideraciones aquí expuestas ya no son necesarias si simplemente se utiliza desktop586.

Al menos, las referidas puramente al kernel. También a partir de Mandriva 2009.0, el instalador de One ofrece eliminar software innecesario, lo que incluye módulos del kernel que no se utilicen en el sistema. Así pues, aunque las disquisiciones sobre el kernel son irrelevantes, los comentarios sobre los módulos sí son relevantes, al menos si se utilizó dicha limpieza automatizada, ya que ésta podría haber eliminado módulos que en el sistema de la máquina virtual no fuesen necesarios, pero sí lo fueran en las máquinas en que se ejecutará el sistema live.

Al realizar la instalación de Mandriva One en una máquina virtual con poca RAM, se instala el kernel desktop586 y los paquetes con drivers propietarios (algún día podremos prescindir de ellos, algún día...) para ese kernel. El instalar los drivers propietarios concretos para un kernel permite ahorrar espacio en disco, ya que no necesita las fuentes del kernel para compilarlos. Ahora bien, tiene la desventaja de que si cambiamos el kernel (el tipo, no la versión), necesitaremos instalar los drivers correspondientes manualmente. No obstante en un sistema live eso únicamente sucederá mientras se prepara, por lo que no es problema.

El uso del kernel desktop586 puede no ser del todo apropiado dependiendo de en qué ordenadores se vaya a utilizar. Los diferentes kernels y sus diferencias pueden verse en el wiki de Mandriva (en inglés): Mandriva Kernels.

Aunque para un sistema normal es recomendable instalar los paquetes latest del kernel y los módulos, en el caso de un sistema live es preferible instalar la última versión disponible y nada más. El motivo es que, en el caso de un LiveCD, los paquetes no se actualizarán nunca, y en el caso del LiveUSB, aunque el kernel podría actualizarse, esto a su vez podría causar problemas en el arranque al estar preparado para otra versión.

Supongamos que el kernel más apropiado para nuestros propósitos es distinto al instalado. En ese caso, instalaríamos la última versión (pero no el paquete latest) del kernel apropiado junto a los paquetes de drivers compilados para dicho kernel que necesitásemos y reiniciaríamos la máquina virtual para comprobar que no hay ningún problema al usar éste (ya que si el instalador puso otro, sus motivos tendría ;) ). Los paquetes de drivers para un kernel concreto son de la forma nombreDriver-kernel-versionKernel-tipoKernel.

Una vez que se confirma que todo funciona como debe, se desinstala tanto el kernel previo como todos los paquetes de drivers concretos para ese kernel. Desinstalando el kernel, los paquetes de los drivers para ese kernel se van por dependencias.

Otra opción para instalar los drivers sería utilizar los paquetes DKMS. Tienen la ventaja de que se compilan cuando se arranca por primera vez con un nuevo kernel, pero el problema que presentan es que ocupan más espacio ya que necesitan herramientas de compilación y el código fuente del kernel (aunque este problema ahora es menor con la introducción de los paquetes kernel-tipoKernel-devel, preparados especificamente para compilación de módulos y mucho más ligeros frente al kernel-source normal).

En el caso de sistemas live, y dado que no se cambiará de kernel una vez creado el sistema live, es preferible usar los paquetes compilados específicamente para un tipo y versión del kernel, y usar los DKMS únicamente cuando lo anterior no es posible por algún motivo.

Puliendo los detalles

Si la instalación se realizó utilizando Mandriva One, dicha instalación deja algunos directorios en el "disco duro" (el de la máquina virtual) que no son necesarios: /live (y subdirectorios), /mnt/disk y /mnt/install, que podemos borrar sin miedo.

Además, Mandriva One es multilenguaje, lo que quiere decir que el sistema instalado está disponible en varios idiomas. Pero, lógicamente, cuantos más idiomas están disponibles, más espacio está ocupado. Por ejemplo, si en Mandriva 2008.1 se eliminan los paquetes de localización de idiomas distintos a español e inglés (de inglés sólo hay localización de diccionarios, de español además localización de interfaces) se consigue recuperar 400 MB.

Como ya se comentó, a partir de Mandriva 2009.0, la instalación de One ofrece eliminar software innecesario, lo que incluye paquetes de idiomas. Esto se puede hacer manualmente como se expone a continuación, y así será necesario hacer para versiones anteriores a la 2009.0.

Los paquetes de localización son, entre otros, paquetes llamados locales-XX, donde XX es el código de idioma (es para español, fr para francés, etc). En el caso de KDE, dichos paquetes son de la forma kde-i18n-XX. En el caso de los diccionarios, los paquetes son aspell-XX, myspell-hyph-XX, myspell-XX_YY y myspell-thes-XX_YY (donde YY es un código de país, como ES para España o MX para México). Hasta donde yo sé, GNOME y otros entornos no tienen paquetes de localización independientes, sino que las traducciones de las aplicaciones van incluidas en los mismos paquetes de éstas.

Para eliminar el idioma XX lo más sencillo es eliminar el paquete locales-XX, ya que al eliminar dicho paquete se eliminan a su vez, por dependencias, todos los demás paquetes del idioma XX.

Para que Draklive pueda generar el sistema live, es necesario instalar el paquete busybox. Así que hala, a instalar se ha dicho (aunque posiblemente ya esté instalado).

Y llegados aquí, sólo queda preparar el sistema al gusto de cada uno, instalando y desinstalando los paquetes oportunos, cambiando configuraciones, etc, etc. Tal y como quede el sistema será a partir de lo que se genere el sistema live, por lo que es recomendable dejarlo lo más afinado posible. Por ejemplo, es preferible instalar todo lo necesario ahora en lugar de instalarlo en el sistema live (si estamos haciendo un LiveUSB, en un LiveCD ya de primeras ni se podría hacer eso), ya que lo que se instale ahora irá comprimido en el medio usado, mientras que lo que se instale más adelante irá "al natural" (ver explicación sobre SquashFS y UnionFS en el apartado sobre cómo hace Draklive su magia si no se sabe de qué estoy hablando. Aunque si no se sabe de qué estoy hablando, o yo me expliqué muy mal antes, o tú no deberías estar leyendo esto sin haber pasado por la teoría ;) ).

Los cambios en la configuración para afinar el sistema hacia su uso como sistema live pueden verse en los archivos copiados en el paso post-install por Draklive. Quizás los más evidentes sean desactivar draksnapshot y MandrivaUpdate (éste en LiveCDs, en LiveUSBs su uso podría ser aceptable hasta cierto punto).

Finalmente, en Mandriva 2008.1 y anteriores es necesario aplicar manualmente un parche para que una vez que hayamos generado nuestro sistema live éste se apague correctamente. A partir de Mandriva 2008.1 el parche ya no está en el repositorio, por lo que parece que ya no es necesario.

Así pues, si es necesario, instalamos el paquete patch, vamos a la interfaz web del SVN de Mandriva, y descargamos halt-live.patch. Luego, como root, aplicamos el parche (todo esto en la máquina virtual);

patch -d / -p0 < halt-live.patch

En el parche indica que será parcheado "etc/init.d/halt". Así que -d / hace que patch se ponga en el directorio raíz, -p0 hace que ignore el
elemento 0 de la ruta (nunca tuve claro cómo funcionaba... pero sé que hace falta :P ), y < halt-live.patch lee el archivo y se lo pasa a patch (que por defecto lee en la salida estándar).

En el caso de los LiveCD, además, puede sustituirse /sbin/halt.local con los contenidos de halt.local.cdrom para que el sistema espere a la expulsión del CD antes de apagarse.