Re: longue attente au boot [résolu]
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]
@ 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 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]
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]
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]
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]
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]
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]
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 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]
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
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
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
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
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: uncachab
Re: attente au boot
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)
Re: attente au boot
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
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
attente au boot
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.