Lo hice y lo entendí

El blog de Vicente Navarro
29 sep

Probar en VirtualBox una memoria USB de arranque

En la entrada anterior, Arrancar BartPE desde memorias USB en FAT32, ¡y mucho más rápido!, hemos vuelto a tratar de memorias USB de arranque. Un importante inconveniente a la hora de trabajar en este tema es que las secuencias de prueba y error se hacen muy penosas, ya que cada cambio que hacemos necesita mucho tiempo para ser probado y el ciclo:

Haz el cambioReiniciaComprueba si funcionaVuelve a arrancar normal

se repite una y otra vez…

Siempre he pensado que sería muy útil poder arrancar esa memoria USB desde una herramienta de virtualización como VirtualBox o VMWare para poder hacer allí tranquilamente las pruebas. Sin embargo, aunque VWMWare permite el acceso a dispositivos USB, si no me equivoco, no permite arrancar desde ellos. El VirtualBox-OSE (la versión GPL), directamente no permite el acceso a dispositivos USB. El VirtualBox normal sí lo permite pero el arranque de un dispositivo USB no es una opción del menú de arranque de su BIOS.

Otra solución sería permitir acceso directo al disco USB /dev/sdX desde el entorno de virtualización. Como el VirtualBox lo trataría como un disco normal, no podríamos simular los problemas que a menudo tienen las BIOS y los sectores de arranque con el hecho de que el disco sea USB, pero al menos podríamos comprobar que, al menos todo parece ir bien. En VirtualBox, la forma de dar acceso a un disco físico es ésta:

VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk /dev/sda

consistente en crear un fichero vmdk enlazado a un disco físico. Sin embargo, la versión 1.5.6 de VirtualBox-OSE, la que lleva Ubuntu Hardy, no incluye este comando. En Debian Lenny, la versión de VirtualBox-OSE incluida, la 1.6.2, sí que lleva el “createrawvmdk y funciona bien. Si queremos poder tener acceso directo a discos en Ubunty Hardy, podemos descargar la versión completa (y cerrada) de VirtualBox, que además de incluir características que no lleva la OSE (VirtualBox Editions), está compilado y empaquetado para la mayoría de las distribuciones más conocidas, incluyendo los módulos del kernel necesarios. Por supuesto, no podemos hacer esto por defecto con los permisos de un usuario normal, ya que no podrá acceder a un fichero de dispositivo /dev/sdX directamente ni para hacer el createrawvmdk ni para luego arrancar el sistema dentro de VirtualBox. Tendremos que usar root o ajustar los permisos.

Pero otra opción que tenemos es la de crear una imagen de nuestra memoria USB, convertir la imagen al formato vdi de VirtualBox, y cargarla. Para crear la imagen podemos usar un sencillo dd:

dd if=/dev/sdX of=imagen_mem_usb.img

Esta imagen ya la podríamos montar con las indicaciones que vimos en Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. y las de Montar imágenes de disco vdi de VirtualBox. En concreto, la primera partición (normalmente las memorias USB sólo tendrán una partición) la podremos montar así:

mount -o loop,offset=32256 imagen_mem_usb.img /mnt/punto_montaje

Convertimos la imagen a formato vdi con:

$ vditool DD imagen_mem_usb.vdi imagen_mem_usb.img
vditool    Copyright (c) 2004-2008 innotek GmbH.

Converting VDI: from DD image file="imagen_mem_usb.img" to file="imagen_mem_usb.vdi"...
Creating fixed image with size 80000040960 Bytes...

The operation completed successfully!
Writing data...
The operation completed successfully!

Y arrancando esta imagen o accediendo a la memoria USB directamente con VirtualBox, podremos hacer las pruebas que queramos sobre la memoria USB sin tener que reiniciar una y otra vez nuestro PC. Cabe la posibilidad de que un disco que arranque bien en VirtualBox tenga problemas en un sistema real, pero es que ahí ya entran, como hemos dicho, los problemas de las BIOS y los sectores de arranque con las particularidades de las memorias USB.

Es usando estas técnicas como he conseguido las capturas que ponía en la entrada anterior:

Para escribir la imagen de vuelta a la memoria USB, seguiremos el camino inverso:

vditool COPYDD imagen_mem_usb.vdi imagen_mem_usb.img
dd if=imagen_mem_usb.img of=/dev/sdX

Epílogo

Al final de todas estas pruebas, y después de varios dd de lectura y de escritura de la memoria USB, me he encontrado con la desagradable sorpresa de que varios bloques ahora son ilegibles. Curiosamente, puedo escribir en toda la memoria pero no puedo leer de ella:

