Para empezar, el sistema intentaba hacer una reparación por su cuenta, es decir: había detectado un fallo y automáticamente entraba en modo reparación. Y no finalizaba.
Tampoco permitía acceder al menú avanzado pulsando F8, por lo que en ese instante esa opción para buscar soluciones no estaba disponible.
La única opción sería arrancar con un USB de Windows 10 y buscar la solución desde el pincho. Una de las configuraciones que hice fue indicarle al equipo desde el setup de la BIOS que me permitiera pulsar F2 o F12 para mostrar el menú de los dispositivos de arranque. Una vez tuve montada la unidad de arranque me llevé una desagradable sorpresa: quise tirar para atrás la instalación de la actualización a través la opción del punto de restauración sin ningún éxito: no se había creado ninguno. Raro, teniendo en cuenta que en teoría se crea uno justo antes de que se apliquen las actuaciones.
¿Qué más podía hacer? Solicitar hacer la auto-reparación, pero desde el USB. Tampoco hubo éxito. Si terminaba, era para reinicarse otra vez mostrando incluso mensajes de error.
¿Qué más hice? En alguno de estos arranques con el USB hice el famoso
sfc /scannow
Pero tampoco funcionó. De hecho, si no recuerdo mal, apenas empezó y ya había finalizado.
Por lo tanto, configuré el arranque de Windows para que me mostrara un menú con las distintas instalaciones para tener acceso a la posibilidad de pulsar F8 con total éxito:
bcdecit /set {bootmgr} displaybootmenu yes
Así, ya con acceso al menú principal, decidí arrancar en modo seguro, en el que se supone que se cargarían los menos controladores posibles. Y ahí estaba, arrancando normalmente hasta que me ofreció parar el checkdisk. No recuerdo si lo dejé pasar en ese instante o no. Creo que no. Pero después también daría su trabajo. El caso es que al rato ya estaba con acceso al sistema. Por lo tanto, reinicié, entré en modo normal (no usé el menú de F8) y ya estaba dentro. Esto parecía que ya sólo quedaba montar la actualización que había dado problemas y terminar de pasar el chkdsk en condiciones. Nada más lejos de la realidad.
Por un lado, se veía que el equipo de vez en cuando se bloqueaba un poco. Y por otro, que la actualización (KB3200970: lo bueno que tiene el guardar las ventanas durante meses) no se instalaba ni "para atrás". Estuve buscando y según los hallazgos resulta que esa actualización había estado dando problemas. Además, según los logs de Windows Update ya se había intentado instalar bastantes veces. Por lo que decidí pasar a la siguiente tarea: revisar el disco duro.
Como en cada arranque seguía pidiendo pasar el chequeo, quise forzarlo yo. Como no recuerdo todas las opciones las opciones que puse, puedo enumerar:
- Desde Windows arrancado
- Desde el USB
- Arrancando Windows: En el que se quedaba en el 4% durante aproximadamente una hora.
Por lo tanto, para resumir, tenemos:
- Un equipo que no ha sido capaz de instalar en varias ocasiones una actualización (¿error de la propia actualización?¿del sistema operativo?¿de hardware?).
- Un sistema operativo que cada pocos minutos, por no decidir algo menos, se bloquea durante unos segundos
- Un disco duro que el sistema operativo no es capaz de reparar los sectores de su sistema de ficheros y la herramienta del fabricante indicando errores.
Dos pasos: físico y lógico.
El físico: comprar un disco duro nuevo de, como mínimo, el tamaño original del disco. Incluso de la marca si es posible. A la vez, adquirir una carcasa para convertir el interno original a USB. Colocar cada uno de los discos en su posición: instalar el disco nuevo en el equipo y el antiguo en la carcasa. La carcasa no se enchufa todavía. Aunque se pueda hacer de la otra forma (clonar y después cambiar), me gusta hacerlo así.
Ahora, el lógico, es decir, lo que hice con software.
Arranqué un Kali y tirando del entorno gráfico que trae por defecto usé un terminal. No sabría decir si ddrescue estaba instalado. Mis primeros intentos de lanzarlo no funcionaron, pero el resultado final es que lo pude usar.
Aquí eché de menos un aparatito que me podía salvar de un posible desastre: un bloqueador de escritura. Resulta que esta operación es delicada porque si te equivocas podrías clonar un disco completamente nuevo (o no, según te estén vendiendo un disco que ya ha sido usado) sobre el importante, perdiendo todos los datos. Lo bueno de ddrescue con respecto a dd es que el primero es capaz de continuar con sectores defectuosos e intentar recuperar sus datos. Sin embargo, dd se puede llegar a parar o, a una mala, si se le indica conv=noerror,sync (lo he tenido que buscar, ¿eh?) continúa si se encontrasen errores, pero no hace el intento de ver si se pueden recuperar (o eso es lo que he entendido).
Como nunca había usado ddrescue busqué la información para ejecutarlo. Una de las cosas que he me ha gustado mucho es que no tienes que preocuparte de si pones el parámetro de origen y destino mal (En dd ¿if era la salida de la lectura o era la entrada de lo que vas a escribir? ¿Lo contrario con of? Te acuerdas durante un tiempo pero luego...):
ddrescue lista_parámetros dicoOrigen discoDestino fichero_log
Así de sencillo. Además, la otra cosa buena que tiene es que al guardar los resultados en un fichero de salida (.log, .txt, .etc) si se parase el proceso podrías continuar más adelante. Y es muy importante, porque puedes hacer distintas pasadas tal y como recomiendan hacer. Consejo que yo seguí.
ddrescue -v -R -n /dev/sdc /dev/sda /root/result_v2.log -f
Por un lado, muy arriesgado mandar la salida a una carpeta virtual. Si algo iba muy, muy mal habría que repetir toda la operación. Pero no había más conexiones USB: 1 para el USB de arranque, 2 para el disco que estábamos clonando.
- -v: verbose, para mostrar más información
- -n: para ignorar los errores y no hacer nada con ellos.
- -R: según pude leer, va de "atrás adelante". Leí que si había problemas el disco era recomendable. Y aquí (https://lists.gnu.org/archive/html/bug-ddrescue/2012-05/msg00006.html) explican más o menos cómo funciona, lo que yo no era consciente era que esta opción ralentizaría el proceso.
- -f: al detectar que podrías estar machacando información (porque se cree que hay una partición en el destino), te obliga a poner este parámetro, que significa "forzar", como indicando que estás seguro de que quieres continuar.
Poco más de 24 horas después, el proceso terminó con apenas 22 errores y unos 300 KB en errores.
ddrescue -v -R -n |
Para intentar recuperar los pocos errores que dio hice una segunda pasada:
ddrescue -v -R -r1 /dev/sdc /dev/sda /root/result_v2.log -f
- -r1: Todo sea dicho, he visto distintos formatos. El 1 lo he llegado a ver junto a la r, separado, distintos valores: -r 3. En mi caso, seguí esta indicación. En teoría es el número de intentos que tiene que hacer para recuperar ese dato.
Aunque no tengo la foto final, tardó media hora de reloj, aparecieron más errores pero el total ocupaba menos que lo que muestro en la imagen de arriba. Al final, di el disco por clonado y recuperado.
Hasta aquí, después de varios días pegándome con el disco, ya teníamos un disco completamente nuevo con el sistema operativo tal cual estaba cuando lo apagamos, con una actualización pendiente de instalar y el sistema operativo esperando a realizar un checkdisk.
Para no alargar más la historia, sólo resumir que fue coser y cantar: pude arrancar correctamente el sistema, la actualización se instaló sin dar ningún problema y el chkdsk pasó del 4% en tiempo record.
Con lo que he podido contar (seguro que alguna cosa me he dejado en el tintero como, por ejemplo, las distintas veces que creé los puntos de restauración): ¿qué habríais hecho vosotros? ¿Qué herramientas con las contáis o que sabéis hubierais usado para arreglar este equipo?