Cuidado con los discos clonado

He tenido un "pequeño" accidente que he tardado en entender. El problema nació de mi decisión de eliminar la grabadora del ordenador, que ya no uso para nada. Eso supone disponer de un SATA libre. Como siempre, estamos escasos de espacio, y decidí recuperar uno de los discos retirados que tengo por ahí. Empecé por uno de 2,5TB, pero tenía algún sector erróneo, así que recuperé el más "moderno" de los disponibles, un Caviar Black de 2TB y fabricado en 2013. Lo incorporo, veo que está en ext4, así que decido no borrarlo y simplemente leo el UUID con blkid y lo incorporo al /etc/fstab

UUID=nume-rito-en-cuestion /mantener2     ext4    defaults        1 2

y reinicio.

En su interior había un directorio home, ya que este era mi antiguo home —véase aquí para ver el cambio de un HD Black Caviar a un SSD— y decido borrarlo... DESASTRE, por que borra todo ese disco y mi /home activo entero, es decir, todo mi trabajo. A otros les hubiera dado un ataque, pero para mi no es nada nuevo, porque me pasa de vez en cuando (esas manos quietas, muchacho!), así que sacamos el disco problema, tiramos de copia de seguridad para recuperar la información básica, instalamos todo de nuevo, porque mi copia de seguridad no guarda las configuraciones, y restaurado lo fundamental dejamos copiando el grueso de la información perdida; en total, unas 7 horas perdidas. Cosas a tener en cuenta:

1. La sincronización que tengo del OneDrive —véase entrada anterior— supone que al borrar el home borró también TODO, la nube y los otros ordenadores, cosa que no me ha pasado en Dropbox. MUY IMPORTANTE tener una copia de seguridad local y no fiarse solo de la nube.
2. ¿De dónde viene este problema? Al principio se lo atribuía a que el disco tenía un directorio /home y que la máquina los hubiera "unido" de alguna manera, pero no debería, ya que uno es /home/usuario y el otro es /mantener2/home. Después, mientras estaba intentando instalar Fedora 33 otra vez, anaconda me decía que detectaba dos discos con la misma UUID. ¿Cómo? Pues por que el disco Caviar Black ERA mi antiguo home, y el nuevo es un clon de él (aquí la prueba del delito clonador).

Sí, había clonado uno sobre otro, y eso ha supuesto que tuvieran para el sistema la misma UUID, y debería saberlo, por que como había dicho en la entrada donde explicaba ese cambio, no había sido necesario recurrir a editar fstab, ya que tenía la misma identificación y, además, debería haberlo visto al editar fstab, pero como lo hacemos todo a velocidad terminal, no nos fijamos en el resto del ambiente. Es decir, al decirle al sistema a través de nautilus —ahora llamado Archivos— que borrara el contenido de un disco, el sistema borró los dos que tenían la misma UUID.

En resumen, antes de reutilizar un disco clonado, formatearlo previamente y a ser posible en un ordenador distinto al que contenga la copia, no vaya a ser que también formatee a los dos en paralelo. Y además, copia de seguridad para todo, y no nos fiemos de tener algo en la nube, por que las nubes se las lleva el viento, o un borrado accidental.

90 segundos de retraso en el arranque mientras el sistema busca un UUID inexistente

En las últimas semanas he tenido dos problemas en el ordenador y una curiosidad. La curiosidad la dejamos para después y los problemas los he solucionado ayer. ¿Dos problemas?, si el título solo habla de uno. Al solucionar uno ha desaparecido el otro. Los problemas eran, primero, que el ordenador mostraba ciertos momentos de congelación en fases cada determinado tiempo —20-30 segundos—; el segundo, que solo lo notaba al reiniciar el ordenador, lo que pasa solo por actualización de kernel, era que el sistema se paraba 1 minuto y 30 segundos buscando un dispositivo con un UUID —Identificador Único Universal— inexistente en mi sistema. Al arrancar notaba un tiempo en vacío; si le damos a ESC, en vez de verse el logo de Fedora aparece el protocolo de arranque y ahí se podía leer:

A start job is running for /dev/disk/by-uuid/9013.... (34s / 1 min 30s)

y tenía 90 segundos para leer el mensaje hasta que seguía el arranque, que si no fuera por esto tarda unos 30s. Al apagar también tardaba y aparecía el mensaje

A stop job is running for Disk Manager (7s / 1 min 30s)

Lo primero que hice fue comprobar los UUID de los dispositivos del equipo, así que edité fstab

su -c 'nano -$ /etc/fstab'

y ninguna de las particiones del disco del sistema (/, /boot, /boot/efi) ni los otros 4 discos duros tienen ese UUID.
Ademas, lo comprobé de nuevo con blkid, que muestra los atributos de los dispositivos:


su -c 'blkid'

así como

su -c 'lsblk -ff'

