Démarrage lent - “un travail de démarrage est en cours d'exécution pour dev-disk-by…”


109

Je ne me souviens pas du moment où le problème a commencé à se produire, mais il est probable que j'ai déplacé mon image Ubuntu VMWare sur un SSD externe afin de pouvoir utiliser le système d'exploitation sur n'importe lequel de mes PC. Il n'y a pas beaucoup de liens sur Google concernant le problème, mais ceux qui apparaissent en parlent fstab. Par exemple, Amorçage lent - Qu'est-ce que "Un travail de démarrage est en cours d'exécution pour dev-disk-by ..."? - Forum OpenSUSE .

Capture d'écran

Mentionne avoir à supprimer la partition de swap et à la recréer.

Je peux essayer de faire cela 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 le swap comme suggéré dans le fil. Quelqu'un peut-il aider?


Vous voudrez peut-être cloner votre disque SSD et vous pourrez ensuite vous assommer :) (Essayez CloneZilla pour cela)
Grammargeek

Ah oui, je suppose que je peux faire ça. J'attendrai d'être de retour des vacances pour pouvoir passer à quelque chose qui me donne plus d'espace
cpd1

1
J'ai fini par réparer ça. Je ne pense pas qu'il y ait jamais eu un échange si je passais par Gparted. J'ai fini par en créer un et modifier l'entrée dans fstab. Cela a fonctionné et pas plus de 90 secondes de démarrage
cpd1

1
si vous avez résolu votre propre problème, faites votre propre réponse et cliquez sur la coche pour la marquer comme résolue :)
Grammargeek

1
Cela a du sens ... je l'ai ajouté
cpd1

Réponses:


115

Si vous obtenez "un travail de démarrage démarré 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 centre logiciel
  2. Ouvrez gparted et voyez quelles partitions sont actuellement utilisées par Ubuntu
  3. Editez 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 en commentaire.

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


3
Des instructions pas à pas aident tout le monde! Merci!
John Hall

J'ai marqué la tienne comme étant la réponse depuis que tu as donné les étapes
cpd1

10
+1 ... pour ceux qui ne le trouvent pas /etc/fstab, vous pouvez aussi le vérifier /etc/crypttab- c'était mon cas.
Grzegorz

7
Si c'est un identifiant de bloc qui a changé, au lieu de le commenter, je préfère corriger l'identifiant du périphérique. Utilisez lsblk -f pour voir quel périphérique est associé à quel identifiant et remplace l'identifiant.
user1708042

3
Ce qui a fonctionné pour moi est de changer l'étape 4 en: "Copiez l'UUID trouvé dans gparted pour le périphérique à l'origine du retard au démarrage", et l'étape 5 en: "Remplacez-le là où se trouve le périphérique dans le fichier fstab". Parfois, lorsque vous changez de partition de déménagement, 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

35

On dirait que le problème vient du fait que même si fstab avait une entrée pour un échange, il n'y en avait aucune. J'ai utilisé GParted pour redimensionner la partition et créé un nouveau swap. 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 vs 90 secondes et plus

5
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 ensuite utilisé le nouvel UUID dans / etc / fstab.
Brad Goss

32

J'ai eu le même problème après le redimensionnement de ma partition principale sur ma machine virtuelle depuis que gparted live m'a obligé à supprimer et réinitialiser mon swap. Cela a entraîné la création d'un nouvel UUID qui ne correspond pas au fichier fstab.

