Disco duro no encontrado durante el arranque de un openSUSE virtualizado

Tiempo atrás preparé una instalación estándar de openSUSE en VirtualBox para mis pruebas de configuración. Con la idea de evitar realizar lo mismo cada vez que necesitaba de un entorno básico de pruebas decidí crear una copia de seguridad de dicha virtualización.

Pero al importar con VirtualBox la copia de seguridad he tenido problemas durante el arranque del sistema operativo, y es sobre este problema y su solución que trata este artículo.

Para crear la copia de seguridad utilicé el asistente Exportar servicio virtualizado de VirtualBox cuyo proceso finalizó correctamente, el problema surgió durante el arranque del sistema operativo luego de haberlo importado a partir de la copia de seguridad con el asistente Importar servicio virtualizado de VirtualBox, tarea que por cierto trascurrió sin problemas.

El problema lo podrán apreciar en la siguiente captura:



Identificación del problema

Por alguna extraña razón el proceso de arranque del sistema operativo fue incapaz de ubicar las particiones del sistema operativo para continuar con el arranque normal, por lo cual me puse a investigar el origen de dicho problema. Luego de indagar "des-organizadamente" por la web y de realizar múltiples pruebas con el asistente de recuperación y con un LiveCD de la propia distribución pude llegar a la conclusión (muy personal por cierto, que quede claro) que durante el proceso de importación, la herramienta VirtualBox creó el disco duro virtual con un ID totalmente distinto al de la instalación original, con lo cual las referencias que utilizaba el sistema operativo quedaron inválidas, ya que apuntaban a un dispositivo que había cambiado de nombre.

En mi caso, el ID del disco duro virtual de la instalación original en VirtualBox era ata-VBOX_HARDDISK_VB4fbf3510-08771d94 haciéndose referencia al mismo en los archivos menu.lst del grub y fstab. Sin embargo, en la instalación importada desde la copia de seguridad el ID del disco duro virtual cambió a ata-VBOX_HARDDISK_VBd2522280-a69b1bab, con lo cual las referencias de los archivos menu.lst y fstab ya no servían para nada, dando como resultado el error que ya apreciaron en la imagen superior.


Solución del problema

Los pasos para solucionar este problema fueron elaborados íntegramente por mí como resultado de la intensa investigación y la gran pérdida de tiempo que supuso encontrarla jaja, así que no esperen demasiados fundamentos elaborados que justifiquen que este es el mejor método para solucionar el inconveniente. Otra cosa que quisiera dejar en claro es que para la reparación de este problema he utilizado la herramienta de rescate que viene con el DVD de instalación de openSUSE, también puede funcionar utilizando un LiveCD, los pasos son los mismos.

