Re: longue attente au boot [résolu]

[Julien]

Bonjour,

J'utilise une Debian SID (unstable) donc j'ai des versions plus
récentes que la version stable :

julien@thinkpad:~$ uname -a
Linux thinkpad 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29)
x86_64 GNU/Linux

Par contre, si tu es en stable, tu devrais avoir une version 4.9.0.6 du
noyau :

https://packages.debian.org/fr/stretch/linux-image-amd64

Est-ce que tu as bien activé le dépot security pour recevoir les mises
à jour de sécurité ?

https://www.debian.org/security/


Julien

Re: longue attente au boot [résolu]

[Frédéric Baldit]

@ Jean Bernon: Je ne comprends pas: je suis sous stretch et uname -r
renvoit  4.9.0-6-amd64. Donc je ne suis ni en version 4.15 ni 4.16 du
noyau. Je pense que par défaut stretch est livré avec 4.9.0, par contre
en stretch-backport on peut installer 4.16.0.

Sinon, la dernière mise à jour de linux-image et linux-headers a en
effet corrigé le problème de temps d'attente au boot, ce qui fait que
je suis revenu dans la situation initiale avec le noyau 4.9.0-6.

Cordialement,

--
  Frédéric Baldit

Le ven. 11 mai 2018 à 10:46:06 +0200
Jean Bernon <jber...@free.fr> a écrit:

