Lo hice y lo entendí

He estado unos días probando el VirtualBox que viene empaquetado en Ubuntu y mis sensaciones no podrían ser mejores:

• Es software libre, a diferencia del VMWare
• Es muchísimo más rápido que el QEMU
• Es mucho más estable que el KQEMU

Sin embargo, respecto al VMware tiene algunas desventajas como que la creación de interfaces de red no es tan sencilla, sino que requiere acudir al manual y hacer algunas operaciones en la línea de comandos. Además, el formato de sus imágenes nativas de disco, el vdi, no es tan estándar/común como el vmdk o el formato raw que puede usar QEMU y que es sólo una copia directa bit a bit de un disco duro.

Respecto a estas imágenes vdi, he estado investigando si se pueden montar directamente como dispositivo loop. Para montar imágenes de VMware podemos usar el VMware DiskMount, una utilidad que incluye el comando vmware-mount. Para montar imágenes raw de QEMU podemos seguir el procedimiento que vimos en: Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. ¿Se puede hacer algo parecido con las imágenes vdi?

Pues sí que es posible hacer operaciones similares gracias a la utilidad de VirtualBox vditool:

$ vditool
vditool    Copyright (c) 2004-2008 innotek GmbH.

Usage:   vditool <Command> [Params]
Commands and params:
    NEW Filename Mbytes          - create new image;
    DD  Filename DDFilename      - create new image from DD format image;
    CONVERT Filename             - convert VDI image from old format;
    DUMP Filename                - debug dump;
    RESETGEO Filename            - reset geometry information;
    COPY FromImage ToImage       - make image copy;
    COPYDD FromImage DDFilename  - make a DD copy of the image;
    SHRINK Filename              - optimize (reduce) VDI image size.

Sigue leyendo »

Muchos de nosotros que nos dedicamos con cierta frecuencia a borrar particiones de aquí, crear por allá y ampliar por más allá, nos hemos encontrado alguna vez en el fatídico momento en el que te das cuenta que te has cargado esa partición repleta de ficheros que tanta falta te hacen. ¿Qué podemos hacer en esos casos? ¿Es reversible?

Como ya vimos en Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco., las particiones son apenas 64 bytes en el primer sector (512 bytes) del disco duro, el que llamamos MBR (Master Boot Record). Bueno, para ser exactos, en el MBR sólo se pueden guardar las 4 particiones (apenas 16 bytes para cada partición) primarias que podemos tener en el sistema de particiones de los PC, o 3 primarias más 1 extendida que puede almacenar un número indefinido de particiones lógicas en el EBR (Extended Boot Record).

Pues bien, un cambio que podamos hacer en esa tabla de particiones por ejemplo con el fdisk de Linux en principio sólo nos estará modificando la información del MBR y/o del EBR, pero en principio no la del sitio donde está la partición, a menos que el programa de gestión de particiones haga cosas más agresivas, algo que suele hacer, por ejemplo, el administrador de discos de windows. Además, si el gestor de particiones que usemos también tiene la capacidad de formatear particiones recién creadas, y es eso lo que seleccionamos, también es altamente probable que perdamos irremediablemente nuestros datos.

Me acuerdo de una vez, hace muchos años, que me cargué la tabla de particiones, ya no recuerdo cómo. Como en aquella ocasión no conocía ninguna herramienta de recuperación de particiones, me tocó armarme de paciencia, recordar de cuánto tamaño era más o menos cada partición e ir probando durante varias horas a crear particiones con el fdisk de Linux empezando un poco más aquí y empezando un poco más allá hasta que conseguí dar con un conjunto de particiones que se montaban sin errores y conseguí no perder mis datos. Hice una recuperación de particiones manual. No fui difícil pero sí muy pesado.

Más recientemente también me ha pasado alguna vez tocar la partición que no era pero, esta vez sí, ya conocía el genial gpart y pude recuperarlas sin apenas despeinarme. Aunque el nombre sea muy parecido, no debemos confundir el gpart (Guess PC-type hard disk partitions), una herramienta de recuperación de particiones, con el GParted (Gnome Partition Editor), un gestor de particiones que nos permite crearlas, eliminarlas, moverlas, copiarlas e incluso cambiarles el tamaño, llegando a igualar y superar al antiguo rey en este campo: el famoso Partition Magic.

Sigue leyendo »

Mi ordenador principal, que acaba de cumplir 4 años, lleva una placa Asus A8N-SLI Deluxe (socket 939, chipset NForce4 SLI), un AMD Athlon64 X2 4600+ (era 3500+ y lo actualicé), una GForce 6600 de 256 MiB y 2 GiB de RAM Kingston DDR400 PC3200 CL3. Es el mismo ordenador con dos discos en RAID 0 al que le instalé Ubuntu Hardy Heron en Abril.

Pues bien, la semana pasada le compré otros dos módulos Kingston de 1 GiB exactamente iguales que los originales para ampliar la memoria a un total de 4 GiB. La memoria es de una marca y modelo oficialmente soportados por esta placa base.

Yo ya sabía que algo que en teoría debería de ser pinchar & listo (plug & play) a menudo causa problemas, ya que, ¿cuántas veces no nos hemos encontrado con memorias de las que la placa sólo reconocía la mitad? ¿o que colgaban el ordenador a la primera de cambio? ¿o que nos obligaba a bajar la velocidad del bus o los parámetros de memoria en los parámetros de la BIOS? En este caso, no ha sido menos, ya que la dichosa ampliación de memoria me ha tenido un buen número de horas en vilo de saber si algún día podría usar esos 4 GiB de RAM en mi sistema.

Tras pinchar la memoria me encontré la primera cosa extraña: La BIOS había bajado la velocidad de la memoria de 400 MHz a 333 MHz. La verdad es que algo así ya me lo esperaba, ya que precisamente uno de las preguntas de las FAQ de la A8N-SLI es, precisamente:

Why does the memory run at 333MHz if I use four DDR400 512MB/256MB memory modules on A8N-SLI?

To be more compatible and stable with some memory modules, the default clock will be at 333MHz if four DDR400 memory modules are plugged on the A8N-SLI. But you still can set at 400MHz manually in the Bios to gain better performance. Moreover, in order to get best performance and compatibility, please choose those memory modules which are verified by us. You can get the QVL from the link below:

http://www.asus.com/products.aspx?l1=3&l2=15&l3=148&model=375&modelmenu=1

Así que entré en la BIOS, puse la configuración de la memoria en Manual, seleccioné la velocidad de 400 MHz y… el ordenador se colgaba instantes después del comienzo del arranque de cualquier sistema operativo. Y es que al poner la configuración manual de la memoria, los otros parámetros de la memoria como CAS# latency, RAS# to CAS# delay, Min RAS# active time o Row Precharge Time dejaban de configurarse automáticamente, así que tuve que volver a poner la memoria en Auto / 333 MHz y entrar en Linux para ver los parámetros de los DIMMs usando el decode-dimm.pl.

Sigue leyendo »