Clonacion de Discos

[Marchi]

Escribo este post para comentar sobre un problema que me surgio con una maquina que me dieron para arreglar.

Se trataba de una computadora con un problema en el disco, clusters dañados. Asi que se me pidio mover todo los datos a un disco nuevo y dejar la unidad vieja como soporte auxiliar.

La maquina tenia 3 particiones, una particion primaria de unos 30 Gb para Win XP y dentro de una extendida, una unidad logica para Win Vista de unos 40 Gb y otra particion para datos de unos 80 Gb. De estas particiones, todas con ntfs, solo la primera tenia sectores inutilizados.


En principio habia pensado en instalar todo desde cero y pasar documentos y otro archivos, pero despues decidi clonar directamente las particiones de un disco a otro ya que si no tendria que intalar y configurar muchas cosas.

Para esto trate de usar Clonezilla, un utilitario estilo Norton Ghost que compila varias herramientas como Partition Image, ntfsclone y partclone entre otras pero con la ventaja de ser Free Software, todo envasado en un Linux Live.
Lamentablemente no tuve en cuenta que no funcionaria con clusters dañados, asi que tuve que buscar otra cosa.

Buscando si habia alguna forma de usar Clonezilla teniendo en cuenta que habia clusters dañados encontre Clonezilla-SysRescCD, otro utilitario que trae ademas del Clonezilla y el System Rescue CD otras herramientas interesantes como Ranish Partition Manager.


Con esto pude usar el dd_rescue, para clonar el disco viejo en el nuevo tan solo con "dd_rescue -A -v -w -m 75G /dev/sda /dev/sdb". Con esto copie los primeros 75Gb (-m 75G) del disco viejo (/dev/sda) en el viejo (/dev/sdb), escribiendo 0 si el la informacion del disco viejo fuera ilegible (-A) y abortando en caso de que halla un error de escritura en el nuevo (-w).

Despues de algo mas media hora y algunos errores de lectura termino, asi que apague la maquina desconecte el disco viejo y bootee desde el nuevo, aparece el menu del inicio dual (XP/VISTA) elijo XP y comienza a cargar, aparece chkdsk para comprobar la unidad E (la de datos, la tercera en el disco con 80Gb) asi que presiono una tecla para evitarlo ya que esta particion no la copie entera a proposito, y luego aparece chkdsk para comprobar C: (particion con XP y sectores defectuosos) asi que aca si dejo que chkdsk haga su trabajo. Despues de corregir algunas pocas cosas termina y prosigue la carga de windows. Inicia windows sin problemas, reinicio y compruebo que tambien funciona VISTA.


Despues de esto apago la maquina, y con Ranish PM en el disco nuevo borro la particion de datos (si bien solo se habia copiado unos 4 o 5 Gb, la informacion de particion se guarda en el MBR), redimensiono la particion extendida para que termine donde termina la particion de VISTAy apago. Conecto el disco viejo pero booteo desde el nuevo, cargo XP perfectamente y desde el administrador de discos (o algo asi, no me acuerdo como se llama) creo una nueva particion en el disco nuevo destinada a datos, pero ahora de unos 500-600 Gb (usando el resto del disco). Paso los archivos de la particion de datos del disco viejo a la nueva particion y apago de nuevo.

Ahora desconecto el disco viejo e intento cargar con el disco nuevo solo, para mi sorpresa al intentar cargar xp me dice que falta el ntldr y al intentar cargar vista me dice que falta Windows/system32/winload.exe (o parecido no recuerdo). Asi que vuelvo a conectar el disco viejo y al intentar cargar esta vez todo va en orden.


Extrañado, trato de empezar de nuevo y volver a copiar todo el disco viejo en el nuevo, pero esta vez con algunos cambios. Para evitar alargarlo mas les cuento que termino pasando lo mismo, solo cargaba cuando ambos discos estaban enchufados, pero erroneamente no me di cuenta de esto y pensando que no sucedia borre las particiones del disco viejo, resultando que ya no podia volver a cargar ningun windows ni en los discos viejos ni nuevos. Si bien pudo haber sido un poco desesperante, por el hecho de siquiera pensar en haber perdido toda la informacion de un cliente, en realidad Con una aplicacion tan simple como Ranish PM esto se puede arreglar poniendo los valores correctos de inicio y finalizacion de cada una de las particiones eliminadas.


