Feliz Navidad 2020

Aunque este año ha sido bastante extraño, espero que estéis bien y que en la medida de lo posible hayáis podido disfrutar de estas fiestas. 

Creo que este año no voy a poner video musical. A lo mejor para felicitar el año nuevo...

MBR2GTP: Convertir disco con MBR a GPT

 Hace mucho tiempo que tendría que haber hecho la conversión de la estructura del disco duro de mi portátil de MBR a GPT. Creo recordar que en su momento quise hacerlo pero tenía que formatearlo y no me apetecía nada. 

Así, hace no más de una semana y pico se me ocurrió buscar cómo se podía hacer y me encontré con algunas páginas que indicaban que a partir de Windows 10 v1709 existía una herramienta llamada MBR2GTP.exe que lo hacía "perfectamente" (entrecomillado porque cuando uno tiene que hacerlo no siempre es tan sencillo como cabría esperar).

Es importante el disclaimer de siempre, por si las moscas: podrías perder tus datos o el sistema. Por lo que tirar de esta herramienta es solo tu decisión y responsabilidad todo lo que pase con ellos.

La primera sorpresa fue que en la búsqueda, una de las primeras entradas era un vídeo en Youtube de Sysadmit. Ya hace mucho tiempo que le tengo en mi feed y está en el listado de blogs a los que sigo.

Normalmente pondría el paso a paso de lo que fui haciendo pero creo que en esta ocasión lo voy a hacer de otra forma. 

Esta herramienta se ejecuta desde un cmd con privilegios de administración. Y se encuentra en %system32%. La ejecución seria

MBR2GTP.EXE [/validate | /convert] /disk:0 /allowFullOS [/logs:rutaLogs]

Con estos parámetros se consigue lo siguiente, si bien algunos son muy intuitivos por su nombre:

• validate: es el modo prueba. Antes de lanzarse a ver si te dejaría como norma general hacer la conversión.
• convert: ejecutar de forma efectiva la conversión
• disk: se indica qué disco duro quieres convertir
• alloFullOS: sobre todo si es el mismo disco duro donde tienes el sistema operativo que estás ejecutando, te obligará a pasar este parámetro. De hecho, si no lo pasas, ya se encargará de recordártelo especificamente.
• logs: Parece ser que lo normal es que te guarde unos logs directamente en %windir%. Yo no fui capaz de encontrarlos y tuve que ponerle este parámetro. Ayuda bastante a debuguear. Te genera cuatro ficheros: diagerr.xml, diagwrn.xml, setupact.log y setuperr.log.

Con una validación sin problemas obtendrías algo así:

mbr2gpt.exe /validate /disk:0 /allowFullOS 

MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Pero te puedes encontrar con algún problema:

MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
Disk layout validation failed for disk 0

Este error puede venir porque tu disco duro en MBR tiene más particiones de las que realmente permite esta herramienta. Sólo funcionará si tienes como máximo 3 particiones. Si tienes una específica para datos ya irían 4: interna oculta del sistema, sistema operativo, recovery... (Ya van tres)... Y la cuarta de datos. 

Aunque el log de error donde lo redirigía no tiene todos los mensajes el que se encuentra en %windir% sí. Para este caso en concreto setuperr.log mostraria:

_datetime_, Error                        ValidateLayout: Too many MBR partitions found, no room to create EFI system partition.

_datetime_, Error                        Disk layout validation failed for disk 0

La solución para continuar con el proceso pasaría por eliminar una partición. Las dos primeras no puedes: te quedarías sin sistema operativo y no podrías arrancarlo. 

Una solución que se encuentra por internet (¡¡pero no la hagas hasta que termines de leer todo el post!!): "he eliminado la partición del recovery y me ha funcionado.". Puede ser una locura que temporalmente se podría pasar por alto... Depende de cada uno si se quiere arriesgar. Sabiendo las consecuencias... Y no se puede eliminar desde dismgmt.msc por lo que habría que utilizar diskpart desde cmd, evidentemente con privilegios de administración.

diskpart
list partition
select partition 3
delete partition override
list partition

