Linux démarre lentement : trouver ce qui bloque et corriger la cause

Votre PC reste sur le logo de la distribution, affiche une attente interminable ou met longtemps à devenir utilisable après la connexion ? Le bon premier réflexe consiste à repérer quelle étape prend du temps. Je vous propose de mesurer le démarrage, de rechercher une cause précise, puis de vérifier une correction ciblée. Désactiver le premier service d’un classement peut faire disparaître une fonction utile sans résoudre votre problème.

Ce guide concerne un Linux de bureau utilisant systemd. La référence documentaire utilisée est Ubuntu 24.04 LTS avec systemd 255 ; la démarche est également pertinente sur les installations de Debian, Linux Mint ou Fedora qui utilisent systemd, avec des différences de services et de menus. Les sorties chiffrées ci-dessous sont des exemples pédagogiques, pas des mesures réalisées sur votre machine. Aucun gain universel n’est promis.

1. Repérer le moment où l’ordinateur attend

Avant d’ouvrir le terminal, observez un démarrage complet. Le logo du constructeur, le menu de choix du système, le logo Linux, l’écran de connexion et le bureau correspondent à des phases différentes. Si vous passez trente secondes devant le logo du fabricant, chercher une application de bureau inutile ne répondra pas à cette attente.

Chronométrez séparément le temps entre l’appui sur le bouton et l’écran de connexion, puis entre la validation du mot de passe et un bureau utilisable. Excluez le temps que vous prenez pour saisir vos mots de passe, y compris celui du disque chiffré. Gardez les mêmes périphériques et le même état de connexion réseau entre les mesures. Comparez des démarrages à froid entre eux, ou des redémarrages entre eux.

Je conseille trois relevés avant toute modification. Une mise à jour ponctuelle, une vérification de disque ou un réseau momentanément indisponible peuvent rendre un démarrage inhabituel. Un problème qui se répète mérite une investigation différente d’une attente isolée après une grosse mise à jour.

2. Préparer un relevé sans modifier le système

Ouvrez l’application Terminal depuis le menu de votre bureau. Les premières commandes peuvent être exécutées depuis votre dossier personnel : elles consultent l’état du système. Ne recopiez pas un symbole de prompt comme $ devant une commande.

ps -p 1 -o comm=
cat /etc/os-release
systemd --version

La première commande doit indiquer systemd. Si elle affiche un autre programme, cette méthode de diagnostic systemd ne correspond pas à votre installation. Les deux autres permettent de noter la distribution et la version de systemd. Dans une machine virtuelle, une session WSL ou un conteneur, les mesures ne décrivent pas le démarrage complet d’un PC physique.

Notez aussi si le problème est apparu après une modification : disque retiré, changement de réseau, installation d’un logiciel ou mise à jour du noyau. Ce détail servira à choisir la bonne branche du diagnostic.

Avant une correction : conservez une sauvegarde de vos documents importants. Les commandes de lecture n’en ont pas besoin pour fonctionner, mais une modification du montage des disques ou d’un service doit être préparée. Vous sauvegarderez le fichier précis au moment de le modifier. Ne cherchez pas à optimiser un disque qui signale des erreurs d’entrée/sortie : protégez d’abord les données.

3. Mesurer le démarrage avec systemd-analyze

systemd-analyze time

Voici une sortie illustrative simplifiée :

Startup finished in 3.200s (kernel) + 6.800s (initrd) + 42.000s (userspace) = 52.000s
graphical.target reached after 41.700s in userspace.

kernel concerne le noyau ; initrd, l’environnement initial ; userspace, le démarrage des services du système principal. Les durées du firmware et du chargeur peuvent aussi apparaître quand les informations sont disponibles. Leur absence ne signifie pas que ces phases sont instantanées.

Ce résultat reste une mesure du démarrage système, pas un chronomètre jusqu’à un bureau complètement réactif. Il n’inclut pas nécessairement toute l’initialisation des applications. Si la commande annonce que le démarrage n’est pas terminé, attendez et réessayez ; consultez systemctl list-jobs si l’attente persiste.

Dans cet exemple, la partie système après le noyau mérite l’attention. Sur votre PC, examinez la phase réellement dominante et rapprochez-la de votre observation à l’écran. Un noyau rapide avec un long délai avant son chargement conduit vers le firmware ou le chargeur, pas vers les services Linux.

4. Le service le plus lent n’est pas automatiquement le coupable

systemd-analyze blame
systemd-analyze critical-chain

blame classe des durées d’activation. critical-chain montre une chaîne de dépendances ; @ indique le moment de démarrage et + la durée d’activation. Ces vues ont des limites : services parallèles, certains types d’unités et travaux expirés peuvent être mal représentés ou absents. Il faut les croiser avec les journaux.

