Bien, como decimos en mi tierra, ’si no es buey, es vaca…’. Así que primero he probado a restaurar la HPA en el disco de 128GB usando el valor de seek que yo creía correcto (7674529), pero no se restaura el Vista.

Decido usar entonces para el valor de seek el que se calcula con la fórmula que indicas en XDA-develloppers (7674880), con idéntico resultado… No es posible recuperar tampoco el Vista.

Sin embargo, a base de repetir los procesos por si en algo me había equivocado, me fijo que en ambos casos, el resultado de ‘dd’ muestra al inicio un mensaje de aviso que dice:

‘dd: writting ‘/dev/hda1′: No space left on device’

lo que me lleva a concluir que, independientemente del valor que usé para ’seek’, el problema está en el ‘tamaño_real_en_bytes_del_nuevo_disco’, ya que entiendo por el error mostrado que estoy intentando escribir la imagen ‘más allá’ del final del disco. De hecho en ambos casos, el nº de bytes copiados con ‘dd’ es inferior al que obtuve al crear la imagen de la HPA.

Concluyo que el valor en bytes que he usado para la capacidad total del disco es mayor de la que realmente tiene la unidad SSD. Según el fabricante, son 128GB. La hoja de características no menciona nada más al respecto, así que les pedí información acerca de si eran 128 GibiBytes o 128 GigaBytes… curiosamente me envían dos respuestas: en la primera me dicen que son GibiBytes, y en la segunda que me olvide de lo anterior, que son GigaBytes… en fin, si ni el fabricante lo tiene claro, menos lo tengo yo!.

Para salir de dudas, uso el ‘dmesg’ desde Linux, e identifica el disco SDD como:

hda: KingSpec KSD-ZF18.1-128MJ, ATA DISK drive
ide0 at 0×1f0-0×1f7,0×3f6 on irq 14
:
:
Probing IDE interface ide1…
hda: max request size : 512KiB
hda: 251887616 sectors (128966 MB), CHS=16383/255/63, UDMA(33)

O sea, que si considero que el tamaño real es el nº de sectores por 512 bytes/sector, obtengo el valor 128966459392 bytes que es el que usé en mis cálculos (y que además convertido a verdaderos bytes, da la capacidad de 120.1GB que indica el Linux para el disco).

Decido repetir el proceso de restauración de la HPA, pero esta vez considerando que el tamaño del disco es de 128 * 1000 * 1000 * 1000 = 128000000000 bytes. Y esta vez sí que no hay errores al escribir la HPA al final del disco (lo he probado con los dos valores de seek ‘posibles’). Pero ni en uno ni en otro caso consigo que el Vista se restaure: siempre da el mensaje de que no hay disco de arranque o algo así.

En resumen, un verdadero lío de cifras y la Shift sin Vista hasta que me aclare o me aclaren las cosas. O eso o bien no es posible usar la HPA restaurada en un disco de diferente tamaño que el original.

Un saludo.

Desde ya agradecer esta fabulosa ‘guía para burros’ que me ha animado a cambiarle el disco duro original de 40GB a la Shift por otro SSD de 128 GB. La copia de la imagen de la HPA la he realizado sin problemas, y como resultado del comando ‘dd’, he obtenido estos datos:

196959+0 records in
196959+0 records out
3226976256 bytes (3.2 GB) copied, 534.1 s, 6.0 MB/s

Bien, ahora me planteo recuperar la HPA en el disco de 128GB, por lo que entiendo que la fórmula que me permite calcular el valor de seek es ésta:

seek = (total_number_of_bytes_in_the_HDD – total_bytes_copiados ) / 16384

es decir, seek = (128966459392 – 3226976256) / 16384 = 7674529

siendo 128966459392 el total de bytes del disco SDD de 128GB y 3226976256 el nº efectivo de bytes de mi copia de la HPA. La duda me surge después de leer en XDA-developpers que indicas que el valor a restar debería ser de 3221225472.

Como no lo tengo muy claro, prefiero que, si puedes, me des una orientación al respecto.

Muchas gracias por adelantado.

P.D.: Ojalá hubiera visto esta página antes, está genial.

Saludos