miércoles, 27 de noviembre de 2019

90 segundos de retraso en el arranque miestras 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.


4 comentarios:

  1. Two problems? If the title only speaks of one. When solving one the other has disappeared. Do you think is it possible to get rid of all of them?

    ResponderEliminar
  2. I hope that this unpleasant problem has been successfully fixed and now you don't experience any other bugs!

    ResponderEliminar
    Respuestas
    1. Por curiosidad, a ver si este mensaje, que creo que es un spam automatizado, responde a esta respuesta. Solo por curiosidad ...

      Eliminar