Mise à jour 9
J'ai décidé d'essayer une expérience. J'ai retiré le SSD de mon bureau et l'ai temporairement placé dans mon ordinateur portable Dell Latitude. Et voilà, il a chargé le initrd
sur un ordre de grandeur plus rapidement, réduisant de 6 secondes le temps de démarrage ...
Je suis un peu confus maintenant ... peut-être que GRUB a un problème avec le chipset de ma carte mère?
Mise à jour 8
J'ai donc remarqué quelque chose d'intéressant à propos de la lumière d'activité du disque dur. Lors du chargement du initrd
, c'est presque comme si la lumière était PWMed à un rapport cyclique de 10% ou quelque chose. Cela me fait me demander si la lecture de GRUB n'est pas optimisée, peut-être quelque chose comme un appel du système d'exploitation pour lire chaque octet plutôt que de lire l'image en tant que flux d'octets?
Mise à jour 7
Il semble que le chargement du disque virtuel initial soit une grande partie du problème.
Dans GRUB, j'ai appuyé Csur l'invite de commande manuelle. J'ai ensuite procédé à la saisie de chaque ligne de ma configuration par défaut une par une (la saisie de ces UUID était pénible!) Et j'ai noté le temps nécessaire à la commande. Voici ce que j'ai trouvé:
- La plupart des commandes exécutées instantanément
- La commande pour charger le noyau a pris environ une seconde
- La commande pour charger le disque virtuel initial a pris 7 secondes
Après avoir tapé toutes les lignes du fichier de configuration, je procède ensuite à l'exécution boot
. Entre le moment où j'ai appuyé sur Entrée et le moment où l'écran de connexion est apparu, il a fallu environ 7,5 secondes.
Il est intéressant de noter que l'image initiale qu'il charge est de 36 Mo. Donc, s'il a fallu 7 secondes pour se charger, il ne le lit qu'à 5 Mo / s!
Le voyant d'activité du disque sur ma tour reste allumé pendant 7 secondes ...
Voici également un extrait intéressant de la page Wikipedia sur initrd :
D'autres distributions Linux (telles que Fedora et Ubuntu) génèrent une image initrd plus générique. Ceux-ci commencent uniquement par le nom de périphérique du système de fichiers racine (ou son UUID) et doivent découvrir tout le reste au démarrage. Dans ce cas, le logiciel doit effectuer une cascade complexe de tâches pour obtenir le système de fichiers racine monté
Mise à jour 6
Nathan Osman a demandé le temps de démarrage en mode mono-utilisateur dans le chat.
Entre le moment où j'appuie F10sur GRUB et le moment où l'invite apparaît, cela prend 13 secondes.
De plus, je parlais à Zanna et Rinzwind dans le chat et ils ont tous deux un démarrage de 8 secondes à partir du moment où le bouton d'alimentation a été enfoncé. Mes 20 secondes viennent de GRUB. Si je comptais le temps POST, ce serait encore plus long!
Mise à jour 5
Ubuntu peut lire mon SSD à sa vitesse maximale de 550 Mo / sec ...
Mise à jour 4
J'ai donc supprimé les quiet splash $vt_handoff
paramètres de la commande de démarrage dans GRUB sur mon ordinateur portable (gardez à l'esprit que cet ordinateur portable n'a pas de SSD) , et j'ai remarqué une chose très intéressante lors de la séquence de démarrage:
Il se bloque sur cette ligne pendant 15 secondes:
[ 4.374390] init: plymouth-upstart-bridge respawnng too fast, stopped
Voici une image (de faible qualité):
Je ne sais pas quelle est la signification de cela ...
Mise à jour 3
J'ai chronométré le démarrage de l'une de mes autres machines exécutant 14.04 (gardez à l'esprit que cette machine n'a pas de SSD) , et à partir du moment où j'appuie sur Entrée dans GRUB jusqu'à ce que l'écran de connexion apparaisse, cela prend 40 secondes.
Après avoir appuyé sur Entrée, il reste sur ce même écran violet blanc pendant 20 secondes, après quoi l'animation Ubuntu se charge et il faut encore 20 secondes avant d'atterrir sur l'écran de connexion.
J'ai regardé la sortie de dmesg
, mais je ne peux pas vraiment dire où elle a fini de démarrer. Je pense que ça s'est terminé à 25 secondes. Voici les dernières lignes:
[ 24.916824] wlan0: associated
[ 24.916852] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 25.215550] init: kdm main process (869) killed by TERM signal
[ 25.441216] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[ 25.445587] vboxdrv: Found 2 processor cores.
[ 25.446142] vboxdrv: fAsync=0 offMin=0x18c offMax=0x960
[ 25.446228] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[ 25.446230] vboxdrv: Successfully loaded version 4.3.36_Ubuntu (interface 0x001a000b).
[ 25.476940] vboxpci: IOMMU not found (not registered)
[ 33.174926] init: plymouth-upstart-bridge main process ended, respawning
[ 36.495811] init: anacron main process (933) killed by TERM signal
Si je l'ai bien interprété, cela semble être un problème universel GRUB.
Update 2
J'ai pu confirmer qu'il s'agit d'un problème GRUB en définissant la couleur d'arrière-plan de GRUB sur vert en utilisant la ligne de commande accessible en appuyant sur Clorsque dans GRUB.
Lorsque j'appuie sur Entrée, j'obtiens un écran vert vierge pendant environ 15 secondes avant le chargement de l'animation de démarrage Ubuntu ...
Mise à jour
Je pense que le problème est que GRUB prend beaucoup de temps pour charger l'image du noyau.
Question
J'ai installé Ubuntu 16.04 sur mon SSD Samsung 850 Pro 512 Go, et je ne comprends pas pourquoi mon temps de démarrage est de 20 secondes. (À partir du moment où j'ai appuyé sur Entrée dans GRUB). Gardez à l'esprit que le 20 dont je parle est 17 sur l'écran de connexion, puis 3 sur le bureau)
Aussi, je ne sais pas si cela est pertinent ou non, mais:
- Ubuntu est installé en mode MBR, car je méprise l'UEFI.
- J'ai installé les pilotes propriétaires Nvidia
En regardant l'image générée parsystemd-analyze plot > bootimage2
, ma startup a apparemment pris 3 secondes?
Et en regardant dmesg
, ma startup a apparemment pris 4 secondes. Mais je l'ai chronométré avec mon chronomètre et cela m'a pris 20 secondes! (N'incluant pas le temps de POST) Encore une fois, gardez à l'esprit que le 20 dont je parle est 17 sur l'écran de connexion, puis 3 sur le bureau)
Voici comment se déroule la séquence de démarrage:
- PUBLIER
- Charges GRUB
- Je démarre mon chronomètre en appuyant sur ENTER
- Je reçois un écran violet vierge pendant environ 15 secondes
- Je vois l'animation de démarrage d'Ubuntu pendant deux secondes
- J'atterris sur l'écran de connexion
- J'arrête le chronomètre
- J'entre mon mot de passe, appuie sur Entrée et redémarre mon chronomètre.
- Après 3 secondes, j'atterris sur le bureau
- J'arrête à nouveau mon chronomètre.
Voici la sortie complète de dmesg
: http://paste.ubuntu.com/23955108/
Et voici les premières lignes de la sortie de systemd-analyze blame
:
365ms dev-sda5.device
327ms networking.service
287ms accounts-daemon.service
286ms ModemManager.service
233ms systemd-logind.service
216ms apport.service
213ms grub-common.service
209ms ondemand.service
200ms irqbalance.service
183ms speech-dispatcher.service
178ms apparmor.service
160ms gpu-manager.service
148ms thermald.service
148ms pppd-dns.service
146ms systemd-user-sessions.service
142ms alsa-restore.service
140ms console-setup.service
137ms rsyslog.service
105ms NetworkManager.service
104ms upower.service
102ms avahi-daemon.service
100ms systemd-udev-trigger.service
Ces gens ont le même problème:
- https://ubuntuforums.org/showthread.php?t=2325045
- https://www.bleepingcomputer.com/forums/t/598260/booting-ubuntu-temporially-stuck-on-a-purple-screen/
- Et il semble que même les personnes atteintes d'ARCH ont ce problème ...
Des idées?
systemd-analyze blame
. La partie étrange est que Grub a été bloqué sur le "chargement du disque RAM initial" pendant environ 10 secondes alors que cela devrait être une fraction de seconde en raison de la taille du fichier. Puis le décalage a disparu. C'était peut-être une mise à jour du noyau? Peut-être que les modifications que j'ai apportées à plymouthd
je ne suis pas sûr.