Juste une remarque, pour finir: de nos jours un démarrage en presque
deux minutes, avec écran figé et aucune ligne de code montrant une
activité du système, peut laisser perplexe, surtout pour un premier
utilisateur de debian et surtout aussi pour ceux habitués à des temps
de boot devenus vraiment courts avec la démocratisation des SSD. En
fait, j'ai moi même mis un certains temps avant de constater qu'il me
fallait simplement attendre environ deux minutes pour pouvoir me
connecter, et j'ai plusieurs fois fait des Ctrl+Alt+Suppr ou
Ctrl+Alt+Fn intempestifs avant de commencer à comprendre. Celui qui,
démarrant une installation fraîche de stretch, observe ce comportement,
a de quoi rester perplexe et peut vite avoir envie de passer à un autre
linux...Peux-t-on faire remonter ce comportement comme un bug?
--
Frédéric Baldit
Le mar. 08 mai 2018 à 16:29:11 +0000
Eric Degenetais <edegenetais@henix.fr> a écrit:
> Le 8 mai 2018 3:12 PM, "Frédéric Baldit" <frederic.baldit@free.fr> 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.
>
> De rien :)
>
>
> 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.
>
> Tel que je comprends, le problème est le suivant : comme tout
> logiciel, le noyau est déterministe. Il dépend donc de sources
> extérieures d'entropie pour générer des nombres aléatoires de bonne
> qualité. Il me semble qu'il a existé à une époque des périphériques
> matériels spécialisés dans la génération d'entropie, donc de nombres
> aléatoires, je ne sais pas si ça existe encore. Dans nos systèmes qui
> n'en sont pas équipés, le générateur est initialement dans un état
> connu, et accumule de l'entropie en provenance du clavier, de la
> souris, des cartes réseau, etc. Ça prend du temps de s'éloigner
> suffisamment de l'état initial prédictible. Concernant la fourniture
> d'entropie par un fichier sauvegardé au shutdown et relu, je me
> souviens clairement avoir vu passer les logs "random seed saved" et
> "random seed reloaded" à chaque shutdown et boot de mon PC sous
> gentoo, environ trois ans en arrière. J'ignore pourquoi ce procédé
> n'aurait pas été conservé depuis.
>
>
> Merci à vous deux,
> --
> Frédéric Baldit
>
> Le lun. 07 mai 2018 à 17:45:38 +0000
> Eric Degenetais <edegenetais@henix.fr> a écrit:
>
> > D'après ce que j'ai compris, le traitement proposé repose sur deux
> > pistes extérieures au noyau :
> > 1) vérifier s'il y a vraiment besoin d'un nombre aléatoire de
> > qualité, 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 la
> > 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).
> >
> > Tu peux booter sur l'ancien noyau en attendant.
> >
> > Julien