> Je découvre naïvement à la lecture de votre échange que vous utilisez
> des kernels 4.15 et 4.16 alors que j'utilise un kernel 3.16. Je suis
> en Debian 9.4 et pensais que les mises à jour incluait celles du
> kernel ce qui ne semble pas le cas. Faut-il mettre à jour le kernel
> indépendamment de Stretch ? 
> 
> *** jean@pc-jean-debian:~ *** $ cat /etc/debian_version 
> 9.4 
> 
> *** jean@pc-jean-debian:~ *** $ uname -a 
> Linux pc-jean-debian 3.16-3-amd64 #1 SMP Debian 3.16.5-1 (2014-10-10)
> x86_64 GNU/Linux 
> 
> 
> 
> - Mail original -
> 
> 
> De: jul...@peclu.net 
> À: debian-user-french@lists.debian.org 
> Envoyé: Mercredi 9 Mai 2018 10:10:35 
> Objet: Re: longue attente au boot [résolu] 
> 
> Bonjour, 
> 
> Tout à fait d'accord avec toi c'est une régression pour l'utilisateur
> final. Pour un serveur c'est pas gênant d'attendre 2 minutes pour
> qu'il démarre mais sur un ordinateur portable c'est pas tolérable
> (même si c'est pour corriger une éventuelle faille de sécurité sur le
> générateur d'entropie). 
> 
> J'ai créé le bug :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898098 
> 
> Julien 
> 
> 
> 
> 

Re: longue attente au boot [résolu]

[Jean Bernon]

Je découvre naïvement à la lecture de votre échange que vous utilisez des 
kernels 4.15 et 4.16 alors que j'utilise un kernel 3.16. Je suis en Debian 9.4 
et pensais que les mises à jour incluait celles du kernel ce qui ne semble pas 
le cas. Faut-il mettre à jour le kernel indépendamment de Stretch ? 

*** jean@pc-jean-debian:~ *** $ cat /etc/debian_version 
9.4 

*** jean@pc-jean-debian:~ *** $ uname -a 
Linux pc-jean-debian 3.16-3-amd64 #1 SMP Debian 3.16.5-1 (2014-10-10) x86_64 
GNU/Linux 



- Mail original -


De: jul...@peclu.net 
À: debian-user-french@lists.debian.org 
Envoyé: Mercredi 9 Mai 2018 10:10:35 
Objet: Re: longue attente au boot [résolu] 

Bonjour, 

Tout à fait d'accord avec toi c'est une régression pour l'utilisateur final. 
Pour un serveur c'est pas gênant d'attendre 2 minutes pour qu'il démarre mais 
sur un ordinateur portable c'est pas tolérable (même si c'est pour corriger une 
éventuelle faille de sécurité sur le générateur d'entropie). 

J'ai créé le bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898098 

Julien 

Re: longue attente au boot [résolu]

[Eric Degenetais]

Pour information, une solution aux bugs déjà déclarés sur l'augmentation du
temps de démarrage, dont le bug 808998 est vraisemblablement un doublon,
est sortie. Elle résoud les problèmes de délai au démarrage introduits par
le correctif de sécurité précédent. À tester mais le défaut évoqué dans
cette conversation devrait faire partie des dysfonctionnements traités.

Cordialement

Éric Dégenètais

Le 9 mai 2018 10:20,  a écrit :

Bonjour,

Tout à fait d'accord avec toi c'est une régression pour l'utilisateur
final. Pour un serveur c'est pas gênant d'attendre 2 minutes pour qu'il
démarre mais sur un ordinateur portable c'est pas tolérable (même si c'est
pour corriger une éventuelle faille de sécurité sur le générateur
d'entropie).

J'ai créé le bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898098

Julien

Re: longue attente au boot [résolu]

[julien]

Bonjour,

Tout à fait d'accord avec toi c'est une régression pour l'utilisateur final. 
Pour un serveur c'est pas gênant d'attendre 2 minutes pour qu'il démarre mais 
sur un ordinateur portable c'est pas tolérable (même si c'est pour corriger une 
éventuelle faille de sécurité sur le générateur d'entropie).

J'ai créé le bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898098

Julien

Re: longue attente au boot [résolu]

[Eric Degenetais]

Bonjour,
c'est déjà fait côté debian, et les développeurs discutent actuellement les
différentes solutions que j'ai évoquées. Les échanges du bugtracker sont
d'ailleurs la source de mes informations à ce sujet.

Cordialement

Éric Dégenètais

Le 8 mai 2018 23:45, "Frédéric Baldit"  a écrit :


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 +
Eric Degenetais  a écrit:

> Le 8 mai 2018 3:12 PM, "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.
>
> 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 +
> Eric Degenetais  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,  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

Re: longue attente au boot [résolu]

[Frédéric Baldit]

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 +
Eric Degenetais  a écrit:

> Le 8 mai 2018 3:12 PM, "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.
> 
> 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 +
> Eric Degenetais  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,  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  

Re: longue attente au boot [résolu]

[Eric Degenetais]

Le 8 mai 2018 3:12 PM, "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.

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 +
Eric Degenetais  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,  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

Re: longue attente au boot [résolu]

[BERTRAND Joël]

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

Re: longue attente au boot [résolu]

[Frédéric Baldit]

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.

Merci à vous deux,
--
  Frédéric Baldit

Le lun. 07 mai 2018 à 17:45:38 +
Eric Degenetais  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,  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

Re: longue attente au boot

[Eric Degenetais]

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,  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

Re: longue attente au boot

[julien]

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

Re: longue attente au boot

[Eric Degenetais]

bonjour,
ça semble lié à la résolution d'une CVE récente : une faille de sécurité
était créée par le fait que les générateurs de nombres aléatoires
n'attendaient pas d'avoir assez d'entropie pour générer des nombres
vraiment aléatoires, ce qui rend les clefs générées prédictibles.
Le patch a semble-t'il rendu l'appel bloquant jusqu'à accumulation d'une
entropie suffisante (ce qui se traduit par des comportements surprenants,
comme par exemple une accélération du boot par l'appui de touches ou le
déplacement de la souris), d'où l'allongement du délai au boot.

Cordialement

__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org


Le 7 mai 2018 à 15:30, Frédéric Baldit  a écrit :

>
> Bonjour,
>
> j'expérimente, depuis une réinstallation de stretch sous un PC portable
> amd64 (ASUS N55JV) avec le bureau gnome un long temps d'attente au boot.
>
> Je n'ai pas chronométré à la seconde près, mais à ma montre l'écran de
> login apparaît, de façon reproductible, au bout de deux minutes.
> Auparavant sur le même ordi. et sous stretch cela durait moins de
> 30s (je pense).
>
> Lors de la réinstall. le disque dur (un SSD) a été repartitionné (j'ai
> gardé le même schéma que lors d'une install. de stretch précédente et
> le système a été entièrement réinstallé.
>
> J'utilise le pilote propriétaire nvidia et bumblebee pour gérer (avec
> optimus) le démarrage à la demande de ma carte dédiée.
>
> J'ai testé (avec gnome-disks) l'état de mon SSD (le test long): cela
> dit il est sain (même si l'indicateur wear-leveling-count est à 25, le
> disque ayant (environ) 5 ans.
>
> Aussi, curieusement, j'ai une situation (que je n'avais pas avant): une
> fois connecté sous gnome (après les 2 min d'attente), un Ctrl+Alt+F1 me
> renvoit sur un nouvel écran de login graphique (et pas sur un login en
> mode console). Je ne sais pas si c'est normal...
>
> Je n'ai trouvé 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é la sortie texte de la commande dmesg.
>
> Apparemment (recherche sur google) il se pourrait que le (nouveau)
> système de boot systemd puisse être fautif, mais je n'en sait rien.
>
> Si quelqu'un a une idée, merci d'avance. Comme d'habitude toute
> suggestion est bienvenue. Je peux fournir les renseignements
> susceptibles d'aider (sur la machine et le système).
>
> Cordialement,
>
> --
>   Frédéric Baldit
>
>

longue attente au boot

[Frédéric Baldit]

Bonjour,

j'expérimente, depuis une réinstallation de stretch sous un PC portable
amd64 (ASUS N55JV) avec le bureau gnome un long temps d'attente au boot.

Je n'ai pas chronométré à la seconde près, mais à ma montre l'écran de
login apparaît, de façon reproductible, au bout de deux minutes.
Auparavant sur le même ordi. et sous stretch cela durait moins de
30s (je pense).

Lors de la réinstall. le disque dur (un SSD) a été repartitionné (j'ai
gardé le même schéma que lors d'une install. de stretch précédente et
le système a été entièrement réinstallé.

J'utilise le pilote propriétaire nvidia et bumblebee pour gérer (avec
optimus) le démarrage à la demande de ma carte dédiée.

J'ai testé (avec gnome-disks) l'état de mon SSD (le test long): cela
dit il est sain (même si l'indicateur wear-leveling-count est à 25, le
disque ayant (environ) 5 ans.

Aussi, curieusement, j'ai une situation (que je n'avais pas avant): une
fois connecté sous gnome (après les 2 min d'attente), un Ctrl+Alt+F1 me
renvoit sur un nouvel écran de login graphique (et pas sur un login en
mode console). Je ne sais pas si c'est normal...

Je n'ai trouvé 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é la sortie texte de la commande dmesg.

Apparemment (recherche sur google) il se pourrait que le (nouveau)
système de boot systemd puisse être fautif, mais je n'en sait rien.

Si quelqu'un a une idée, merci d'avance. Comme d'habitude toute
suggestion est bienvenue. Je peux fournir les renseignements
susceptibles d'aider (sur la machine et le système).

Cordialement,

--
  Frédéric Baldit

[0.00] microcode: microcode updated early to revision 0x22, date = 
2017-01-27
[0.00] Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) 
(gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.88-1 
(2018-04-29)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 
root=UUID=008405b6-78a7-45b4-960a-fac0a3cebfac ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x9e010fff] usable
[0.00] BIOS-e820: [mem 0x9e011000-0x9e017fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x9e018000-0x9e84] usable
[0.00] BIOS-e820: [mem 0x9e85-0x9ead5fff] reserved
[0.00] BIOS-e820: [mem 0x9ead6000-0xad8edfff] usable
[0.00] BIOS-e820: [mem 0xad8ee000-0xadaf2fff] reserved
[0.00] BIOS-e820: [mem 0xadaf3000-0xade25fff] usable
[0.00] BIOS-e820: [mem 0xade26000-0xaeb25fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xaeb26000-0xaef59fff] reserved
[0.00] BIOS-e820: [mem 0xaef5a000-0xaeffefff] type 20
[0.00] BIOS-e820: [mem 0xaefff000-0xaeff] usable
[0.00] BIOS-e820: [mem 0xafc0-0xcfdf] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00042f1f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI 2.0=0xadeae000  ACPI=0xadeae000  SMBIOS=0xaef58418 
[0.00] SMBIOS 2.7 present.
[0.00] DMI: ASUSTeK COMPUTER INC. N550JV/N550JV, BIOS N550JV.208 
11/19/2013
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x42f200 max_arch_pfn = 0x4
[0.00] MTRR default type: 

Re: attente au boot

[Sylvain Sauvage]

Alexandre Gerussi, mercredi 28 février 2007, 20:14:25 CET
 
 Bonjour,

'jour,

 je suis passé à Etch avec noyau 2.6.18 et lilo 22.6.1.
 
 Depuis, au démarrage, l'ordinateur s'arrête environ 30 secondes en 
 affichant LIL, puis affiche le menu lilo comme d'habitude.

  Bizarre. Normalement si Lilo s'arrête sur LIL, c'est qu'il n'arrive
pas à lire le disque (erreur physique ou mauvaise configuration), mais
il est censé s'arrêter là. Le fait qu'il reprenne signifierait qu'il
retrouve finalement ses petits ?
  Pas de problème de disque ?

 Au lancement de etch, le boot s'arrête encore 5 secondes en affichant 
 bios check bypassed, puis démarre enfin.

  Message introuvable dans LILO ou les sources du noyau 2.6.18.
  Tu es sûr du message ?

  Au pif, un antivirus dans le BIOS ?

 Je n'avais jamais remarqué ce message auparavant.
 
 Y a-t-il un moyen d'éviter cette attente de 30 secondes ?
 Comme lilo est un point sensible pour le démarrage, je préfère avoir
 un avis éclairé avant de magouiller n'importe quoi.

-- 
 Sylvain Sauvage

Re: attente au boot

[Alexandre Gerussi]

Sylvain Sauvage a écrit :

Alexandre Gerussi, mercredi 28 février 2007, 20:14:25 CET

Bonjour,


'jour,


je suis passé à Etch avec noyau 2.6.18 et lilo 22.6.1.

Depuis, au démarrage, l'ordinateur s'arrête environ 30 secondes en 
affichant LIL, puis affiche le menu lilo comme d'habitude.


  Bizarre. Normalement si Lilo s'arrête sur LIL, c'est qu'il n'arrive
pas à lire le disque (erreur physique ou mauvaise configuration), mais
il est censé s'arrêter là. Le fait qu'il reprenne signifierait qu'il
retrouve finalement ses petits ?

Apparemment oui...


  Pas de problème de disque ?
Non, je n'ai jamais eu le moindre problème de disque (j'en ai d'ailleurs 
 deux, l'autre n'est monté et démonté que pour des sauvegardes 
automatiques).




Au lancement de etch, le boot s'arrête encore 5 secondes en affichant 
bios check bypassed, puis démarre enfin.


  Message introuvable dans LILO ou les sources du noyau 2.6.18.
  Tu es sûr du message ?

Certain.
Il affiche d'abord une ou deux lignes (le bla bla classique), puis le 
message, puis ca défile.


Mystère, mystère.

Re: attente au boot

[Jean-Yves F. Barbier]

Le jeudi 1 mars 2007 12:25, Sylvain Sauvage a écrit :
 Alexandre Gerussi, mercredi 28 février 2007, 20:14:25 CET

  Bonjour,

 'jour,

  je suis passé à Etch avec noyau 2.6.18 et lilo 22.6.1.
 
  Depuis, au démarrage, l'ordinateur s'arrête environ 30 secondes en
  affichant LIL, puis affiche le menu lilo comme d'habitude.

   Bizarre. Normalement si Lilo s'arrête sur LIL, c'est qu'il n'arrive
 pas à lire le disque (erreur physique ou mauvaise configuration), mais
 il est censé s'arrêter là. Le fait qu'il reprenne signifierait qu'il
 retrouve finalement ses petits ?
   Pas de problème de disque ?

Ca ressemble effectivement à un PB de HD
j'étais tombé sur un HD Samsung qui semblait fonctionner correctement,
mais qui inexplicablement mettais jusqu'à plus d'une minute pour lire
certains fichiers (SANS affichage d'erreur!!)
jusqu'à ce que je le formatte avec une vérification destructrice, et là
le 1er et le dernier tiers formattaient à vitesse normale; par contre
le tiers central à mis presque 8H à completer, toujours SANS erreurs
affichées (même avec mke2fs)

  Au lancement de etch, le boot s'arrête encore 5 secondes en affichant
  bios check bypassed, puis démarre enfin.

   Message introuvable dans LILO ou les sources du noyau 2.6.18.
   Tu es sûr du message ?

   Au pif, un antivirus dans le BIOS ?

non, ça donnerait un erreur lors de l'execution de lilo

par contre, ça pourrait être un virus BIOS (pour vérifier, il
suffit de reflasher le BIOS à la dernière version stable, venant
du site officiel, PAS d'ailleurs)

attente au boot

[Alexandre Gerussi]

Bonjour,

je suis passé à Etch avec noyau 2.6.18 et lilo 22.6.1.

Depuis, au démarrage, l'ordinateur s'arrête environ 30 secondes en 
affichant LIL, puis affiche le menu lilo comme d'habitude.
Au lancement de etch, le boot s'arrête encore 5 secondes en affichant 
bios check bypassed, puis démarre enfin.


Je n'avais jamais remarqué ce message auparavant.

Y a-t-il un moyen d'éviter cette attente de 30 secondes ?
Comme lilo est un point sensible pour le démarrage, je préfère avoir un 
avis éclairé avant de magouiller n'importe quoi.



Merci d'avance.