Por suerte recorde algo que habia leido sobre un posible error con el archivo winload.exe debido a la modificacion de un campo en el mbr usado para identificar discos, el mbr pose un valor de 32 bits en el offset 1B8 usado por systemas nt para reconocer a un disco de manera unica (creo que fue usado al principio por los nt, pero hoy en dia su uso se amplio a otros sistemas).
Ahi me puse a pensar que al copiar el disco entero se copio tambien este identificador y mientras usase solo un disco conectado no habia problema, pero al conectar los dos e intentar bootear desde uno con windows, de alguna forma se daba cuenta de que los 2 discos tenian el mismo identificador y entonces se cambiaba uno. De forma que mientras tubiera ambos discos conectados y con las particiones donde esta la carpeta boot, el ntldr y otros datos necesarios para la carga de los SO no abria problema, pero al dejar solo el disco cuyo identificador fue cambiado, no se podria cargar ninguno de los SO.

Para ver si esta idea era real o solo un razonamiento incorrecto o no aplicable, cargue con el live del System Rescue CD y habri ambos mbr y los compare en la posicion 1B8, afortunadamente los valores eran distintos, asi que modifique el valor del mbr del disco nuevo con el del disco viejo, previo guardado del mbr original, intente bootear con solo el disco nuevo y al fin pude bootear correctamente ambos SO.


Bueno despues quedo trabajo por hacer, pero esto era lo importante.
Cuando se hacen clonaciones de discos con herramientas que copian byte por byte desde el primer sector hasta el ultimo (o el que se quiera), y se estan usando sistemas windows xp o vista (en realidad supongo que puede ser para cualquier nt o basado en nt, como 2000, 2003 y otro, pero no puedo asegurarlo) hay que tener cuidado con intentar bootear uno de los sistemas con el otro disco conectado, ya que automaticamente se modificara alguno de los identificadores de disco haciendo que sea imposible la carga de un SO hubicado en este cuando el otro disco no este conectado.



La verdad que esto no podia creerlo hasta que no se me ocurrio la solucion, porque en pocas palabras sucedia que tenia un disco andando, le conectaba otro booteaba y lo desconectaba y desde ese momento no podia volver a cargar el primero. Realmente parecia de locos y por eso la empresa de Redmond se comio unas cuantas puteadas de mi persona , ahora ya sabiendo la causa del problema sepan bien que no les quitaria ninguna puteada.



Bueno, espero que hallan llegado hasta el final y no se hallan perdido o dormido con mi mala redaccion.



Saludos

[j8k6f4v9j]

Es increíble, hacen lo que sea para salirse de lo estándar y fastidiar al personal haciéndolo dependiente. Muy mal por su parte. A cualquier otro menos despabilado le hubiera ocasionado un serio problema.

Salu2

[arkechu]

La verdad que a mi se me habría pasado por alto ya que desconocía el tema de la identificación de discos.
Me saco el sombrero por la abstracción en la búsqueda de la solución y por no bajar los brazos.
Yo creo que habría copiado los archivos de un disco a otro y luego formatear el disco con clusters dañados, pero claro que después de romperme la cabeza por horas intentando clonar los discos.

[Marchi]