Si ejecutas volvemos a ejecutar el validate:

MBR2GPT.EXE /validate /disk:0 /allowFullOS

MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
Cannot find OS partition(s) for disk 0

Nos da el anterior error. Acabamos de eliminar la partición del recovery ahora nos suelta este otro error.

Las opciones pasarían por:

1. Volver a crear la partición del recovery si es que se eliminó usando diskpart y poniendo el tipo de partición 0x27. Además, quedaría un paso adicional que ahora explicaré.
2. Eliminar la cuarta partición: que puede ser la de datos. Espérate. 

¿He eliminado la partición del recovery?

Llegado el caso de haber eliminado la partición del recovery, aunque se haya creado de nuevo, nos encontraremos con que los logs muestran otros mensajes de error.

_datetime_, Error                        GetOSDeviceVolume: Cannot get NT path for entry.[gle=0x000000ea]

_datetime_, Error                        FindOSPartitions: Cannot get volume name for the recovery boot entry. Error: 0x000000EA[gle=0x000000ea]

_datetime_, Error                        Cannot find OS partition(s) for disk 0[gle=0x000000ea]

Este mensaje puede despistar mucho. Pensar en que al haber recreado la partición del recovery se quitaría... Y no es así. Me encontré con la solución, pero viendo ahora todo el bloque entero del log, tiene más sentido:

_datetime_, Info                         BCD: Opening store. Flags: 0x0

_datetime_, Info                         BCD: Store path: "\??\GLOBALROOT\device\harddisk0\partition1\Boot\BCD"

_datetime_, Info                         BCD: Loaded hive at BCD00000000

_datetime_, Info                         BCD: Opening object {_ID01_}

_datetime_, Info                         FindOSPartitions: Default boot entry: {_ID02_}

_datetime_, Info                         BCD: Opening object {_ID02_}

_datetime_, Info                         VERBOSE: Device path: \Device\HarddiskVolume2

_datetime_, Info                         VERBOSE: Dos path: \\?\GLOBALROOT\Device\HarddiskVolume2

_datetime_, Info                         FindOSPartitions: Volume name for the default boot entry: \\?\Volume{_ID04_}\

_datetime_, Info                         BCD: Opening object {**_ID05_**}

_datetime_, Error                        GetOSDeviceVolume: Cannot get NT path for entry.[gle=0x000000ea]

_datetime_, Error                        FindOSPartitions: Cannot get volume name for the recovery boot entry. Error: 0x000000EA[gle=0x000000ea]

_datetime_, Error                        Cannot find OS partition(s) for disk 0[gle=0x000000ea]

El problema radica en que en la base de datos del BCD existía la partición de recuperación, que el ejemplo que pongo está con ID05. Si quieres dejar eliminada esta partición para no tener que cargarte la siguiente, o ya la has eliminado y tirarás con la siguiente, no podrás continuar hasta que no arregles los registros del bcd. La opción que seguí fue eliminar el registro. Y ya lo arreglaría (y lo haré en algún momento) más adelante.

Enumeramos los registros que tiene bcd:

bcdedit.exe /enum /v

Buscamos en el listado que nos muestra el identificador que tiene de etiqueta recoverysecuence y lo eliminamos:

bcdedit.exe /delete {__idDelRecoverySequence__}

Si volvemos a hacer la enumeración ya no lo deberíamos de ver.

Por lo tanto: en este punto, que hemos eliminado la partición de recuperación, ya no habrá acceso a la misma al arrancar: hayas creado una partición con su sistema de ficheros específico o hayas dejado su espacio sin tocar.

Línea de pegote... En algún sitio proponen ejecutar:

bcdboot c:\Windows /f bios /s c:

Pero no funcionará.

¿Elimino la cuarta partición?

Aunque estoy generalizando, este es mi caso: hice un rsync de la partición de datos contra el servidor de backups (actualicé los datos) y la eliminé. Con la diferencia de que después de eliminar la partición fue cuando descubrí el problema del BCD.

Como resumen antes de volver a lanzar MBR2GTP.exe: 