que lo deja más claro, ya que dibuja un árbol mejor distribuido. Y, como debería ser, tampoco coincide ningún dispositivo con ese UUID. Revisando la red en muchos sitios se achaca este problema a un cambio de swap y que el UUID nuevo no haya sustituido al antiguo. Sin embargo mi partición swap muestra el UUID que se le asigna por fstab y la swap funciona como podemos ver

Entonces, si no estaba en fstab, y no era un problema de swap, ¿de dónde venía la orden de buscar ese dispositivo? Me puse a buscar parte de la cadena en los ficheros del sistema

su -c 'grep -lir "9013ddb2" /'

y el resultado fue nulo. Luego revisé los logs, y tampoco apareció nada. Miré todo lo que pude sobre systemd, y nada. Así que finalmente acabé en /boot/efi/EFI/fedora/grub.cfg y ahí estaba:

... resume=UUID=9013ddb2-...

Primero, ¿por qué el sistema no me lo había mostrado al pedírselo?; será que el administrador no puede entrar en EFI...
Segundo, el grub.cfg no se debe editar directamente, como dice el mismo,

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

así que revisamos el fichero /etc/default/grub y los del directorio /etc/grub.d. Ninguno contenía ese UUID, así que ejecutamos

su -c 'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg'

y reiniciamos y arrancó en un suspiro.

El segundo problema era la congelación temporal del sistema. En algunos sitios había observado que se podía deber a mutter, y que ere error se había corregido para la versión 3.34.1.11, pero era la que tenía y seguía congelándose. Sin embargo, al reiniciar después de haber cambiado grub.cfg el sistema dejo de estar congelado, asi que asumo que cada 20 o 30 segundos el sistema seguía buscando un dispositivo inexistente.

Queda por satisfacer la curiosidad, que es sobre sudo. Si me pongo a ello, lo pondré en otra entrada.

El sistema no puede arrancar. UUID ha cambiado. Solución rápida

Me he encontrado en esta situación mientras instalaba alguna de las versiones Live de los sistemas en la entrada anterior. Cuando usamos Fedora Media Writer hay que estar atento de que dispositivo señala como diana; por ejemplo véase aquí.

En algún momento, más atento al café que a la ejecución de las órdenes, Media writer fijó su puntero en mi disco 5 (imagen anterior) y al dar la orden lo que hice fue "reparar" el disco duro, en vez de copiar la iso en el USB. El resultado fue que el disco fue formateado y cambió su UUID —identificador único universal—. La definición de las unidades en estos momentos no se hace simplemente mediante sda1..., sino que se identifican por ese identificador. Véase por ejemplo /etc/fstab en el ordenador donde estoy escribiendo:

El siguiente rearranque el sistema no pudo lanzar el escritorio gráfico y dejó una pantalla en texto sin arranque de sistema, ya que no era un disco externo, formaba parte del sistema.
Tenemos dos soluciones; la lenta y costosa en tiempo, aunque más sencilla, y la rápida, algo trabajosa, pero solucionable en unos minutos. La más lenta es instalar de nuevo el sistema manteniendo todos los discos sin formatear salvo el de sistema. La más rápida nos lleva a editar /etc/fstab.
Nunca me había atrevido a editar fstab por que estaba convencido que también tendría que editar grub, y todos sabemos que desde que tenemos grub 2 no se edita en ficheros de texto plano. Sin embargo la necesidad de recuperar rápidamente el ordenador me obligó a intentarlo. Dividamos la ejecución en partes:

1. Cuando aparece en la pantalla de arranque los diferentes kernels disponibles, que en Fedora suelen ser tres, debajo existe una posibilidad de entrar en recuperación. Elegimos esa posibilidad.

2. Nos lleva a una pantalla completamente en texto. Nos identificamos como administrador y ponemos su palabra clave.

3. Detectamos la nueva UUID de la unidad que ha cambiado. Para ello usamos el comando blkid

# blkid

que nos indica todos los UUID

y debemos apuntarlo a mano o hacer una foto con el teléfono. Existen formas de copiar un trozo de texto, pero son muy complicadas y suponen un esfuerzo excesivo para escribir 36 caracteres.

4. Editamos /etc/fstab. Estamos en un entorno de texto, así que no podemos usar gedit ni otros editores gráficos. Para los que dominen vi/m, adelante. Los demás podemos usar nano

nano -$ /etc/fstab

La opción -$ permite un "soft wrapping", una alineación "suave", lo que permite ver entera la línea aunque el ancho de la ventana sea menor. ¡Cuidado! Esta opción debe ir como la última o por separado si se usan más opciones —véase aquí—.
Cambiamos el UUID del dispositivo por el nuevo. Guardamos

5. Reinicio. Si todo va bien, listo. En mi caso, así ha sido.

Este caso particular se puede ampliar a cambios de discos. En concreto el sistema de esa máquina permite el cambio en caliente. Si queremos cambiar un disco interno identificado en el arranque podríamos aplicar este sistema para poder hacer cambios rápidos en minutos.

Errores al introducir un nuevo dispositivo [ACTUALIZADO]