Imaginez deux tâches lancées simultanément : une tâche de fond dure vingt secondes, mais l’écran de connexion apparaît au bout de dix. Supprimer cette tâche ne vous fera pas automatiquement gagner vingt secondes. En revanche, un montage dont un composant indispensable attend la fin peut retarder toute une branche du démarrage. N’additionnez pas les lignes de blame.

Pour comprendre le parallélisme, produisez le graphique de votre propre démarrage :

systemd-analyze plot > "$HOME/demarrage-linux.svg"
xdg-open "$HOME/demarrage-linux.svg"

Le fichier est enregistré dans votre dossier personnel ; un fichier portant ce nom sera remplacé. Ouvrez-le dans un navigateur si aucune application n’est associée au SVG. Zoomez sur les longues barres et les décalages. Le graphique représente les données disponibles, pas tous les blocages possibles.

5. Lire les messages qui expliquent l’attente

systemctl --failed --no-pager
sudo journalctl -b -p warning --no-pager
sudo journalctl -b -o short-monotonic --no-pager

La première commande repère les unités en échec. Les suivantes lisent le journal du démarrage courant : d’abord les avertissements et messages plus graves, puis la chronologie complète. Les horodatages monotones facilitent la recherche d’une longue pause. Le mot de passe demandé par sudo ne s’affiche généralement pas pendant la saisie.

Une erreur n’est pas forcément la cause de la lenteur. Cherchez un message qui correspond à son moment et à sa durée, puis regardez les lignes voisines. Une connexion réseau qui échoue immédiatement explique moins bien une minute d’attente qu’une tentative répétée pendant cette minute. Un trou entre deux messages est une piste, pas une preuve à lui seul.

Pour examiner un service identifié, remplacez NOM.service par son nom exact :

systemctl status NOM.service --no-pager
sudo journalctl -b -u NOM.service --no-pager

Pour une attente très tôt dans le démarrage, consultez aussi les messages du noyau :

sudo journalctl -b -k --no-pager

Avant de partager un journal, retirez les noms personnels, identifiants de machines, adresses et autres informations privées. Inutile d’envoyer tout le démarrage si quelques lignes autour de l’attente suffisent à expliquer le cas.

6. Cas fréquent : Linux attend un disque qui n’existe plus

Un disque externe retiré ou une partition recréée peut laisser une ancienne déclaration de montage dans /etc/fstab. Un message du type Timed out waiting for device... oriente vers cette piste, sans établir à lui seul l’origine de la déclaration. Les volumes chiffrés et la configuration de reprise d’hibernation peuvent aussi référencer un périphérique.

Commencez par comparer les disques présents et les montages configurés :

lsblk -f
cat /etc/fstab
sudo findmnt --verify --verbose

lsblk -f affiche notamment les systèmes de fichiers et leurs UUID. Dans fstab, retrouvez l’entrée correspondant au disque attendu. findmnt aide à détecter des problèmes de configuration ; ce contrôle ne prouve pas que chaque périphérique sera disponible au prochain démarrage.

Exemple : vous aviez un disque de données monté sur /mnt/archives. Il est désormais débranché définitivement, mais sa ligne reste active dans fstab. Si vous avez confirmé que ce montage est obsolète et qu’aucun service n’en dépend, vous pouvez commenter uniquement cette ligne. Ne touchez pas aux entrées de /, /boot, /boot/efi, /home ou du swap dans le cadre de ce raccourci de dépannage.

1. Sauvegardez le fichier avec la commande suivante. Si ce nom de sauvegarde existe déjà, utilisez un autre nom pour conserver l’état précédent.
2. Ouvrez le fichier avec sudoedit et ajoutez # au début de la seule ligne obsolète.
3. Vérifiez de nouveau la configuration. Ne redémarrez pas avec une erreur nouvelle non comprise.
4. Rechargez la configuration de systemd, puis redémarrez depuis le menu de votre bureau.

sudo cp -a /etc/fstab /etc/fstab.avant-diagnostic
sudoedit /etc/fstab
sudo findmnt --verify --verbose
sudo systemctl daemon-reload

sudoedit ouvre l’éditeur configuré. Avec Nano, enregistrez avec Ctrl+O, validez avec Entrée et quittez avec Ctrl+X. Si vous ne maîtrisez pas l’éditeur proposé, choisissez-en un que vous connaissez avant de toucher au fichier.

