j'exp=C3=A9rimente, depuis une r=C3=A9installation de stretch sous un PC po=
rtable
amd64 (ASUS N55JV) avec le bureau gnome un long temps d'attente au boot.
Je n'ai pas chronom=C3=A9tr=C3=A9 =C3=A0 la seconde pr=C3=A8s, mais =C3=A0 =
ma montre l'=C3=A9cran de
login appara=C3=AEt, de fa=C3=A7on reproductible, au bout de deux minutes.
Auparavant sur le m=C3=AAme ordi. et sous stretch cela durait moins de
30s (je pense).
Lors de la r=C3=A9install. le disque dur (un SSD) a =C3=A9t=C3=A9 repartiti=
onn=C3=A9 (j'ai
gard=C3=A9 le m=C3=AAme sch=C3=A9ma que lors d'une install. de stretch pr=
=C3=A9c=C3=A9dente et
le syst=C3=A8me a =C3=A9t=C3=A9 enti=C3=A8rement r=C3=A9install=C3=A9.
J'utilise le pilote propri=C3=A9taire nvidia et bumblebee pour g=C3=A9rer (=
avec
optimus) le d=C3=A9marrage =C3=A0 la demande de ma carte d=C3=A9di=C3=A9e.
J'ai test=C3=A9 (avec gnome-disks) l'=C3=A9tat de mon SSD (le test long): c=
ela
dit il est sain (m=C3=AAme si l'indicateur wear-leveling-count est =C3=A0 2=
5, le
disque ayant (environ) 5 ans.
Aussi, curieusement, j'ai une situation (que je n'avais pas avant): une
fois connect=C3=A9 sous gnome (apr=C3=A8s les 2 min d'attente), un Ctrl+Alt=
+F1 me
renvoit sur un nouvel =C3=A9cran de login graphique (et pas sur un login en
mode console). Je ne sais pas si c'est normal...
Je n'ai trouv=C3=A9 aucune piste prometteuse sur les posts des forum. Les
messages de dmesg indiquent une grosse attente lors du boot (justement
de environ 120s) qui se termine par la ligne:
random: crng init done
En fichier attach=C3=A9 la sortie texte de la commande dmesg.
Apparemment (recherche sur google) il se pourrait que le (nouveau)
syst=C3=A8me de boot systemd puisse =C3=AAtre fautif, mais je n'en sait rie=
n.
Si quelqu'un a une id=C3=A9e, merci d'avance. Comme d'habitude toute
suggestion est bienvenue. Je peux fournir les renseignements
susceptibles d'aider (sur la machine et le syst=C3=A8me).
Bonjour, C'est un bug lié au fonctionnement du généra teur d'entropie du noyau... Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça corrige une faille de s écu mais dans les programmes en espace utilisateur (en gros, ton sys tème attend qu'il y ait assez d'entropie pour démarrer gdm). Tu peux booter sur l'ancien noyau en attendant. Julien
Bonjour,
C'est un bug lié au fonctionnement du généra teur d'entropie du noyau...
Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça corrige une faille de s écu mais dans les programmes en espace utilisateur (en gros, ton sys tème attend qu'il y ait assez d'entropie pour démarrer gdm).
Bonjour, C'est un bug lié au fonctionnement du généra teur d'entropie du noyau... Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça corrige une faille de s écu mais dans les programmes en espace utilisateur (en gros, ton sys tème attend qu'il y ait assez d'entropie pour démarrer gdm). Tu peux booter sur l'ancien noyau en attendant. Julien
Eric Degenetais
--000000000000ea2b46056ba13cdc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable D'après ce que j'ai compris, le traitement proposé repose sur deu x pistes extérieures au noyau : 1) vérifier s'il y a vraiment besoin d'un nombre aléatoire de qua lité, sinon utiliser un autre appel système 2) utiliser le bootloader pour conserver l'entropie lors d'un reboot pour que le générateur soit plus rapidement près sans sacrifier l a sécurité Éric Dégenètais Le 7 mai 2018 17:42, a écrit : Bonjour, C'est un bug lié au fonctionnement du générateur d'entropie du noyau... Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça corrige une faille de sécu mais dans les programmes en espace utilisateur (en gros, ton système attend qu'il y ait assez d'entropie pour démarrer gdm). Tu peux booter sur l'ancien noyau en attendant. Julien --000000000000ea2b46056ba13cdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="auto">D'après ce que j'ai compris, le traitement p roposé repose sur deux pistes extérieures au noyau :<div dir="a uto">1) vérifier s'il y a vraiment besoin d'un nombre alé atoire de qualité, sinon utiliser un autre appel système </d iv><div dir="auto">2) utiliser le bootloader pour conserver l'entropi e lors d'un reboot pour que le générateur soit plus rapidemen t près sans sacrifier la sécurité <br><br><div data-sma rtmail="gmail_signature" dir="auto">Éric Dégenètais </di v></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 7 mai 2018 17:42, <<a href="mailto:"> lu.net</a>> a écrit :<br type="attribution"><blockquote clas s="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l eft:1ex">Bonjour,<br> <br> C'est un bug lié au fonctionnement du générateur d'e ntropie du noyau...<br> Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça corrige une faille de sécu mais dans les programmes en espace utilisateur (en gros, ton système attend qu'il y ait ass ez d'entropie pour démarrer gdm).<br> <br> Tu peux booter sur l'ancien noyau en attendant.<br> <font color="#888888"><br> Julien<br> <br> </font></div><br></div> --000000000000ea2b46056ba13cdc--
D'après ce que j'ai compris, le traitement proposé repose sur deu x pistes
extérieures au noyau :
1) vérifier s'il y a vraiment besoin d'un nombre aléatoire de qua lité,
sinon utiliser un autre appel système
2) utiliser le bootloader pour conserver l'entropie lors d'un reboot pour
que le générateur soit plus rapidement près sans sacrifier l a sécurité
Éric Dégenètais
Le 7 mai 2018 17:42, <julien@peclu.net> a écrit :
Bonjour,
C'est un bug lié au fonctionnement du générateur d'entropie du noyau...
Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car
ça corrige une faille de sécu mais dans les programmes en espace
utilisateur (en gros, ton système attend qu'il y ait assez d'entropie pour
démarrer gdm).
<div dir="auto">D'après ce que j'ai compris, le traitement p roposé repose sur deux pistes extérieures au noyau :<div dir="a uto">1) vérifier s'il y a vraiment besoin d'un nombre alé atoire de qualité, sinon utiliser un autre appel système </d iv><div dir="auto">2) utiliser le bootloader pour conserver l'entropi e lors d'un reboot pour que le générateur soit plus rapidemen t près sans sacrifier la sécurité <br><br><div data-sma rtmail="gmail_signature" dir="auto">Éric Dégenètais </di v></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 7 mai 2018 17:42, <<a href="mailto:julien@peclu.net">julien@pec lu.net</a>> a écrit :<br type="attribution"><blockquote clas s="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l eft:1ex">Bonjour,<br>
<br>
C'est un bug lié au fonctionnement du générateur d'e ntropie du noyau...<br>
Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça corrige une faille de sécu mais dans les programmes en espace utilisateur (en gros, ton système attend qu'il y ait ass ez d'entropie pour démarrer gdm).<br>
<br>
Tu peux booter sur l'ancien noyau en attendant.<br>
<font color="#888888"><br>
Julien<br>
<br>
</font></blockquote></div><br></div>
--000000000000ea2b46056ba13cdc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable D'après ce que j'ai compris, le traitement proposé repose sur deu x pistes extérieures au noyau : 1) vérifier s'il y a vraiment besoin d'un nombre aléatoire de qua lité, sinon utiliser un autre appel système 2) utiliser le bootloader pour conserver l'entropie lors d'un reboot pour que le générateur soit plus rapidement près sans sacrifier l a sécurité Éric Dégenètais Le 7 mai 2018 17:42, a écrit : Bonjour, C'est un bug lié au fonctionnement du générateur d'entropie du noyau... Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça corrige une faille de sécu mais dans les programmes en espace utilisateur (en gros, ton système attend qu'il y ait assez d'entropie pour démarrer gdm). Tu peux booter sur l'ancien noyau en attendant. Julien --000000000000ea2b46056ba13cdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="auto">D'après ce que j'ai compris, le traitement p roposé repose sur deux pistes extérieures au noyau :<div dir="a uto">1) vérifier s'il y a vraiment besoin d'un nombre alé atoire de qualité, sinon utiliser un autre appel système </d iv><div dir="auto">2) utiliser le bootloader pour conserver l'entropi e lors d'un reboot pour que le générateur soit plus rapidemen t près sans sacrifier la sécurité <br><br><div data-sma rtmail="gmail_signature" dir="auto">Éric Dégenètais </di v></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 7 mai 2018 17:42, <<a href="mailto:"> lu.net</a>> a écrit :<br type="attribution"><blockquote clas s="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l eft:1ex">Bonjour,<br> <br> C'est un bug lié au fonctionnement du générateur d'e ntropie du noyau...<br> Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça corrige une faille de sécu mais dans les programmes en espace utilisateur (en gros, ton système attend qu'il y ait ass ez d'entropie pour démarrer gdm).<br> <br> Tu peux booter sur l'ancien noyau en attendant.<br> <font color="#888888"><br> Julien<br> <br> </font></div><br></div> --000000000000ea2b46056ba13cdc--
BERTRAND Jo=c3=abl
Frédéric Baldit a écrit :
Bonjour, merci aux deux personnes ayant répondu: en effet je comprends mieux pourquoi le système est si long à démarrer, c'est maintenant assez clair. J'ai adoptée la solution la plus rapide: installation de la version précédente du noyau (9.0.5) et ça marche! Rq: je suis quand même étonné, étant donné l'importance de la qualité des générateurs aléatoires pour tout ce qui concerne la sécurité (du système en général), que celui implanté dans le noyau linux ne génère pas des nombres de qualité (aléatoire) suffisante, et ceci en un temps qui ne pénalise pas la rapidité du démarrage. Ceci dit, je me doute que le problème est plus complexe que ça...et que je dois n'avoir qu'une idée très incomplète de la complexité de la situation.
Bonsoir, C'est parce que les développeurs du noyau sont persuadés faire mieux que l'état de l'art. Dans un tas de systèmes (les BSD, mais pas que), l'état du générateur aléatoire est sauvegardé lors de l'extinction et rechargé au démarrage suivant. Ça évite les problèmes de générateur aléatoire qui part dans un état plus ou moins connu. Et le générateur n'est réinitialisé qu'en cas de crash système pour lequel le fichier est inexistant. Cordialement, JKB
Frédéric Baldit a écrit :
Bonjour,
merci aux deux personnes ayant répondu: en effet je comprends mieux
pourquoi le système est si long à démarrer, c'est maintenant assez
clair.
J'ai adoptée la solution la plus rapide: installation de la version
précédente du noyau (9.0.5) et ça marche!
Rq: je suis quand même étonné, étant donné l'importance de la qualité
des générateurs aléatoires pour tout ce qui concerne la sécurité (du
système en général), que celui implanté dans le noyau linux ne génère
pas des nombres de qualité (aléatoire) suffisante, et ceci en un temps
qui ne pénalise pas la rapidité du démarrage. Ceci dit, je me doute que
le problème est plus complexe que ça...et que je dois n'avoir qu'une
idée très incomplète de la complexité de la situation.
Bonsoir,
C'est parce que les développeurs du noyau sont persuadés faire mieux
que l'état de l'art. Dans un tas de systèmes (les BSD, mais pas que),
l'état du générateur aléatoire est sauvegardé lors de l'extinction et
rechargé au démarrage suivant. Ça évite les problèmes de générateur
aléatoire qui part dans un état plus ou moins connu. Et le générateur
n'est réinitialisé qu'en cas de crash système pour lequel le fichier est
inexistant.
Bonjour, merci aux deux personnes ayant répondu: en effet je comprends mieux pourquoi le système est si long à démarrer, c'est maintenant assez clair. J'ai adoptée la solution la plus rapide: installation de la version précédente du noyau (9.0.5) et ça marche! Rq: je suis quand même étonné, étant donné l'importance de la qualité des générateurs aléatoires pour tout ce qui concerne la sécurité (du système en général), que celui implanté dans le noyau linux ne génère pas des nombres de qualité (aléatoire) suffisante, et ceci en un temps qui ne pénalise pas la rapidité du démarrage. Ceci dit, je me doute que le problème est plus complexe que ça...et que je dois n'avoir qu'une idée très incomplète de la complexité de la situation.
Bonsoir, C'est parce que les développeurs du noyau sont persuadés faire mieux que l'état de l'art. Dans un tas de systèmes (les BSD, mais pas que), l'état du générateur aléatoire est sauvegardé lors de l'extinction et rechargé au démarrage suivant. Ça évite les problèmes de générateur aléatoire qui part dans un état plus ou moins connu. Et le générateur n'est réinitialisé qu'en cas de crash système pour lequel le fichier est inexistant. Cordialement, JKB
julien
Bonjour, Tout à fait d'accord avec toi c'est une régressio n pour l'utilisateur final. Pour un serveur c'est pas gênant d'atten dre 2 minutes pour qu'il démarre mais sur un ordinateur portable c'e st pas tolérable (même si c'est pour corriger une éventuel le faille de sécurité sur le générateur d'entropie). J'ai créé le bug : https://bugs.debian.org/cgi-bin/bugrep ort.cgi?bug‰8098 Julien
Bonjour,
Tout à fait d'accord avec toi c'est une régressio n pour l'utilisateur final. Pour un serveur c'est pas gênant d'atten dre 2 minutes pour qu'il démarre mais sur un ordinateur portable c'e st pas tolérable (même si c'est pour corriger une éventuel le faille de sécurité sur le générateur d'entropie).
J'ai créé le bug : https://bugs.debian.org/cgi-bin/bugrep ort.cgi?bug=898098
Bonjour, Tout à fait d'accord avec toi c'est une régressio n pour l'utilisateur final. Pour un serveur c'est pas gênant d'atten dre 2 minutes pour qu'il démarre mais sur un ordinateur portable c'e st pas tolérable (même si c'est pour corriger une éventuel le faille de sécurité sur le générateur d'entropie). J'ai créé le bug : https://bugs.debian.org/cgi-bin/bugrep ort.cgi?bug‰8098 Julien