Est-il habituel qu'Ubuntu 14.04.2 prenne longtemps à l'étape «aléatoire: le pool non bloquant est initialisé» pendant le processus de démarrage?

9

Pendant le processus de démarrage, mon Ubuntu 14.04.2 prend environ 11 secondes pour terminer l'étape "aléatoire: le pool non bloquant est initialisé" (c'est l'étape la plus lente, FYI).

Que signifie cette étape?
Est-il normal de prendre beaucoup de temps pour le terminer?
Y a-t-il une solution à cela?

Un exemple de journal / var / log / dmesg de mon Ubuntu 14.04.2 est présenté ci-dessous:

[    2.090510] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    2.091836] i915 0000:00:02.0: registered panic notifier
[    2.103088] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[    2.104819] acpi device:02: registered as cooling_device4
[    2.106250] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input6
[    2.107908] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[    2.214193] psmouse serio1: synaptics: queried max coordinates: x [..5888], y [..4856]
[    2.301008] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[    2.334007] psmouse serio1: synaptics: Touchpad model: 1, fw: 7.4, id: 0x1e0b1, caps: 0xd04773/0xe40000/0xa0400, board id: 0, fw id: 639087
[    2.409482] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input5
[    2.914326] Switched to clocksource tsc
[    3.120191] random: nonblocking pool is initialized
[   14.745283] Adding 3986428k swap on /dev/sda5.  Priority:-1 extents:1 across:3986428k FS
[   14.875375] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   15.027854] systemd-udevd[333]: starting version 204
[   15.316294] lp: driver loaded but no devices found
[   15.330491] ppdev: user-space parallel port driver

14.04 boot

— À M
source

2

Je crois que cette étape particulière ne prend pas vraiment beaucoup de temps. Le message dans le journal dmesg est imprimé lorsque le pool a été initialisé, pas au démarrage de l'initialisation.

Ce que Linux fait pendant ces 11 secondes est probablement de sonder, d'identifier et d'initialiser le matériel, ce qui ne génère pas nécessairement des entrées dans le journal dmesg.

— mdd
source

Oui, je vois la même chose. (J'espère) quelque chose d'inoffensif doit se produire en arrière-plan.

— Tom

2

Dit, une autre façon: non, ce n'est pas normal, quelque chose prend du temps pour répondre. Avez-vous des périphériques que vous pouvez débrancher et réessayer de démarrer? L'un d'eux crée probablement un problème. débranchez votre imprimante, votre mémoire USB, etc ... et essayez de redémarrer. Est-ce plus rapide? Si tel est le cas, essayez de réinsérer un périphérique à la fois dans votre système et de redémarrer pour identifier le périphérique problématique. comprendre l'appareil en difficulté et poster. vous pouvez vérifier l'intégrité de votre disque (SMART Analysis)

Le journal que vous souhaitez consulter est (probablement): /var/log/syslog

vous pouvez également essayer d'entrer dans votre bios et de désactiver des choses comme le port parallèle et d'autres matériels inutilisés, de sorte que vous n'avez pas besoin de perdre du temps à initialiser les ports que vous n'utilisez pas.

— j0h
source

Débrancher tous les périphériques n'a pas fait l'affaire, ni tous les tests que vous avez suggérés. Ubuntu prend toujours les mêmes 11 secondes entre ces 2 étapes et je ne peux pas en trouver la raison. De toute façon, ce n'est pas du tout une catastrophe. Il est possible de vivre avec. Merci beaucoup pour vos conseils.

— Tom

Hé @Tom qu'est-ce que la commande: cat /proc/sys/kernel/threads-maxte donne?

— j0h

Il montre "59582". Est-ce bon ou mauvais? Désolé, je suis complètement novice en ce qui concerne les problèmes de noyau.

— Tom

Je ne suis pas sûr à ce stade, je me plongeais dans d'autres idées sur la résolution de votre problème. J'ai vu quelques autres threads comme celui-ci sur d'autres forums, mais les gens avaient des solutions pour réinstaller. Quoi qu'il en soit, je pense que le "pool non bloquant" a à voir avec les threads et les limites de threads. Je reviendrai plus tard, je dois prendre un bus pour rentrer.

— j0h

2

Il pourrait essayer et échouer à changer de mode vidéo. Essayez d'ajouter nomodesetà la ligne de commande du noyau et voyez si cela aide.

Dans le menu de démarrage de grub, appuyez sur epour modifier l'entrée de démarrage actuelle et ajoutez " nomodeset" à la ligne commençant par linux. Appuyez ensuite sur f10 ou ctrl+ xpour démarrer l'entrée modifiée.

— András Korn
source

Salut @ András, si vous pouviez peut-être modifier votre réponse pour ajouter des instructions sur la façon exacte dont on peut ajouter nomodesetdu noyau?

— Tshilidzi Mudau

1

Réponse modifiée comme demandé.

— András Korn