• Partición recovery y su entrada BCD eliminada.
• Partición de datos eliminada sin necesidad de tocar recovery.

¿Ejecucion final?

mbr2gpt.exe /validate /disk:0 /allowFullOS 

MBR2GPT: Attempting to validate disk 0

MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Si ya no se queja aquí, podría aplicar el parámetro convert:

mbr2gtp.exe /convert /disk:0 /allowFullOS

MBR2GPT: Attempting to convert disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Trying to shrink the OS partition
MBR2GPT: Creating the EFI system partition
MBR2GPT: Installing the new boot files
MBR2GPT: Performing the layout conversion
MBR2GPT: Migrating default boot entry
MBR2GPT: Fixing drive letter mapping
MBR2GPT: Conversion completed successfully
Call WinReReapir to repair WinRE
MBR2GPT: Failed to update ReAgent.xml, please try to  manually disable and enable WinRE.
MBR2GPT: Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!

No obstante, parece que hay casos en los que el validate sí que da un OK pero el convert da error. 

Por último hay que configurar la BIOS para que cambie el modo legacy (heredado) a seguro o UEFI.

Además, insta a ejecutar el WinReRepair (¿WinReapir? ¿Eso es una errata?) que ya lo haré en algún momento.

No quiero olvidarme de poner algunos enlaces que pueden ser importantes, por si os fuese de utilidad o para un futuro volver a mirar por si contasen más cosas de las que he puesto aquí:

• Youtube Sysadmit
• Blog Sysadmit: convertir de MBR a GPT sin perder datos.
• IT Army: vídeo1 y vídeo2.
• Microsoft oficial
• Cannot find OS partitions(s) for disk 0: otra manera de solucionarlo. Entiende bien cuál era el problema del autor: no se sabe cuántas particiones tenía. 

Rsync desde Debían liveUSB con Veracrypt

Además de seguir trabajando con el NAS, esta entrada también la voy a escribir con el móvil.

En esta ocasión estaba intentando sincronizar con rsync la carpeta de datos principal con el NAS para hacer un backup como es debido. No voy a negar que aquí también he estado dando muchos bandazos. OpenMediaVault trae por defecto rsync, pero no es sencillo encontrar un port para Windows, ya que el existente tira de CygWin. Algo sí que he encontrado, pero bueno... Cyg* no me entusiasmaba. Otra opción era SyncThing. Que tenía que instalar un dock. Y lo acabé haciendo. Además del cliente para Windows. Pero en mitad de la configuración, cuando se estaban comunicando entre sí, vi unas direcciones IP que no eran internas y cancelé esa operación. 

No sé si fue entre medias intenté tirar de un liveUSB para hacer la sincronización. Sobretodo porque también me podía pasar que al lanzarla, el antivirus decidiese eliminar cosas que no debía. Pero no había forma de montar la partición. Más adelante me dije: "tate!! VeraCrypt!!!".

Así, hoy le he vuelto a dar para tirar otra vez del liveUSB, instalar VeraCrypt y montar la partición.

Yo voy a tirar de Debían. 

Ya lo hagamos antes de arrancar el liveUSB o cuando estemos con el sistema lanzado, nos hará falta VeraCrypt. Yo he descargado varios: tanto el de con de consola como el de GUI. Este último es el que he usado.

Aunque lo he hecho más adelante, no pasa nada por hacerlo ahora. El idioma del teclado. En mi caso lo tenía en inglés y me hacía falta en español. Para esto he seguido las instrucciones de SysAdmit. ¡Muchas gracias!

#apt-get install console-data

#setxkbmap -layout 'es,es' -model pc105

Después, tendremos que instalar VeraCrypt. En mi caso, como me he descargado un instalable .deb he tirado de dpkg.

#dpkg -i veracrypt_XYZ.deb

Podría ir bien. Pero a mí me ha dado unos cuantos problemas por alguna dependencia de librerías. Lo he podido solucionar...

#apt-get update

#apt-get upgrade

;Estos dos siguientes daban error

#apt-get install libwxgtk3.0-gtk3-0v5

#apt --fix-broken install libwxgtk3.0-gtk3-0v5