La verdad que tenia una bronca terrible, pero pensandolo mas frio, el valor este que se usa como identificador, creo que no es algo fuera del estandar (http://en.wikipedia.org/wiki/Master_boot_record, segun dice aca hoy en dia lo usa tambien linux para saber la ubicacion del disco del cual bootear) , pero el problema viene cuando o el bootloader o windows o no se que porqueria lo modifica a su antojo sin pedir permiso.

Me gustaria probar que pasa con linux, bsd o solaris entre otros en la misma situacion, para no ser imparcial, y tambier hacer la prueba de nuevo, por que no estoy seguro de si el problema fue xp o vista, pero para esto necesitaria algun disco sin usar o hacerlo con mis propios discos pero como por ahora estoy con poco tiempo no quiero arriesgarme a tener que pasarme todo un dia tratando de recuperar lo que se pudiera perder.


Saludos

[j8k6f4v9j]

Cada disco duro se identifica por un uuid (teniendo asociados muchos valores más). Igual pasa con las particiones, que cada una tiene un identificador único. Para linux, hay un comando, lshal, que te muestra todos estos valores una vez reconocido el hardware. Te pongo como ejemplo una partición NTFS con W2000server vista desde lshal en debian squeeze (cambiando algunos valores):

udi = '/org/freedesktop/Hal/devices/volume_uuid_E86CE2816CE249A0'
  block.device = '/dev/sda10'  (string)
  block.is_volume = true  (bool)
  block.major = 8  (0x8)  (int)
  block.minor = 10  (0xa)  (int)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_SATA_Hitachi_HTS5427080406BB2300ACGRLAJA'  (string)
  info.capabilities = {'volume', 'block'} (string list)
  info.category = 'volume'  (string)
  info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string list)
  info.parent = '/org/freedesktop/Hal/devices/storage_serial_SATA_Hitachi_HTS5425080406BB2300ACGRLJJA'  (string)
  info.product = '2003 server'  (string)
  info.udi = '/org/freedesktop/Hal/devices/volume_uuid_E86CE2816CE249A0'  (string)
  linux.hotplug_type = 3  (0x3)  (int)
  linux.sysfs_path = '/sys/block/sda/sda10'  (string)
  org.freedesktop.Hal.Device.Volume.method_argnames = {'mount_point fstype extra_options', 'extra_options', 'extra_options'} (string list)
  org.freedesktop.Hal.Device.Volume.method_execpaths = {'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject'} (string list)
  org.freedesktop.Hal.Device.Volume.method_names = {'Mount', 'Unmount', 'Eject'} (string list)
  org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'} (string list)
  volume.block_size = 512  (0x200)  (int)
  volume.fstype = 'ntfs'  (string)
  volume.fsusage = 'filesystem'  (string)
  volume.fsversion = '3.1'  (string)
  volume.ignore = false  (bool)
  volume.is_disc = false  (bool)
  volume.is_mounted = false  (bool)
  volume.is_mounted_read_only = false  (bool)
  volume.is_partition = true  (bool)
  volume.label = '2003 server'  (string)
  volume.linux.is_device_mapper = false  (bool)
  volume.mount.valid_options = {'ro', 'sync', 'dirsync', 'noatime', 'nodiratime', 'noexec', 'quiet', 'remount', 'exec', 'uid=', 'gid=', 'umask=', 'utf8'} (string list)
  volume.mount_point = ''  (string)
  volume.num_blocks = 39070017  (0x2542941)  (uint64)
  volume.partition.media_size = 160041885696  (0x25433d6000)  (uint64)
  volume.partition.number = 10  (0xa)  (int)
  volume.partition.start = 102018180096  (0x17c0c1e400)  (uint64)
  volume.size = 20003848704  (0x4a8528200)  (uint64)
  volume.unmount.valid_options = {'lazy'} (string list)
  volume.uuid = 'E86CE2816CE249A0'  (string)

A lo que me refiero con que se pasan el estándar por el forro es a que, de ser cierto lo que dices de que modifica el uuid de uno de los discos, se desestabilizan implementaciones de otras plataformas/sistemas operativos. Eso no debería ser así, de hecho yo mismo he preparado hace muy poco una solución de backups que se apoya en la identificación de un disco externo (por su uuid, evidentemente) para, al detectar en el bus del sistema su conexión, comenzar un script que se responsabilida de montar el volúmen y realizar las pertinentes copias de respaldo. En este caso, por ejemplo, y según parece por lo que comentas, se rompería el invento por culpa de vete a saber qué motivo.

Pero bueno, es cuestión de confirmarlo. Yo desde luego no me explico el motivo (legítimo) de porqué cambiar el uuid de un disco sin que lo solicite el usuario explícitamente.