Pour un disque facultatif que vous souhaitez continuer à monter, les options nofail et x-systemd.device-timeout=5s peuvent être pertinentes : la première permet au démarrage de continuer sans attendre ce montage, la seconde limite l’attente du périphérique. Elles se placent dans le champ des options de l’entrée concernée. Elles ne conviennent pas à un volume indispensable ; cinq secondes peuvent aussi être trop courtes pour votre matériel.

Pour revenir à l’état sauvegardé, si aucune autre modification utile n’a été faite depuis :

sudo cp -a /etc/fstab.avant-diagnostic /etc/fstab
sudo systemctl daemon-reload
sudo findmnt --verify --verbose

Après correction, vérifiez à la fois le temps de démarrage et la disponibilité des volumes attendus. Si le périphérique absent ne figure pas dans fstab, poursuivez le diagnostic de la référence signalée ; modifier un fichier sans lien avec elle ne corrigera rien.

7. Cas fréquent : le système attend une connexion réseau

Une attente de NetworkManager-wait-online.service indique que certains composants attendent la fin de l’initialisation réseau. Un profil Ethernet inutilisé peut tenter de s’activer, par exemple. Ce service d’attente est distinct de NetworkManager, qui gère les connexions.

systemctl status NetworkManager-wait-online.service --no-pager
sudo journalctl -b -u NetworkManager -u NetworkManager-wait-online.service --no-pager
systemctl list-dependencies --reverse network-online.target
nmcli device status
nmcli connection show

Les commandes examinent l’attente, ses consommateurs et les profils disponibles. Si NetworkManager n’est pas installé, cette branche ne s’applique pas : recherchez le gestionnaire réseau de votre distribution. La liste des dépendances est une aide, pas un inventaire garanti de toutes les configurations possibles.

Si vous identifiez un profil réellement inutilisé qui échoue au démarrage, notez d’abord son réglage :

nmcli -g connection.autoconnect connection show "NOM_DU_PROFIL"

Remplacez NOM_DU_PROFIL par le nom exact, en conservant les guillemets. Pour empêcher uniquement ce profil de s’activer automatiquement :

sudo nmcli connection modify "NOM_DU_PROFIL" connection.autoconnect no

Cette modification ne supprime pas le profil ; il reste activable manuellement. Si son réglage précédent était yes, le retour arrière est :

sudo nmcli connection modify "NOM_DU_PROFIL" connection.autoconnect yes

Redémarrez avec la même connexion physique et contrôlez le réseau utilisé. Si l’attente vient d’un partage distant indispensable, réparez plutôt sa disponibilité ou sa configuration. Je déconseille de désactiver automatiquement l’attente réseau sur toutes les machines : une sauvegarde, un montage ou un service peut en avoir besoin.

8. Cas fréquent : un service installé pour un ancien usage

Un logiciel que vous n’utilisez plus peut encore lancer un service. Avant d’intervenir, identifiez son rôle, sa configuration et ses déclencheurs :

systemctl cat NOM.service
systemctl is-enabled NOM.service
systemctl list-dependencies --reverse NOM.service

Ces informations sont à rapprocher du journal et du chemin de démarrage observé. Gardez le résultat de is-enabled. Un service nécessaire mais lent doit être réparé. La désactivation convient seulement à une fonction devenue inutile dont vous comprenez les conséquences.

Pour une unité classique initialement enabled, dont vous avez vérifié le rôle, vous pouvez retirer son activation automatique :

sudo systemctl disable NOM.service

Cela ne l’arrête pas immédiatement et ne garantit pas qu’aucune dépendance, socket ou minuterie ne la relancera. Si le système signale un autre déclencheur, examinez-le. Ne lancez pas une série de désactivations pour faire disparaître toute la chaîne. Pour une unité static, indirect ou déjà désactivée, cette procédure simplifiée ne correspond pas au cas.

Après redémarrage, vérifiez le service et la fonction concernée. Si la modification n’apporte rien, rétablissez l’activation initiale du service classique :

sudo systemctl enable NOM.service
sudo systemctl start NOM.service

Écartez de ces essais les services fondamentaux du réseau, du stockage, de la connexion, de la sécurité et des mises à jour. Un bureau qui arrive plus vite parce qu’un composant indispensable ne fonctionne plus n’est pas un résultat satisfaisant.

9. Le bureau apparaît, mais reste lent après la connexion

Si l’écran de connexion arrive normalement et que l’attente commence après le mot de passe, concentrez-vous sur la session. Ouvrez le moniteur système dès que possible et observez quel programme sollicite le processeur, la mémoire ou le disque pendant cette période.

Dans Linux Mint Cinnamon, cherchez Applications au démarrage. Sous Xfce, cherchez Session et démarrage, puis l’onglet des applications automatiques. Les intitulés varient selon la version et le bureau. Certains logiciels proposent directement une option de lancement à la connexion dans leurs préférences.