Como decía en la entrada anterior, la moda multimedia me ha generado un problema... De repente me ha faltado espacio. Mi sistema principal está distribuido de la siguiente manera:
sda - disco duro sólido de 64 GB. Es root, y contiene solo el sistema
sdb - caviar black de 2TB. Contiene solo mi carpeta personal
sdc - caviar black de 1TB. Tiene material multimedia
sdd - caviar green de 3TB. Es la copia interna del resto del equipo. Duplica el material importante.

No está distribuido, probablemente, de la mejor manera posible, pero está así dispuesto por razones históricas, ya que al cambiar de ordenador no cambio de discos y suelo mantener desde hace años un sistema similar. Sin embargo, podemos decir que la capacidad de almacenaje debería ser suficiente. Pero debido a que guardo en el interior del sistema los trabajos almacenados desde 1990, no he tenido sitio para hacer la última copia de seguridad en el disco interno.

Por supuesto, la solución más sencilla sería cambiar el disco de 3 TB por uno de 4TB, pero no me han parecido adecuado los costes, superiores a 150€.

Entre los discos que tengo "aparcados" para diferentes usos según el momento tenía uno de 1,5TB -un caviar black-, y como aun me quedaba una conexión SATA sin ocupar, lo he incorporado como quinto disco. Lo he conectado en caliente de forma frontal, formateado (era un antiguo home con una carpeta personal antigua), configurado para arranque al encender el ordenador.

Cuando todo parecía listo, una de mis aplicaciones lo identificaba mediante su UUID, ya que no le había puesto una etiqueta, y le añadí un nombre. Luego actualicé el ordenador y lo reinicié; bueno, lo intenté, por que esta fue la respuesta:

Simplemente, estaba identificado por su UUID y, supongo, al haberle cambiado la etiqueta, ya no era identificado.

Las soluciones posibles eran
1. La primera que se me pasó por la cabeza; instalar de nuevo el sistema, integrando los discos a mi gusto. Tendría una mejora añadida; librarme de kde, que aunque cumple mis necesidades, no me gusta.

2. Dos, mucho más delicada; editar con un LiveCd fstab.

Por suerte, suelo empezar por la versión más barata o que exija menos tiempo. Simplemente extraje el disco, arranque el equipo -funcionó-, volví a introducir el disco en caliente y lo configuré de nuevo. MUCHO más fácil.

Como consejo, evitar configuraciones tras la adaptación de nuevos dispositivos antes de reiniciar.

Además de añadir un disco, apliqué tune2fs para intentar aumentar el volumen disponible, pero eso lo dejamos para un tercer episodio.

[ACTUALIZACIÓN]: Al final no quedó más remedio que editar los fstab

Fedora sobre Ubuntu. Error al compartir home

Estoy en un cambio desde Ubuntu a Fedora. Después de instalar con éxito Fedora sobre Ubuntu en el portátil decidí cambiar el sistema también en uno de los ordenadores de trabajo. Decidí instalarlo directamente sobre la particiones de Ubuntu, al igual que había hecho con el portátil. Una inicial de sda1 para sistema (/), con formateo a ext4 y en la extendida sda5 en ext4 sin formatear para home (nombre de usuario idéntico) y sda6 swap. La instalación la realicé desde el CD Live i686 en unos minutos y permite el arranque y comienza la configuración. En un punto avisa de que ya existe un directorio idéntico al que va a generar para home pide permiso para utilizarlo como tal y cambiar sus permisos o si preferimos cambiar a otro. Autorizo el cambio de permisos (un par de minutos de espera) y ya llama a la pantalla de entrada. Sin embargo, al poner la contraseña y entrar salta un error (calidad baja de imagen sacada con el teléfono). Daba un mensaje del Asistente de problemas, y guardé la imagen (o eso me parecía a mi) pero luego no fui capaz de encontrarla, así que supongo que la guardó en RAM; de todas maneras, no explicaba la causa de lo que pasaba

Entonces hice un segundo intento; antes de la instalación borré desde el arranque del CDLive todo fichero de configuración y todos los directorios ocultos, dejando solo .mozilla y datos y luego instalé. El resultado fue el mismo. Finalmente instalé completamente de limpio formateando todo el disco y funcionó (estoy escribiendo en él). Entre las posibles causas para este error, hckorootx ha sugerido un posible cambio de la UUID de la partición que incluye el directorio home. Las UUID de las particiones cambian mediante un MD5 sobre la estructura de ficheros al reformatearla, pero como no se ha formateado, a lo mejor no coincidiría con la que Fedora ha calculado al instalar. Sin embargo, eso no pasó en el portátil. En él, al haber cambiado el nombre del usuario, cambio también el directorio, y el que tenía todas las configuraciones de ubuntu no fue utilizado en el arranque. Desde mi punto de vista, al instalar Fedora sobre Ubuntu debemos evitar usar el mismo directorio de usuario en home, ya que las "herencias" de Ubuntu no coinciden con los nuevos deseos de Fedora.