Salu2!

[Marchi]

Ahora entiendo a que te referias y tenes razon. Ahora, yo no estoy diciendo que modifica el uuid de un disco, segun veo este es un valor de 64 bits, mientras que el que yo vi que se modifico es un valor de 32 bits, claro esta que puede ser que el uuid dependa del codigo de 32 bits que esta en el mbr, y en consecuencia modificar uno modifica el otro.

Segun estuve mirando, lshal no me da el codigo del que hablo.

Para verlo, "sudo hexedit /dev/disco", desplazamiento 1B8, son 4 bytes.
Seguramente lo sabras j8, pero para quienes no lo sepan, modificar esto seguido del correspondiente guardado y posiblemente se jodan de lo lindo, asi que cuidado.

En mi caso:
El mbr:

000001B0   66 BB 44 72  69 76 65 20  B1 00 80 0F  B6 00 80 01

lshal:

udi = '/org/freedesktop/Hal/devices/storage_serial_872009044506'
  block.device = '/dev/hda'  (string)
  block.is_volume = false  (bool)
  block.major = 3  (0x3)  (int)
  block.minor = 0  (0x0)  (int)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_872009044506'  (string)
  info.capabilities = {'storage', 'block'} (string list)
  info.category = 'storage'  (string)
  info.parent = '/org/freedesktop/Hal/devices/pci_10de_265_ide_0_0'  (string)
  info.product = 'QUANTUM FIREBALLlct10 10'  (string)
  info.udi = '/org/freedesktop/Hal/devices/storage_serial_872009044506'  (string)
  linux.hotplug_type = 3  (0x3)  (int)
  linux.sysfs_path = '/sys/block/hda'  (string)
  storage.automount_enabled_hint = true  (bool)
  storage.bus = 'ide'  (string)
  storage.drive_type = 'disk'  (string)
  storage.firmware_version = 'A03.0900'  (string)
  storage.hotpluggable = false  (bool)
  storage.media_check_enabled = false  (bool)
  storage.model = 'QUANTUM FIREBALLlct10 10'  (string)
  storage.no_partitions_hint = false  (bool)
  storage.originating_device = '/org/freedesktop/Hal/devices/computer'  (string)
  storage.partitioning_scheme = 'mbr'  (string)
  storage.removable = false  (bool)
  storage.removable.media_available = true  (bool)
  storage.removable.media_size = 10262568960  (0x263b26000)  (uint64)
  storage.requires_eject = false  (bool)
  storage.serial = '872009044506'  (string)
  storage.size = 10262568960  (0x263b26000)  (uint64)
  storage.vendor = ''  (string)

Saludos

[j8k6f4v9j]

claro esta que puede ser que el uuid dependa del codigo de 32 bits que esta en el mbr, y en consecuencia modificar uno modifica el otro.

Pues creo que aquí puede estar el quid del problema, sólo que a la inversa. Supongo que lo que ocurre es que Windøws utiliza en el MBR valores de 32 bits generados a partir de los uudis de las particiones de sistema (combinándolos quizá con otros elementos). En cualquier caso, debe (o debería) haber por ahí documentación al respecto.

Salu2

[hystd]

El objetivo de que sea así es debido a que se necesita de algún mecanismo de seguridad para evitar la copia de los Windows Vista de un HD a otro (recuerda que éstos ya vienen instalados por el OEM, al adquirir un equipo). Ese mecanismo se basa precisamente en eso, en obtener el id del disco en el que fue instalado, y si es distinto, no permite el arranque. Existen dos id's, uno perteneciente (o relacionado) con el número de serie asignado durante la instalación del sistema, el cual es generado aleatoriamente (creo que se genera tomando como semilla la fecha y hora de instalación), y que es posible obtener mediante la función GetVolumeInformation contenida en kernel32.dll y otro perteneciente al ID propio del fabricante, el cual se graba en el MBR, en el offset que habéis comentado (0x1B8). El primero por tanto, varía cuando se reintala el sistema, y el segundo permanece invariable. Desconozco si ese identificador se encuentra grabado en alguna ROM del disco, pero lo lógico es pensar que si.