Pour éviter le problème, /etc/fstabvous pouvez soit

  • Remplacez l’UUID d’échange par le nouveau (exécutez-le sudo blkidpour 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 car c'est la manière dont le système d'exploitation doit être configuré.


M'a aidé aussi après avoir déplacé ma partition de swap
po.pe

17

Dans mon cas, j’avais utilisé auparavant un swap chiffré et le travail 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.


6

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

Il est ensuite 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 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 l'exécuter dans un terminal:

sudo blkid

pour le trouver.


4

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

Dans mon /etc/fstabfichier, mes partitions étaient définies comme /dev/sda1, /dev/sda2etc., mais lors du démarrage, le message " Un travail de démarrage est en cours d'exécution pour dev-sdx " est apparu plusieurs fois ("x" définit l'unité ou la partition affectée).

Pour le résoudre, j'ai changé la valeur de /dev/sdxpar l'UUID de la partition. Pour voir l'UUID, depuis le terminal lsblk -f. Copiez ensuite l’UUID de la partition affectée et écrivez-le dans un /etc/fstabfichier en remplaçant /dev/sdaxcomme suit: /dev/sda1change to UUID=xxxxxxxxxxxxxxxxxx.

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


Oui. C'est précisément le problème que résolvent les UUID. Le système monte toute partition portant cet ID, quel que soit le périphérique sur lequel il se trouve ou l'emplacement de la partition. L'inconvénient est que vous devez modifier l'UUID chaque fois que vous détruisez / créez la partition ou installez un nouveau lecteur. De plus, la duplication d'une partition (copier / coller) crée une copie avec le même UUID, ce qui peut poser problème si l'original et la copie sont tous deux en ligne simultanément. Cela convient à la plupart des gens, mais vous devez en tenir compte lors du clonage / remplacement des lecteurs.
David C.

3

Mon démarrage a été ralenti car j'ai échangé mon lecteur et l'UUID ne correspond pas. Ceci a amené Ubuntu à effectuer une analyse au démarrage.

Je permute fréquemment les lecteurs. Si vos montages sont toujours au même endroit (comme le mien), vous pouvez simplement supprimer l'UUID et placer le chemin direct pour empêcher cette erreur de scan de se produire ...

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

Comment cette suggestion pourrait-elle accélérer le démarrage? Toute référence?
Mostafa Ahangarha

Je répondais à sa question d'erreur qui a causé le démarrage lent. J'ai clarifié ma réponse.
Dan

1
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) modifiera le nom du périphérique, briser vos montures. Vous devez décider quel problème est le plus facile à vivre, mais souvenez-vous de votre décision car cela peut être très frustrant lorsqu'un problème survient parce que vous avez oublié.
David C.

3

Situation principale:

Déjà répondu en détail ... (Vous devez vérifier l'UUID sous ces fichiers)

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

Situation alternative I - Udev:

Cela pourrait être dû à udev si vous avez un script de règles sous /etc/udev/rules.d/qui n’est pas destiné à être exécuté au démarrage, si le script échoue, l’étape fstab sera définitive, modifiez simplement votre script pour répondre à vos besoins ou supprimez-le.

Situation alternative II - Dev crypté:

Les partitions cryptées peuvent être source de confusion car la partition principale a un UUID et celle qui est mappée décryptée ont un autre UUID différent du disque principal pour une partition unique, elles doivent être définies à un endroit différent etc/crypttabet/etc/fstab

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

Le véritable UUID doit être spécifié dans etc/crypttab

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

L'UUID virtuel doit être à /etc/fstab

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

Situation alternative III - Ghost Dev:

Un périphérique qui est configuré pour être monté au démarrage mais qui n'est ni présent dans le système ni détaché comme un lecteur USB.

Vérifiez les périphériques réellement connectés avec lsblk -o name,uuid,mountpointet éditez /etc/fstabpour ne conserver que le périphérique connecté OU laissez le périphérique non connecté là-bas, mais configurez-les pour qu'ils soient ignorés au démarrage avec l'option noautoet définissez la ligne comme ceci

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

Vérification des journaux du système

journalctl -ab 

systemd-analyze blame

systemd-analyze critical-chain

systemctl status dev-mapper-crypt_sda2.device

systemctl status systemd-udev-settle.service

1
Merci, c'est une très bonne réponse et devrait être accepté. La plupart des autres réponses ici sont dangereusement erronées et, même si elles contournent le problème, elles introduisent d'autres problèmes moins évidents, par exemple la suppression du cryptage d'un périphérique d'échange.
Waqar Lim

2

En plus de vérifier /etc/fstabou /etc/crypttabcomme mentionné dans les autres réponses, vérifiez également les UUID provenant des paramètres du noyau dans /etc/default/grub. Pendant un certain temps, j'ai été très déconcerté par un système qui fonctionnait parfaitement bien /etc/fstabpour découvrir un resume=…paramètre de noyau dans la configuration de GRUB.


1
Cela m'a aidé à résoudre le problème. Mon / etc / fstab était bien. Ensuite, /etc/default/grubj'ai également dû apporter des modifications /boot/efi/EFI/fedora/grub.cfg. Le paramètre linux "resume = UUID = ..." est devenu obsolète après que j'ai modifié manuellement la partition de swap.
Stéphane

1

Vous pouvez ignorer l'attente et accéder directement à votre écran de connexion à l'aide du Ctrlsigne c" + ", puis travailler sur la solution. Parfois, cela durera éternellement sinon.


Est-ce que c'est littéralement Ctrl, la touche plus et c?
muru

Oui, c'est ça :)
Ramon Suarez

0

Je sais que c'est vieux, mais je suis tombé sur ce problème, le même message d'erreur, lors du clonage d'une installation avec rsync. n'ayant aucune erreur sur fstab, le problème a été résolu après la mise à jour manuelle de initrdfs. pour y parvenir,

  1. amorcez la machine dans une installation qui fonctionne (machine multiboot, livecd sinon)

  2. monter la partition racine du système avec le problème

  3. monter dev, sys et proc comme pour un chroot en fonctionnement

  4. chroot dans la racine du filesistem

  5. exécuter mkinitrd

  6. quittez chroot et redémarrez.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.