Question Démarrage lent - "un travail de démarrage est en cours d'exécution pour dev-disk-by ..."


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.

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

Je peux essayer de le faire avec Gparted mais ma principale préoccupation 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 avec swap comme suggéré dans le sujet. Quelqu'un peut-il aider?

Capture d'écran


75
2017-12-18 20:45


origine


Vous voudrez peut-être cloner votre SSD et vous pourrez alors vous dépouiller :) (Essayez CloneZilla pour ça) - Grammargeek
Hah ouais, je suppose que je peux le faire. Je vais attendre que je sois de retour à la maison après les vacances pour que je puisse le déplacer vers quelque chose où j'ai plus d'espace - cpd1
J'ai fini par réparer ça. Je ne pense pas qu'il y ait eu un échange si je passe par Gparted. J'ai fini par en créer un et changer l'entrée dans fstab. Cela a fonctionné et pas plus de 90 secondes de démarrage - cpd1
Si vous avez résolu votre propre problème, faites votre propre réponse et cliquez sur le chèque pour le marquer comme résolu :) - Grammargeek
Fait sens ... Je l'ai ajouté - cpd1


Réponses:


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. Ouvrir gparted et voir 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érer un # et un espace au début de cette ligne le commente.

  6. Réinitialiser, j'espère que ça marche pour vous!


81
2018-04-04 05:06



Les instructions étape par étape aident tout le monde! Merci! - John Hall
J'ai étiqueté le tien comme la réponse depuis que tu as donné les étapes - cpd1
+1 ... pour ceux qui ne peuvent pas le trouver /etc/fstab, vous pouvez également le vérifier dans /etc/crypttab - c'était mon cas. - meta
Si c'est un identifiant de bloc qui a changé, au lieu de le commenter, je préfère corriger l'ID de périphérique. Utilisez lsblk -f pour voir quel périphérique est associé à quel identifiant et remplacez l'identifiant. - user1708042
Ce qui a fonctionné pour moi est de changer l’étape 4 en: "Copier l’UUID trouvé dans gparted pour le périphérique qui cause le retard au démarrage", et l’étape 5 pour: "Remplacez-le par le fichier fstab". Parfois, lorsque vous changez de partition de déplacement, les UUID changent et c'est ce qui cause le problème. Il vous suffit de corriger le nouvel UUID pour la partition modifiée. - m4l490n


On dirait que le problème est 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. Et le démarrage est réduit à quelques secondes contre 90 secondes

28
2017-12-31 01:56



J'ai redimensionné ma partition principale (suppression / recréation de swap) et j'ai rencontré ce problème. J'ai utilisé 'sudo blkid' pour lister les périphériques par UUID et utiliser le nouvel UUID dans / etc / fstab. - Brad Goss
@ BradGoss merci qui le répare! - JREAM


J'ai le même problème après avoir redimensionné ma partition principale sur ma VM depuis Gparted en direct m'a obligé à supprimer et 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 tu peux 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 recommande le premier car c'est la manière dont le système d'exploitation doit être configuré.


21
2017-08-09 18:24



C'est la bonne réponse! Merci mon pote. - CppChase
M'a aidé aussi après avoir déplacé ma partition de swap - Humpawumpa


Dans mon cas, j'utilisais auparavant le swap crypté et le job de démarrage mentionné /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.


13
2017-09-28 11:40





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.


3
2017-09-01 17:09





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

Dans mon /etc/fstab fichier, mes partitions ont été définies comme /dev/sda1, /dev/sda2, etc., mais au démarrage, plusieurs fois est apparu le message "Un travail de démarrage est en cours pour dev-sdx"(" x "définit quelle unité ou partition a été affectée).

Pour le résoudre, j'ai changé la valeur de /dev/sdx par l'UUID de la partition. Pour voir l'UUID, à partir du terminal lsblk -f. Ensuite, copiez l'UUID de la partition affectée et écrivez-la sur /etc/fstab fichier, remplacement /dev/sdax comme suit: /dev/sda1 changements à UUID=xxxxxxxxxxxxxxxxxx.

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


2
2018-04-23 09:30



Oui. C'est précisément le problème que résoudre UUID. Le système monte toute partition avec cet ID, quel que soit l'appareil sur lequel il se trouve ou où se trouve la partition. Avec l'inconvénient que vous devez modifier l'UUID chaque fois que vous détruisez / créez la partition ou installez un nouveau lecteur. Et la duplication d'une partition (copier / coller gparted) créera une copie avec le même UUID, ce qui peut poser problème si l'original et la copie sont tous deux en ligne en même temps. Pour la plupart des gens, cela ne pose aucun problème, mais vous devez en tenir compte lors du clonage / remplacement de disques. - David C.


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

1
2018-01-25 18:43



Comment cette suggestion pourrait-elle accélérer le démarrage? Une référence? - Mostafa Ahangarha
Je répondais à sa question d'erreur à l'origine du démarrage lent. J'ai rendu ma réponse plus claire. - Dan
Oui, le montage par nom de périphérique évite le problème, mais cela crée également le problème que les UUID (et les étiquettes de volume) étaient censés résoudre - le fait de connecter un lecteur à différents endroits (par exemple d’une interface SATA à une autre) briser vos montures. Vous devez décider quel problème est plus facile à vivre, mais assurez-vous de vous souvenir de votre décision car cela peut être très frustrant quand un problème survient parce que vous avez oublié. - David C.