Solución «dracut-initqueue timeout – starting timeout scripts»
En más de una ocasión me he encontrado que al encender un servidor con GNU Linux, en el registro de arranque ha aparecido este mensaje «dracut-initqueue timeout – starting timeout scripts» Esto suele ser debido a que se han modificado los volúmenes lógicos y el sistema no los puedo localizar.
Explicación del problema
Los mensajes de «dracut-initqueue timeout – starting timeout scripts» se imprimen en bucle durante el arranque y se inicia una shell de emergencia o bien, depende del volúmen lógico que sea, continua el arranque. Todo este proceso hace que el sistema de demore mucho al iniciarse o incluso que no consigamos que se inicie.
Esto es debido a que se han cambiado la configuración de los volúmenes LVM, pero los ficheros de configuración no se actualizaron. Los más probable es que los parámetros del kernel en el fichero «/etc/default/grub» no están al día.
Solución del problema
Estos pasos se pueden ejecutar después de encender el sistema, desde un kernel anterior, o bien después de arrancar el sistema desde un medio de instalación o ingresar en modo de recuperación.
Listamos los volúmenes lógicos del sistema:
lvs -o vg_name,lv_nameVG LV
centos lv_boot
centos lv_root
centos lv_swap
Verifica que el parámetro «rd.lvm.lv=» coincide con el nombre de los volúmenes del sistema:
# grep GRUB_CMDLINE_LINUX /etc/default/grubGRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/lv_boot rd.lvm.lv=centos/lv_root rd.lvm.lv=centos/lv_swap rhgb quiet"
Una vez comprobado y en su caso modificado el fichero, lo tenemos que volver a recargar:
#En sistemas sin UEFIgrub2-mkconfig -o /etc/grub2.cfg
#En sistemas con UEFIgrub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Y ahora sólo nos queda reiniciar el sistema:
reboot
Este procedimiento lo he probrado de manera satisfactoria en CentOS 7, RHEL 7 y Ubuntu 18
Lo dejamos aquí, espero que el artículo os sirva en el algún momento, nos vamos leyendo ^.^
hola, tengo un caso con rhel7 vere si me sirve tu procedimiento y te cuento , saludos
Hola Pablo,
Espero te sirva.
Saludos
la incidencia es que tengo un volumen en el storage y este ultimo no es reconocido después de la actualización de RHEL
y el grupb no inicia, quedando solo en el prompt luego de iniciar mediante rescue mode, al tratar de iniciar por los kernel antiguos queda stoppeado el inicio.
Hola, podrías apoyarme en solucionar este tema, seguí tu procedimiento, pero el mismo sigue presentando la falla, faltaban unas unidades en /etc/default/grub pero aun así sigue la falla.
Gracias!!!
Hola Julian,
Gracias a ti por pasarte y comentar. Un saludo
haz lo mismo que mencionan pero ahora colocando la ruta absoluta
#En sistemas sin UEFI
grub2-mkconfig -o /mnt/sysimage/etc/grub2.cfg
#En sistemas con UEFI
grub2-mkconfig -o /mnt/sysimage/boot/efi/EFI/redhat/grub.cfg
y al final de cada uno debe decir «donde»
reboot
Muchas gracias, amigo!!! Me has salvado!!! Lo he probado y me ha funcionado en un SLES 12 SP4. Lo que no me ha funcionado es el «grub2-mkconfig -o /etc/grub2.cfg», pero ya lo miraré con más calma.