$ sudo dd if=/dev/zero of=/dev/sdc bs=4K
1953127+0 records in
1953126+0 records out
8000004096 bytes (8.0 GB) copied, 1522.37 s, 5.3 MB/s
$ sudo dd if=/dev/sdc of=/dev/null bs=4K
dd: reading `/dev/sdc': Input/output error
632476+0 records in
632476+0 records out
2590621696 bytes (2.6 GB) copied, 440.465 s, 5.9 MB/s

Nota: He usado 4 KiB en el dd porque creo que el tamaño de bloque típico de las memorias USB es 4 KiB normalmente, pero no estoy seguro de si es lo más óptimo.

$ sudo badblocks -sv /dev/sdc
Checking blocks 0 to 7812503
Checking for bad blocks (read-only test): 5724736 5724736/        7812503
5724744 5724744/        7812503
5724745 5724745/        7812503
5724746 5724746/        7812503
5724747 5724747/        7812503
5724928 5724928/        7812503
5724956 5724956/        7812503
5724957 5724957/        7812503
5724958 5724958/        7812503
5724959 5724959/        7812503
done                                
Pass completed, 10 bad blocks found.

En estos casos, se impone marcar los bloques defectuosos con dosfsck o con el scandisk de MS-DOS (si la partición es FAT/FAT32):

$ sudo dosfsck -v -t -a /dev/sdc1
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      4096 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   7795200 bytes per FAT (= 15225 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 15606784 (sector 30482)
   1948717 data clusters (7981944832 bytes)
62 sectors/track, 247 heads
         0 hidden sectors
  15620218 sectors total
Checking for bad clusters.
Cluster 628667 is unreadable.
Cluster 628668 is unreadable.

... 27 clusters más...

Cluster 628696 is unreadable.
Cluster 628697 is unreadable.
Cluster 1434912 is unreadable.
Cluster 1434913 is unreadable.

... 20 clusters más...

Cluster 1453357 is unreadable.
Cluster 1453358 is unreadable.
Reclaiming unconnected clusters.
Checking free cluster summary.
Free cluster summary wrong (1948716 vs. really 1948661)
  Auto-correcting.
Performing changes.
/dev/sdc1: 0 files, 56/1948717 clusters

y para obtener una imagen de esta memoria USB de ahora en adelante, para que el dd no intente leer dichos sectores y falle por ello, usaremos la opción conv=noerror,sync:

dd if=/dev/sdX of=imagen_mem_usb.img conv=noerror,sync

de forma que el comando ignore los errores de lectura en la entrada (noerror) y los sustituya por ceros en la salida (sync).

En cualquier caso, me parece que esta memoria no tiene remedio: cuantas más pruebas hago, más sectores defectuosos aparecen. ¡Ya veis qué caras me salen las entradas del blog que para probar todo lo que escribo me cargo las memorias USB! ;-)

:wq

Entradas relacionadas

4 Comentarios a “Probar en VirtualBox una memoria USB de arranque”

  • ReiRok dice:

    Super Coco, paso a saludar nuevamente como en el post anterior.

    Solo para comentar que esto lo vengo haciendo pero con qemu, que tiene acceso directo al disco físico.

    Y, nunca tuve un problema.

    Quizás el problema es de tu PenDrive, mis pruebas en windows con DD for windows (siempre de 1 sector o sea 512 bytes, yo prefiero leer de sectores, esto es personal), HxD (Editor Hex) con acceso a disco físico o partición, o creando un disco virtual directamente con Winimage, fueron correctas.

    Otra cosa para terminar, en la entrada anterior, se puede instalar directamente Grub4dos en el MBR (en realidad ocupa mas de 1 sector) así queda como bootloader principal sin pasar por el boot sector de DOS.
    Y de ahí en mas hacer Chainloader al loader (io.sys, ntldr, bootmgr) que quiera uno o a un BootSector por ejemplo para arrancar un Syslinux o a otra partición.
    Hay muchas combinaciones.

    Bueno, saludos nuevamente.
    ReiRok.

  • ReiRok dice:

    Veo que tarda bastante en aparecer mi anterior comentario, ¿ siempre pasa así ?
    Quería editar algo como leí hace unos días en una entrada del blog, pero era para cierto tiempo.
    Otra cosa en la entrada anterior figura que hay 5 comments pero al verlos solo hay 4, ¿ esta bien ?

    Bueno basta de preguntas, después borra todo el comment.
    Como leí por acá , te comento que vuelvas a leer esta misma entrada.
    “ya que no podrá acceder a un fichero de (((disponitivo))) /dev/sdX directamente”
    Te lo comento por lo que leí del lenguaje (se que eres muy cuidadoso con este) y por eso me atrevo a escribirte este detalle, a mi por supuesto no me molesta.
    Solamente para colaborar en este blog ya que verdaderamente es un lujo.

    Saludos, y borra esto después.

  • @ReiRok ¡Pues gracias por pasarte por aquí también! Yo antes también usaba QEmu/KQEmu, pero en unos casos me iba muy lento y en otros muy inestable, de modo que me pasé a VirtualBox.

    Y respecto a mi memoria USB, ahora ya puedo decir que está muerta del todo. Tan sólo la conecto a un PC, sea Windows o Linux, basta para colgarlo por errores de lectura hasta que la desconecto. Que descanse en paz.

    El grub4dos lo he usado muy poco, y siempre desde MS-DOS. Para instalar en el sector de arranque siempre he usado GRUB, pero ya ves que grub4dos permite hacer chainloader del ntldr, cosa que GRUB no lo permite. Gracias por tu sugerencia, lo probaré más detenidamente.

    Lo de que te tarde en aparecer el comentario, creo que es por la caché. Ya creo que la he configurado para que no vuelva a pasar.

    En la entrada anterior hay 4 comentarios y un “trackback”, que también cuenta ;-)

    Y muchas gracias por avisar por la errata, ya la he corregido, y sí, ¡me dan mucha manía!.

  • cl4551f13d dice:

    Carajo! Todos su artículos son muy buenos e interesantes, pero ya no puedo transnochar más y tengo que madrugar. Si mañana tengo unos minutos, continuo.

Tema LHYLE09, creado por Vicente Navarro