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

72

Je ne me souviens plus du moment où le problème a commencé à se produire, mais il est probable que lorsque j'ai déplacé mon image VMWare Ubuntu vers un disque SSD externe, je pourrai utiliser le système d'exploitation sur n'importe quel PC. Il n'y a pas beaucoup de liens sur Google à propos de ce problème, mais ceux qui apparaissent parlent de fstab. Par exemple ...

lien

Mention de devoir supprimer la partition swap et la créer à nouveau.

Je peux essayer de le faire avec Gparted, mais mon principal souci est de perdre ma configuration actuelle dans Ubuntu car je ne suis pas tout à fait sûr de ce qui se passera si je gâche le swap comme suggéré dans le sujet. Quelqu'un peut-il aider?

Capture d'écran

    
posée cpd1 18.12.2015 - 21:45
la source

9 réponses

79

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!

réponse donnée William MacDonald 04.04.2016 - 07:06
la source
27

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
réponse donnée cpd1 31.12.2015 - 02:56
la source
19

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é.

    
réponse donnée Matthew Cordaro 09.08.2016 - 20:24
la source
12

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.

    
réponse donnée Kalle Elmér 28.09.2016 - 13:40
la source
3

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.

    
réponse donnée Alessandro D'lncal 01.09.2016 - 19:09
la source
2

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.

    
réponse donnée Lord Ferm 23.04.2017 - 11:30
la source
1

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
    
réponse donnée Dan 25.01.2017 - 19:43
la source
1

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.

    
réponse donnée Ramon Suarez 27.02.2017 - 12:55
la source
0

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.

    
réponse donnée Random Poster 03.07.2018 - 16:03
la source

Lire d'autres questions sur les étiquettes