; Así lo he solucionado

#apt --fix-broken install

Ahora, volvemos a lanzar dpkg:

#dpkg -i veracrypt_XYZ.deb

Y ya sí me ha funcionado la instalación. Por lo que sólo he tenido que lanzar:

#veracrypt

Lo reconozco: lo he hecho con root, y debería de haber probado con el usuario normalito o sudo.

En mi caso estoy tirando de entorno gráfico. Una vez he podido seleccionar la partición y he introducido la contraseña, se me ha montado en /media/veracrypt1. 

Hasta aquí he llegado. Sabiendo que esa es la ruta, me quedaría probar a ejecutar rsync:

$ rsync --dry-run -rahuv /media/veracrypt1 usuario@IP:/recursoCompartido/

Y si no hay problemas, la prueba de sincronización empezará. He tenido que poner la v porque no me ha mostrado nada al finalizar. Si te gusta el resultado, sólo queda volver a lanzarlo sin --dry-run.

[update]

No he podido actualizar esto hasta ahora. Este comando no es que no funcione. Pero te deja los datos en raiz, en una carpeta con el nombre /recursoCompartido/, creándola si es necesario. Sin embargo, anteponiendo rsync://, sí que te lo guardará en la ruta donde el servidor tiene marcado ese recurso compartido.:

$ rsync --dry-run -rahuv /media/veracrypt1 rsync://usuario@IP:/recursoCompartido/

[/update]

Si lo probáis, contadme qué tal os ha ido. O si tenéis más ideas al respecto, también son bienvenidas.

Buscando ficheros duplicados

 Como ya os conté hace apenas unos días estoy configurando OpenMediaVault como servidor NAS. Y después de copiar un montón de datos de los distintos discos con backups hechos a mano no me queda otra que organizar todos los datos. Ya se sabe, en casa del herrero...

Para ello estoy usando varias herramientas. La de dupeguru, que es precisamente la que os conté el otro día, puede servir pero... Realmente no hace las comparaciones por hash, que creo que es sí que es importante. Y buscando la otra que vi y tenía pendiente de probar, rmlint, me he encontrado con un post en el que muestran un listado de más herramientas con comparativas de tiempos y consumo de memoria. 

La entrada en cuestión es esta:

https://www.virkki.com/jyri/articles/index.php/duplicate-finder-performance-2018-edition/

Espero que os sea de utilidad para cuando os haga falta. 

OpenMediaVault y dupeGuru

Hace menos de una semana me instalé en una máquina OpenMediaVault, una distribución Linux para montar un NAS. 

De momento estoy intentando hacerme con el sistema. La idea es hacer backups de los datos, sobre todo de los distintos discos que tengo dispersos. Pero de momento tengo que tener cuidado porque no he podido configurar la redundancia de los discos. Ya veré si acabo contando algo sobre la configuración después de su instalación (como cualquier otro Debian). 

Uno de los módulos que tiene es la posibilidad de instalar containers en de docker. En OpenMediaVault 5 usan Portainer. La verdad, nunca había trabajado con Portainer (realmente nada de docker). Y para la instalación de los distintos stacks (¿son como las imágenes que después puedes pedir que se carguen como si fuesen máquinas virtuales?), que son realmente las aplicaciones con las que se trabajan, se puede hacer pasando la URL de un git, subiendo un fichero de texto escribiendo el contenido de ese fichero en el textarea. Sé que es un poco lío (y cuando lo lea dentro de unos meses me llevaré las manos a la cabeza sorprendiéndome de lo mal que me expreso).

Resumen: quieres instalar una aplicación de docker, escribes una ristra de parámetros con su sintaxis, y si es capaz de encontrarla con esos parámetros, la instala.

Una de las aplicaciones que se proponen para buscar ficheros repetidos es dupeguru. Es muy básica y por lo que he podido averiguar, no verifica los hashes. Ya buscaré otra que lo haga. El problema es que no hay publicada la estructura que hace falta para esta forma de instalar y para esta aplicación.

Para ver si podía instalarla del mismo modo que lo hice con una anterior que sí lo tenían publicado lo que intenté hacer es basarme en los sus parámetros y después cambiar o añadir los valores necesarios.

