Démarrage lent - "un travail de démarrage est en cours d'exécution pour dev-disk-by ..."
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 parlent de 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 ..."? - OpenSUSE Forum .
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 de discussion. Quelqu'un peut-il aider?
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:
- Installer gparted à l'aide du centre logiciel
- Ouvrez gparted et voyez quelles partitions sont actuellement utilisées par Ubuntu
Editez le fichier fstab en utilisant la ligne ci-dessous.
Sudo -H gedit /etc/fstabTrouvez le périphérique que vous n'utilisez pas actuellement
Insérez un
#et un espace au début de cette ligne en commentaire.Réinitialiser, espérons que cela fonctionne pour vous!
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 ...
- J'ai maintenant un échange
- Et le démarrage est réduit à quelques secondes vs 90 secondes et plus
J'ai le même problème après le redimensionnement de ma partition principale sur mon VM depuis gparted live m'a obligé à supprimer et à réinitialiser mon swap pour le faire. Cela a entraîné la création d'un nouvel UUID qui ne correspond pas au fichier fstab.
Pour éviter le problème, dans /etc/fstab vous pouvez soit
Remplacez l’UUID d’échange par le nouveau (exécutez
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 façon dont le système d'exploitation doit être configuré.
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.
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.
J'ai eu le même problème lors du démarrage.
Dans mon fichier /etc/fstab, mes partitions étaient définies comme suit: /dev/sda1, /dev/sda2, etc., mais lors du démarrage, le message " apparaît plusieurs fois. Un travail de démarrage est en cours d'exécution 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, exécutez lsblk -f. Copiez ensuite l'UUID de la partition affectée et écrivez-le dans le fichier /etc/fstab en remplaçant /dev/sdax comme suit: /dev/sda1 devient UUID=xxxxxxxxxxxxxxxxxx.
Cela a fonctionné pour moi, j'espère que cette information est utile.
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 causé par dev si vous avez un script règle sous /etc/udev/rules.d/ qui n'est pas destiné à être exécuté au démarrage, si le script échoue, il passera à l'étape fstab Pour toujours, éditez 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 a un autre UUID différent de la partition principale. Elles doivent être définies à l'emplacement différent etc/crypttab et /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,mountpoint et éditez /etc/fstab pour ne conserver que le périphérique connecté OU laissez le périphérique non connecté à cet emplacement, mais configurez-le pour qu'il soit ignoré au démarrage avec l'option noauto et 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
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
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 certain temps, j'ai été très déconcerté par un système qui avait un /etc/fstab parfaitement cromulent uniquement pour découvrir un paramètre de noyau resume=… dans la configuration GRUB.
Vous pouvez ignorer l'attente et accéder directement à l'écran de connexion en utilisant 'Ctrl+c'et ensuite travailler sur la solution. Parfois, cela durera éternellement sinon.