Igual ocurre con muchos sistemas anticopias de CD's y DVD's (éstos también poseen un identificador único) y es utilizado por una inmensa cantidad de software (no sólo por el Windows). Hay aplicaciones con protección anticopia basada en comprobar el identificador generado durante la instalación, y otras basadas en la anticopia que comprueba el id único del disco. Para la primera, es posible modificar dicho identificador y problema solucionado, pero en caso de optar por realizar ingeniería inversa, bataría con invalidar dicha comprobación en la aplicación.

Para el caso del Vista, habría que "parchear" el kernel del sistema (NtosKrnl.exe) para que invalidara la rutina de comprobación y así conseguir que se puedan realizar copias del Windows de un soporte a otro sin ningún problema.

Un saludo.

[j8k6f4v9j]

hystd, según esto que dices, la comprobación no estaría en el mbr mismo, sino en la segunda fase del arranque, porque si no, para poder arrancar una copia del sistema, bastaría con arrancarla desde un gestor de mbr distinto (i.e. grub).

Salu2

[Marchi]

Ese mecanismo se basa precisamente en eso, en obtener el id del disco en el que fue instalado, y si es distinto, no permite el arranque. Existen dos id's, uno perteneciente (o relacionado) con el número de serie asignado durante la instalación del sistema, el cual es generado aleatoriamente (creo que se genera tomando como semilla la fecha y hora de instalación), y que es posible obtener mediante la función GetVolumeInformation contenida en kernel32.dll y otro perteneciente al ID propio del fabricante, el cual se graba en el MBR, en el offset que habéis comentado (0x1B8).

Precisamente cuando se intenta cargar Vista y se detecta que este valor cambio tira el error sobre la falta de o problema con Windows/system32/winload.exe , es un mecanismo para evitar la clonacion de instalaciones (cuando se hacen con herramientas que NO copian exactamente toda la estructura del disco) como bien mencionas hystd. Esto no lo considero mal, el problema es que se modifique ese valor sin permiso. El valor esta en el MBR, no en el primer sector de la particion en la se ubica vista ,ese valor tambien es usado por otros SO. Es un recursos comun para muchos de los sistemas que se puedan instalar en un mismo disco.

Es como si vos llamas a un electricista a tu casa para que te arregle un desperfecto electrico y ademas de eso sin consultarte te rompe los caños de gas, de agua y te tira las estufas.


Saludos

[hystd]

Efectivamente, quien hace la comprobación es el sistema operativo cuando carga y no la rutina del master boot, en ningún momento he dicho que no fuera así. Arrancar con un gestor de arranque distinto no significa nada... los gestores de arranque lo que varían es esa rutina, metiendo una instrucción de salto en ella hacia donde comienza la aplicación del gestor para mostrar opciones, menús, etc... y puesto que aún no se ha realizado la carga de ningún SO, el gestor se ejecutará sin problemas.

Cuando una vez iniciado el gestor, comienza la carga del SO, éste puede acceder a donde quiera (en ese instante la CPU aún está en modo supervisor), y en el caso de Vista, se ejecuta el cargador del núcleo (ntldr.exe), el cual será quien llame a los distintos módulos: NtDetect.exe, Ntoskrnl.exe, etc... y en ese momento es cuando se realiza la comprobación del id almacenado en el MBR...

Esto es muy parecido a lo que comenté en este hilo hace algún tiempo:

http://foro.hackhispano.com/showthread.php?t=30743&page=2#31

El hecho de que se modifique sin permiso es un tema delicado... no tengo el Vista instalado (y que me libren de tenerlo), y no puedo demostrar nada experimentalmente, pero por lo visto, en sus "maravillosas mejoras" incorpora un nuevo proceso de arranque, utilizando unas estructuras de datos llamadas BCD (Boot Configuration Data), y en resumidas cuentas viene a significar en principio y de forma grotesca que "el Vista necesita el MBR para el sólo"... eso si, no significa que no sea viable hacer arranques duales con otros sistemas operativos, pero no es tan trivial como antes.

Un saludo.