Désactivez temporairement le lancement automatique d’une seule application que vous reconnaissez, puis fermez et rouvrez la session. Cela ne désinstalle pas le programme : vous pourrez le lancer manuellement. Pour revenir en arrière, réactivez la même option. Reproduisez votre contrôle avant de modifier une deuxième application.

Un client de synchronisation qui indexe une grosse bibliothèque, un lanceur de jeux ou une restauration de session chargée sont des pistes à examiner. Ne coupez pas au hasard les composants de l’accessibilité ou du bureau. L’objectif est d’attribuer l’attente à une activité identifiable.

10. Une lenteur avant Linux ou apparue après une mise à jour

Pour une attente au logo constructeur, faites un essai sans les périphériques externes non indispensables, après avoir arrêté proprement le PC. Si cela change le résultat, reconnectez-les un par un. Examinez ensuite l’ordre de démarrage dans le firmware : une tentative réseau ou un support absent mérite d’être vérifié. Photographiez le réglage initial avant un changement. Les menus dépendent du fabricant ; ne modifiez pas le mode du contrôleur de stockage ou Secure Boot pour gagner quelques secondes.

Si le ralentissement est apparu après une mise à jour du noyau, essayez ponctuellement le noyau précédent déjà installé, s’il est disponible dans le menu de démarrage. Sur une installation utilisant GRUB, il est souvent proposé dans les options avancées. Ne supprimez pas le noyau actuel et conservez une version permettant de démarrer. Si l’ancien noyau élimine le problème, notez les deux versions et le matériel concerné pour documenter la régression.

Pour des messages d’erreurs disque, des déconnexions de stockage ou des fichiers devenus illisibles, suspendez les essais d’optimisation. Une sauvegarde et un diagnostic matériel sont prioritaires. Évitez de lancer une réparation de système de fichiers sur une partition montée à partir d’une recette générale.

11. Prouver que la correction a réglé le problème

Reproduisez trois démarrages dans les conditions initiales. Comparez la valeur centrale des trois mesures, c’est-à-dire la médiane, plutôt que le meilleur résultat isolé. Gardez séparées les mesures au chronomètre et celles de systemd : elles décrivent des périmètres différents.

Relancez systemctl --failed --no-pager et le journal ciblé. Une correction convaincante fait disparaître l’attente identifiée, améliore la mesure correspondante et conserve les fonctions nécessaires. Si seule une valeur fluctue sans changement du symptôme, poursuivez l’enquête ou annulez la modification inutile.

Pour éviter de perdre le fil, gardez une petite fiche avec la date, le symptôme, la cause supposée, le réglage initial, l’action et le résultat. Après un retrait de disque ou un changement de réseau, revérifiez les anciennes déclarations qui pouvaient dépendre de cet équipement.

Les questions qui restent quand le diagnostic ne suffit pas

Il n’y a aucune unité en échec. Pourquoi le démarrage reste-t-il lent ?

Une opération peut finir correctement après une longue attente. Un délai du firmware ou une application personnelle ne se traduira pas nécessairement par un service système en échec. Revenez à la phase observée et à la chronologie complète.

Peut-on comparer les journaux du démarrage précédent ?

Oui, si votre système les conserve. Utilisez journalctl --list-boots pour vérifier, puis sudo journalctl -b -1 --no-pager pour le précédent. S’il n’est pas disponible, sauvegardez le journal courant avant le prochain essai dans un fichier personnel.

Masquer le logo Linux permet-il de démarrer plus vite ?

Afficher les messages peut aider à repérer une attente, mais retirer une animation n’en corrige pas automatiquement la cause. Votre priorité reste le composant qui retarde l’arrivée à l’étape suivante.

Faut-il réinstaller Linux ?

Une entrée de montage obsolète, un profil réseau inutile ou une application mal configurée peuvent se corriger directement. Je réserve la réinstallation à un problème plus large identifié, avec une sauvegarde vérifiée et une raison précise ; elle ne remplace pas la recherche de cause.

Quelles informations garder pour demander de l’aide ?

Préparez la distribution, la version du noyau obtenue avec uname -r, la phase lente, les changements récents et les messages pertinents. Ajoutez les mesures et le résultat d’une correction déjà tentée. Ces éléments permettent d’étudier une hypothèse concrète plutôt que de repartir de « mon PC est lent ».

Le bon résultat : une attente expliquée et corrigée, un démarrage mesuré dans des conditions comparables et un ordinateur qui conserve toutes les fonctions dont vous avez besoin. Je commencerais toujours par cette preuve avant d’envisager une autre optimisation.