démarrage lent - "un travail de démarrage est en cours pour dev-disk-by ..."

Si vous obtenez "un travail de démarrage lancé par dev-disk-by .." suivi d'un délai de 90 secondes lors de chaque démarrage, procédez comme suit:

1. Installer gparted à l’aide du Software Center
2. Ouvrez gparted et voyez quelles partitions utilise actuellement Ubuntu

3. Modifiez le fichier fstab en utilisant la ligne ci-dessous.

   sudo -H gedit /etc/fstab
   

4. Trouvez le périphérique que vous n'utilisez pas actuellement

5. Insérez un # et un espace au début de cette ligne le commente.

6. Réinitialiser, espérons que cela fonctionne pour vous!

On dirait que le problème était dû au fait que même si fstab avait une entrée pour un échange, il n'y en avait pas vraiment. J'ai utilisé GParted pour redimensionner la partition et créer un nouvel échange. J'ai ensuite copié l'UUID dans le fichier fstab ...

1. J'ai maintenant un échange
2. Le démarrage ne dure que quelques secondes contre 90 + secondes

J'ai eu le même problème après avoir redimensionné ma partition principale sur ma VM car gparted live m'a obligé à supprimer & amp; réinitialiser mon échange pour le faire. Cela a entraîné la définition d'un nouvel UUID qui ne correspondait pas au fichier fstab.

Pour éviter le problème, dans /etc/fstab vous pouvez soit

• Remplacez l'UUID swap par le nouveau (exécutez sudo blkid pour le trouver) après le redimensionnement de la partition principale.

• Ou commentez la partition de swap avant (ou après) le redimensionnement de la partition principale.

Je recommanderais le premier puisque c'est la façon dont le système d'exploitation doit être configuré.

Dans mon cas, j'utilisais auparavant le swap crypté et le job de démarrage mentionnait /dev/mapper/cryptswap1 . Pour résoudre le problème, j'ai également dû supprimer le fichier /etc/crypttab , en plus des étapes décrites dans la réponse de William MacDonald.

Lors du redimensionnement ou de la suppression de partitions avec gparted, vous devez souvent créer une nouvelle partition de swap.

Il est alors nécessaire d’activer le swap via gparted après sa création (il y a la commande "Activer le swap").

De plus, vous devez copier le nouvel UUID dans / etc / fstab pour le monter sinon, au démarrage, le système d'exploitation tentera de le trouver mais en vain car le fichier fstab contient l'UUID faisant référence à l'ancien swap. Gparted fournit les informations pour l'UUID mais vous pouvez facilement les exécuter dans un terminal:

sudo blkid

pour le trouver.

J'ai eu le même problème lors du démarrage.

Dans mon fichier /etc/fstab , mes partitions ont été définies comme /dev/sda1 , /dev/sda2 , etc., mais lors du démarrage, le message est apparu plusieurs fois em> "(" x "définit quelle unité ou partition a été affectée).

Pour le résoudre, j'ai modifié la valeur de /dev/sdx par l'UUID de la partition. Pour voir l'UUID, à partir du terminal, exécutez lsblk -f . Ensuite, copiez l'UUID de la partition affectée et écrivez-la dans le fichier /etc/fstab , en remplaçant /dev/sdax comme suit: /dev/sda1 change en UUID=xxxxxxxxxxxxxxxxxx .

Cela a fonctionné pour moi, j'espère que cette information est utile.

Mon démarrage a été ralenti car j'ai échangé mon disque et l’UUID ne correspondait pas. Cela a obligé Ubuntu à effectuer une analyse au démarrage.

Je change souvent de lecteur. Si vos montages sont toujours au même endroit (comme le mien), vous pouvez simplement supprimer l'UUID et placer le chemin direct pour éviter que cette erreur d'analyse ne se produise ...

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

Vous pouvez ignorer l'attente et accéder directement à votre écran de connexion en utilisant ' Ctrl + c ', puis travaillez sur la solution. Parfois, cela durera éternellement, sinon.

En plus de vérifier /etc/fstab ou /etc/crypttab comme mentionné dans les autres réponses, vérifiez également les UUID provenant des paramètres du noyau dans /etc/default/grub . Pendant un moment j'ai été très confus par un système qui avait un /etc/fstab parfaitement cromulent seulement pour découvrir un paramètre de noyau resume=… dans la configuration GRUB.