Arranque lento: "se está ejecutando un trabajo de inicio para dev-disk-by ..."

No recuerdo cuándo comenzó a ocurrir el problema, pero es probable cuando moví mi imagen de Ubuntu VMWare a un SSD externo para poder usar el sistema operativo en cualquiera de mis PC. No hay muchos enlaces en Google sobre el tema, pero los que aparecen hablan fstab. Por ejemplo, Arranque lento: ¿qué es "Se está ejecutando un trabajo de inicio para dev-disk-by ..."? - Foro OpenSUSE .

Menciona tener que eliminar la partición de intercambio y crearla nuevamente.

Puedo intentar hacer esto con Gparted, pero mi principal preocupación es perder mi configuración actual en Ubuntu, ya que no estoy completamente seguro de lo que sucederá si me meto en el intercambio como se sugiere en el hilo. Alguien capaz de ayudar?

Si obtiene "un trabajo de inicio iniciado por dev-disk-by .." seguido de un retraso de 90 segundos durante cada arranque, complete los siguientes pasos:

1. Instale gparted usando el Centro de software
2. Abra gparted y vea qué particiones usa Ubuntu actualmente

3. Edite el archivo fstab usando la línea de abajo.

   sudo -H gedit /etc/fstab
   

4. Encuentra el dispositivo que no estás usando actualmente

5. Inserte un #y un espacio al comienzo de esa línea coméntelo.

6. Restablecer, ¡espero que funcione para ti!

Parece que el problema se debió al hecho de que aunque fstab tenía una entrada para un intercambio, en realidad no la había. Usé GParted para cambiar el tamaño de la partición y creé un nuevo Swap. Luego copié el UUID en el archivo fstab ...

1. Ahora tengo swap
2. Y el arranque se reduce a segundos o más de 90 segundos

Tuve el mismo problema después de cambiar el tamaño de mi partición primaria en mi VM ya que gparted live me obligó a eliminar y reiniciar mi intercambio para hacerlo. Eso provocó que se configurara un nuevo UUID que no coincidía con el archivo fstab.

Para evitar el problema, /etc/fstabpuede

• Reemplace el UUID de intercambio con el nuevo (ejecutar sudo blkidpara encontrarlo) después del cambio de tamaño de la partición primaria.

• O comente la partición de intercambio antes (o después) del cambio de tamaño de la partición primaria.

Recomendaría el primero ya que es la forma en que el SO está destinado a ser configurado.

En mi caso, anteriormente había estado usando intercambio encriptado, y el trabajo de inicio mencionado /dev/mapper/cryptswap1. Para resolver el problema, también tuve que eliminar el archivo /etc/crypttab, además de los pasos descritos en la respuesta de William MacDonald.

Al cambiar el tamaño o eliminar particiones con gparted, a menudo tiene que crear una nueva partición de intercambio.

Luego es necesario activar el intercambio a través de gparted después de su creación (existe el comando "Activar intercambio").

Además, debe copiar el nuevo UUID en / etc / fstab para montarlo; de lo contrario, en el arranque, el sistema operativo intentará encontrarlo, pero en vano porque el archivo fstab contiene el UUID que hace referencia al antiguo intercambio. Gparted entrega la información para el UUID pero puede ejecutarlo fácilmente en la terminal:

sudo blkid

para encontrarlo.

Tuve el mismo problema al arrancar.

En mi /etc/fstabarchivo, mis particiones se definieron como /dev/sda1, /dev/sda2etc., pero al arrancar, varias veces apareció el mensaje " Se está ejecutando un trabajo de inicio para dev-sdx " ("x" define qué unidad o partición se vio afectada).

Para resolverlo, cambié el valor de /dev/sdxpor el UUID de la partición. Para ver el UUID, desde la terminal ejecute lsblk -f. Luego, copie el UUID de la partición afectada y escríbalo en el /etc/fstabarchivo, reemplazando de la /dev/sdaxsiguiente manera: /dev/sda1cambios a UUID=xxxxxxxxxxxxxxxxxx.

Funcionó para mí, espero que esta información sea útil.

Mi arranque se ralentizó porque cambié mi unidad y el UUID no coincidía. Esto hizo que Ubuntu escaneara durante el arranque.

Con frecuencia cambio unidades. Si sus monturas siempre están en el mismo lugar (como el mío), puede eliminar el UUID y colocar la ruta directa para evitar que ocurra ese error de escaneo ...

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda1 /               ext4    errors=remount-ro 0       1
/dev/sda2 none            swap    sw              0       0

Situación principal:

Ya respondí en detalles ... (Debe verificar el UUID debajo de esos archivos)

/etc/crypttab 
/etc/fstab
/etc/grub.d/40_custom 
/boot/grub2/grub.cfg

Situación alternativa I - Udev:

Esto podría ser causado por udev si tiene un script de regla/etc/udev/rules.d/ que no debe ejecutarse en el momento del arranque, si el script falla, hará que el paso fstab continúe para siempre, solo edite su script para que coincida con sus necesidades o elimínelo.

Situación alternativa II - Desarrollador cifrado:

Las particiones cifradas pueden ser confusas porque la partición principal tiene un UUID y el descifrado mapeado tiene otro UUID diferente del principal para una única partición, deben definirse en un lugar diferente etc/crypttaby/etc/fstab

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi

El UUID real debe especificarse en etc/crypttab

# cat /etc/crypttab
sda2_crypt  UUID=727fa348-8804-4773-ae3d-f3e176d12dac  none  luks

El UUID virtual debe estar en /etc/fstab

# cat /etc/fstab
UUID=P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi / ext4 defaults,errors=remount-ro 0 1

Situación alternativa III - Ghost Dev:

Un dispositivo que está configurado para montarse en el momento del arranque pero que no está presente en el sistema ni está separado como una unidad usb.

Verifique los dispositivos conectados reales con lsblk -o name,uuid,mountpointy edite /etc/fstabpara mantener solo el dispositivo conectado O deje el dispositivo no conectado allí, pero configúrelos para que se ignoren en el arranque con la opción noautoy configure la línea de esta manera

UUID=BLA-BLA-BLA /mount ext4 option,noauto,option 0 0

Comprobación de los registros del sistema

journalctl -ab 

systemd-analyze blame

systemd-analyze critical-chain

systemctl status dev-mapper-crypt_sda2.device

systemctl status systemd-udev-settle.service

Además de verificar /etc/fstabo /etc/crypttabcomo se menciona en las otras respuestas, también verifique los UUID provenientes de los parámetros del núcleo en /etc/default/grub. Durante un tiempo estuve muy confundido por un sistema que tenía un cromulent perfecto /etc/fstabsolo para descubrir un resume=…parámetro del núcleo en la configuración de GRUB.

Puede omitir la espera e ir directamente a la pantalla de inicio de sesión utilizando ' Ctrl+ c' y luego trabajar en la solución. A veces esto continuará para siempre si no.

Sé que esto es antiguo, pero me topé con este problema, el mismo mensaje de error, mientras clonaba una instalación con rsync. Al no tener errores en fstab, el problema se resolvió después de actualizar el initrdfs a mano. para lograr eso,

1. Arrancar la máquina en una instalación que funcione (máquina de arranque múltiple, livecd de lo contrario)

2. montar la partición raíz del sistema con el problema

3. monte dev, sys y proc como para un chroot que funcione

4. chroot en la raíz del sistema de archivos

5. ejecutar mkinitrd

6. salga de chroot y reinicie.