Hechas las aclaraciones correspondientes comenzamos con la secuencia de pasos que permiten solucionar este problema:
  1. Lo primero que tenemos que hacer es tratar de arrancar la máquina virtual con el DVD de instalación de la distribución. Esto lo hacemos agregando el ISO del DVD en el apartado Almacenamiento de las configuraciones de la máquina virtual afectada o colocando el DVD físico en la lectora del host anfitrión y configurando ésta como origen para la lectora virtual.

  2. Luego debemos verificar que en el orden de arranque de la lectora virtual esté en primer lugar, esto se configura en el apartado Sistema de la ventana de configuraciones.

  3. Procedemos a arrancar la máquina virtual y en el cargador de arranque del DVD de instalación seleccionamos la opción Sistema de Rescate.

  4. Una vez iniciado el modo rescate nos conectamos con el usuario root:
    Rescue login: root
    Rescue:~ #

  5. Luego procedemos a montar las particiones del disco duro virtual que tienen los directorios que nos interesan: /boot y /etc. En mi caso tenía solo dos particiones en el disco duro virtual, una para la partición swap y otra para el / (root), con lo cual la instancia del asistente de rescate identificó dos unidades del dispositivo sda, la partición sda1 correspondiente a swap y la partición sda2 correspondiente a la raíz.
    Rescue:~ # ls /dev/sda*
    /dev/sda /dev/sda1 /dev/sda2
    Rescue:~ #
    Para este caso solo necesité montar la partición sda2, ya que en la misma se encuentran los directorios y archivos que se necesitan modificar.
    Rescue:~ # mount /dev/sda2 /mnt
    Como se podrá apreciar la partición sda2 fue montada en el directorio /mnt del sistema de archivos del asistente de rescate.
    OBS: En el caso de que tengan particiones específicas para el directorio /boot y / deberán montar ambas particiones para realizar los ajustes.
  6. Una vez montada la partición, editamos el archivo de configuración fstab para realizar las correcciones:
    Rescue:~ # vi /mnt/etc/fstab
    Al editarlo por primera vez su configuración fue la siguiente:
    /dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 swap                 swap       defaults              0 0
    /dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 / ext4 acl,user_xattr 1 1

    proc /proc proc defaults 0 0
    sysfs /sys sysfs noauto 0 0
    debugfs /sys/kernel/debug debugfs noauto 0 0
    usbfs /proc/bus/usb usbfs noauto 0 0
    devpts /dev/pts devpts mode=0620,gid=5 0 0
    Como se observa, los dispositivos ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 y ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 en el directorio /dev/disk/by-id son las particiones correspondientes a las unidades swap y / respectivamente, si los tratamos de buscar en el directorio /mnt/dev/disk/by-id nos daremos cuenta que ni siquiera se encuentra accesible la carpeta disk, al menos desde el asistente de rescate.

    En realidad lo que sucede es que los dispositivos ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 y ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 del directorio /dev/disk/by-id son meros enlaces a los dispositivos /dev/sda1 y /dev/sda2 respectivamente (esto lo veremos más adelante), por lo cual podemos reemplazar ambas referencias en el archivo fstab con las referencias a los dispositivos sda1 y sda2, quedando la configuración similar a lo que sigue:
    /dev/sda1            swap                 swap       defaults              0 0
    /dev/sda2 / ext4 acl,user_xattr 1 1

    proc /proc proc defaults 0 0
    sysfs /sys sysfs noauto 0 0
    debugfs /sys/kernel/debug debugfs noauto 0 0
    usbfs /proc/bus/usb usbfs noauto 0 0
    devpts /dev/pts devpts mode=0620,gid=5 0 0
    Con esto ya tenemos corregido este archivo, guardamos los cambios y volvemos al promp para continuar con la siguiente corrección.

  7. El siguiente paso consiste en realizar los mismos cambios en el archivo de configuración menu.lst del gestor de arranque grub, para ello editamos el archivo menu.lst ubicado en el directorio /mnt/boot/grub:
    Rescue:~ # vi /mnt/boot/grub/menu.lst
    La configuración que tenía en mi caso fue la siguiente:
    # Modified by YaST2. Last modification on lun abr 25 17:32:14 PYT 2011
    # THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
    # Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader


    default 0 timeout 8
    ##YaST - generic_mbr
    gfxmenu (hd0,1)/boot/message
    ##YaST - activate

    ###Don't change this comment - YaST2 identifier: Original name: linux###

    title openSUSE 11.4 - 2.6.37.1-1.2 root (hd0,1) kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 resume=/dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 splash=silent quiet showopts vga=0x317 initrd /boot/initrd-2.6.37.1-1.2-default

    ###Don't change this comment - YaST2 identifier: Original name: failsafe###
    title Failsafe -- openSUSE 11.4 - 2.6.37.1-1.2 root (hd0,1) kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/disk/by-id/ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 showopts apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x317 initrd /boot/initrd-2.6.37.1-1.2-default

    ###Don't change this comment - YaST2 identifier: Original name: floppy###
    title Disquete rootnoverify (fd0) chainloader +1
    Al igual que en el archivo fstab debemos reemplazar las referencias de los dispositivos ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1 y ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2 por los dispositivos sda1 y sda2 respectivamente, el archivo corregido quedó como se muestra a continuación:
    # Modified by YaST2. Last modification on lun abr 25 17:32:14 PYT 2011
    # THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
    # Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader


    default 0 timeout 8
    ##YaST - generic_mbr
    gfxmenu (hd0,1)/boot/message
    ##YaST - activate

    ###Don't change this comment - YaST2 identifier: Original name: linux###

    title openSUSE 11.4 - 2.6.37.1-1.2 root (hd0,1) kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/sda2 resume=/dev/sda1 splash=silent quiet showopts vga=0x317 initrd /boot/initrd-2.6.37.1-1.2-default

    ###Don't change this comment - YaST2 identifier: Original name: failsafe###
    title Failsafe -- openSUSE 11.4 - 2.6.37.1-1.2 root (hd0,1) kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/sda2 showopts apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x317 initrd /boot/initrd-2.6.37.1-1.2-default

    ###Don't change this comment - YaST2 identifier: Original name: floppy###
    title Disquete rootnoverify (fd0) chainloader +1
    Corregidos los dispositivos podemos salir del archivo guardando previamente los cambios.

  8. Por último solo resta reiniciar la máquina virtual para salir del modo rescate.
    Rescue:~ # reboot