Este es el resultado:

---
version: "2.1"
services:
  dupeguru:
    image: jlesage/dupeguru
    container_name: dupeguru
    environment:
      - PUID=XYZ
      - PGID=ZYP
      - TZ=Europe/Madrid
    ports:
      - 5800:5800
      - 5900:5900
    volumes:
      - /srv/dev-disk-by-_______/dirConfigs/dupeguru:/config
      - /srv/dev-disk-by-_______/carpetaVirtualRaiz:/storage
      - /srv/dev-disk-by-_______/trash:/trash
    restart: unless-stopped

El PUID y el GUI se consiguen accediendo por ssh al servidor, y ejecutando

#id usuarioDeseado

Así se obtienen el id de usuario y de grupo principal.

Aunque me estoy adelantando un poco: en OpenMediaVault se trabaja con carpetas compartidas. Al final son carpetas virtuales que están asociadas a un disco duro y a una ruta dentro de ese disco duro. Realmente esa carpeta está asociada a una ruta, y es la que se corresponde con

/srv/dev-disk-by-_label_o_ID_del_disco/carpeta

Para esta aplicación, el puerto 5800 está asociado al acceso a la aplicación vía web y el 5900 está para acceder por VNC.

Así, tuve mucha suerte y después de poner estos datos (y algunos problemas como, por ejemplo, no poner en el textbox el nombre del stack y el valor de algunos parámetros (como la versión, no sirve la 3) conseguí que funcionase. 

Yyyyy... ya está. Aquí lo tenemos. 

Para cualquier duda o problema por favor, avisadme. Pero como comento, en esto de los dockers soy bastante nuevo. No obstante, se hará lo que se pueda. También, como de costumbre, las aportaciones también son muy bienvenidas. 

Arrancando UEFI en PCs HP

Pero post que escribo desde el móvil. Con los riesgos que ello conlleva.

Me ha llegado una máquina que no se iba a usar más para su propósito inicial y por sus características me dije que sería estupenda para hacerme un NAS. Ya veré si publico algo al respecto.

Este ordenador es una (mini-) torre HP. Y la verdad, al abrirla... No termina de darme todo lo que me haría falta, pero para empezar voy a darla por válida.

El problema que me he encontrado, tanto a la hora de arrancar el USB de instalación como el sistema ya instalado ha sido que la configuración del UEFI impedía iniciarlos.

Para el USB incluso tuve que probar a poner el modo no seguro (legado o legacy) sin ningún éxito. Pero si en el POST, al encender la máquina, le damos a la tecla escape (ESC) nos muestra un menú. Y en ese menú nos ofrece seleccionar con los cursores opciones como "Menú de inicio" o "Ejecutar aplicación EFI". En un principio, con mínimo una de ellas, se debería de poder arrancar el dispositivo.

Una vez instalado el sistema, me he encontrado con que tenía que seleccionar la segunda opción sí o sí. Cada vez que se apague o reinicie el sistema. Y eso es inasumible con un ordenador que no debería de tener ni teclado, pantalla o ratón.

En algunas búsquedas no se daban muchas pistas a parte de la queja (con razón) contra el fabricante de dificultar (casi imposibilitar) a los compradores la decisión de qué arrancar y qué no. (Opinión: No digo que no se pueda poner una protección, pero de ahí a casi impedirlo...). 

Las últimas que he encontrado proponen una solución... Un workaround. Se trata de hacer una copia del fichero UEFI que instala el sistema operativo en cuestión en una ruta predeterminada.

#mkdir /boot/EFI/boot/

#cp /boot/EFI/__nombreX_/grubx64.efi /boot/EFI/boot/bootx64.efi

Sólo quedaría asegurarse de que los permisos de la nueva carpeta y del fichero son los mismos. Sólo por precaución.

Y ya estaría. Al reiniciar, no debería de dar ningún problema.

Estoy viendo que algunos cambios en el arranque podrían afectar, ya que en el setup, menú configuración de arranque seguro, las dos opciones , compatibilidad heredada y arranque seguro se están quedando deshabilitadas. 

No sé. En principio, así deberías de poder arrancar sin ningún problema. En mi caso ahora voy a formatear el disco que tenía esta máquina. 

Espero que para en caso de necesidad os sea de utilidad. De todas formas, si tenéis más ideas para solucionar este problema, bienvenidas sean.

****

https://askubuntu.com/questions/554690/hp-uefi-doesnt-boot-ubuntu-automatically

https://ubuntuforums.org/showthread.php?t=2392797

Trasteando con discos duros

Una vez más, voy a escribir esta entrada con el móvil. No creo que sea muy larga. A ver qué sale.

Por cierto, y antes de empezar, como de costumbre el disclaimer típico en estos casos: cualquier intento de repetir lo que aquí se muestre puede llevar a perder los datos (o con mucha suerte, recuperarlos). Si quieres hacerlo es bajo tu riesgo y responsabilidad.

Hacía mucho tiempo que quería hacer cosas con discos duros. Realmente quería destruirlos, algo que es relativamente fácil. Los que tenía, también llevaban almacenados muchísimo tiempo. Además, dos de ellos eran pareja: exactamente iguales. Y al intentar ver qué contenían... Uno encendía pero hacía "clicks" y el otro ni se movía.

La primera idea fue cambiar las dos interfaces (en este caso, IDE). 

Y, en efecto, funcionó. Además, conseguí ver el contenido del disco con su interfaz nueva.

El siguiente paso: arreglar los clicks. 

Siempre se ha dicho que nunca enciendas el disco duro abierto. Que hay que hacerlo en una sala ¿blanca? (¿Limpia?); Vamos: una sala preparada para que no haya X partículas de polvo en Y metros cuadrados. Y eso en una casa... Buscaré información porque he visto algún vídeo donde dicen que mostrarán en otro cómo montar una caja que cumpla esa función.

En mi caso, lo voy a hacer a la aventura. No pasa nada porque pierda estos datos. Pero ya digo que de las pruebas que he hecho y las herramientas disponibles, no he conseguido nada.

Estos son los discos duros abiertos:

Posiblemente por el efecto de mi propio reflejo no se perciba muy bien. Pero... ¿Sabrías decirme qué disco tiene el problema de los clicks? ¿Izquierda o derecha? Eso es: el de la izquierda. Se puede apreciar una circunferencia en el centro que no aparece en el disco de la derecha.

La landing zone está en el interior del plato (sólo tienen uno). Además, aunque sólo tiene un cabezal (para leer por ambas partes del plato) está preparado para que a la hora de fabricar con más cilindros puedan usar la misma pieza. Debajo podrían caber más:

Aquí me encuentro con varios problemas.

Uno es averiguar qué le pasa o por qué el motor del cabezal no va bien. 

Otro, es intentar poner el cabezal del que funciona en este que no lo hace. Para eso tengo que conseguir mover todo el cabezal hacia afuera. A su vez: me hará falta poner un se parador de cabezales en ambas piezas. ¿Cómo es ese separador? Es... Como una hilera de terminaciones de las bridas. Se ponen entre medias de ambos lados del cabezal. Y después, con mucho cuidado, se tendría que desplazar hacia afuera. Y yo no tengo de eso. Además, cabe la posibilidad de que esa pieza negra con el número de serie entorpezca (o haya que desmontarla también). 

En teoría, y por lo que he visto en algún vídeo: se sujeta el centro de los platos con un destornillador y con otra herramienta y mucho cuidado (además del separador ya puesto) tira hacia afuera. 

Después operar con lo que se quisiera. Si es que los cabezales no volvieron a la landing zone que debía de estar fuera, ver si se pueden recuperar los datos. O intercambiar los platos y llevarlos a otra caja (sin descuadrar los: la posición de unos con los otros también es crucial). O al revés: quitarle todo el motor de los cabezales y ponerle otros.

Como veis, ahora mismo, no tengo herramientas no toda la experiencia para hacerlo. No obstante, si alguno la tiene y quiere compartir al respecto, bienvenido sea.