Con estos pasos el problema debería quedar solucionado y al iniciar nuevamente la máquina virtual el sistema operativo debería arrancar con total normalidad.

Una vez iniciado el sistema operativo podremos verificar que los ID's de las particiones del disco duro virtual ya no son los mismos que los ID's de la instalación original. Esto lo podemos hacer listando el contenido del directorio /dev/disk/by-id (que ahora si ya estará disponible) y compararlos con los ID originales como se muestra a continuación:
testsrv:~ # ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root 9 Apr 29 08:18 ata-VBOX_CD-ROM_VB2-01700376 -> ../../sr0
lrwxrwxrwx 1 root root 9 Apr 29 08:18 ata-VBOX_HARDDISK_VBd2522280-a69b1bab -> ../../sda
lrwxrwxrwx 1 root root 10 Apr 29 08:18 ata-VBOX_HARDDISK_VBd2522280-a69b1bab-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 29 08:18 ata-VBOX_HARDDISK_VBd2522280-a69b1bab-part2 -> ../../sda2
lrwxrwxrwx 1 root root 9 Apr 29 08:18 scsi-SATA_VBOX_HARDDISK_VBd2522280-a69b1bab -> ../../sda
lrwxrwxrwx 1 root root 10 Apr 29 08:18 scsi-SATA_VBOX_HARDDISK_VBd2522280-a69b1bab-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 29 08:18 scsi-SATA_VBOX_HARDDISK_VBd2522280-a69b1bab-part2 -> ../../sda2
testsrv:~ #
Como se puede observar arriba, estas unidades son enlaces a los dispositivos sda, sda1 y sda2. Comparando los nombres de los dispositivos que se encontraban en los archivos menu.lst y fstab previa modificación y los nombres reales de los dispositivos del directorio /dev/disk/by-id tenemos las siguientes claras diferencias que dieron origen a todo este problema.
En menu.lst y fstab: ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part1
En /dev/disk/by-id/: ata-VBOX_HARDDISK_VBd2522280-a69b1bab-part1

En menu.lst y fstab: ata-VBOX_HARDDISK_VB4fbf3510-08771d94-part2
En /dev/disk/by-id/: ata-VBOX_HARDDISK_VBd2522280-a69b1bab-part2
En fin, esto se volvió a hacer largo, será hasta la próxima..


Datos de los programas utilizados

  • VirtualBox v4.x.x
  • openSUSE i586


Enlaces externos

Comentarios

  1. muchisimas gracias, 11 años despues ésta sigue siendo una valiosisima informacion, me daba que era problemas de los ID de los discos pero no sabia atinar con ellos bien jajaja

    ResponderEliminar
    Respuestas
    1. Buenas Anónimo, yo aquí respondiéndote luego de más de dos meses de tu comentario. La verdad no se cuantos años más estará el blog disponible, mientras que pueda y me siga sirviendo lo mantendré arriba, esperemos que a Google no se le ocurra dar de baja pronto el servicio de blogger.com, por suerte al parecer no le cuesta demasiado mantener el servicio corriendo porque o sino ya lo hubieran cerrado...

      PD: Espero no haber invocado a Google..

      Eliminar
  2. Este comentario ha sido eliminado por el autor.

    ResponderEliminar

Publicar un comentario