Jessie 8.2 : écran noir lors du boot (résolu)

Support Debian
#1

Bonjour,

Je suis en multiple boot Win 7 premium - Debian Jessie 8.2 stable 64 bits - Archlinux 64 bits et Linux Mint 17.1 64 bits sur un PC fait main avec une carte Asus, CPU Intel, 4 Go RAM DDR3 et une carte graphique nVidia GT 630 (gérée par le module “nouveau”.

Le choix de l’OS à lancer se fait via le Grub2 de Linux Mint 17.1.

Le problème que je rencontre avec Jessie est que lors du démarrage, les trois ou 4 premières lignes habituelles s’affichent en blanc sur fonds noir (la 4ème ligne indique que jessie-home est propre) puis ces lignes disparaissent et je reste face à un écran totalement noir avec un underscore immobile dans le coin supérieur gauche.

Cela dure une quinzaine de secondes puis je vois le témoin d’activation du pavé numérique s’allumer, preuve que le boot se poursuit.

Quelque secondes plus tard, mon écran de connexion graphique apparaît demandant mon login et mon password.

Encore quelques secondes et mon bureau s’affiche et tout fonctionne parfaitement.

J’ai supprimé le mot “quiet” dans grub.cfg au bout de la ligne du kernel mais ça n’y change rien car voici ce que j’obtiens :

okapi@Jessie82:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=2ea6dfb5-a126-4dc5-ba9d-136e6bdadd1b ro quiet

Si je supprime manuellement ce “quiet” lors de l’affichage de grub (touche “e” pour éditer la cmdline) puis F10 pour démarrer le boot, alors les lignes de boot défilent normalement.

lspci renvoie ceci :

okapi@Jessie82:~$ lspci 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5) 00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5) 00:1c.4 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation H61 Express Chipset Family LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05) 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 630] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio Controller (rev a1) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09) 04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller 05:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01) okapi@Jessie82:~$

lsudb renvoie ceci :

okapi@Jessie82:~$ lsusb Bus 004 Device 004: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash Card Reader Bus 004 Device 003: ID 1bcf:0007 Sunplus Innovation Technology Inc. Optical Mouse Bus 004 Device 005: ID 03f0:5311 Hewlett-Packard OfficeJet 6300 Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 003: ID 03f0:2b17 Hewlett-Packard LaserJet 1020 Bus 002 Device 002: ID 046a:0021 Cherry GmbH CyMotion Expert Combo Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub okapi@Jessie82:~$

A toutes fins : lsmod :

okapi@Jessie82:~$ lsmod Module Size Used by usblp 17274 0 cfg80211 405538 0 binfmt_misc 16949 1 nfsd 263032 2 auth_rpcgss 51211 1 nfsd oid_registry 12419 1 auth_rpcgss nfs_acl 12511 1 nfsd nfs 188136 0 lockd 83389 2 nfs,nfsd fscache 45542 1 nfs sunrpc 237402 6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl x86_pkg_temp_thermal 12951 0 intel_powerclamp 17159 0 intel_rapl 17356 0 coretemp 12820 0 kvm_intel 139116 0 kvm 388635 1 kvm_intel crc32_pclmul 12915 0 ghash_clmulni_intel 12978 0 joydev 17063 0 aesni_intel 151423 0 eeepc_wmi 12600 0 snd_hda_codec_hdmi 45118 4 asus_wmi 22781 1 eeepc_wmi sparse_keymap 12818 1 asus_wmi rfkill 18867 2 cfg80211,asus_wmi aes_x86_64 16719 1 aesni_intel lrw 12757 1 aesni_intel gf128mul 12970 1 lrw iTCO_wdt 12831 0 iTCO_vendor_support 12649 1 iTCO_wdt glue_helper 12695 1 aesni_intel ablk_helper 12572 1 aesni_intel snd_hda_codec_realtek 67127 1 snd_hda_codec_generic 63181 1 snd_hda_codec_realtek cryptd 14516 3 ghash_clmulni_intel,aesni_intel,ablk_helper snd_hda_intel 26327 10 snd_hda_controller 26646 1 snd_hda_intel snd_hda_codec 104463 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller mei_me 17941 0 lpc_ich 20768 0 mei 74977 1 mei_me snd_hwdep 13148 1 snd_hda_codec mfd_core 12601 1 lpc_ich pcspkr 12595 0 battery 13356 0 psmouse 99249 0 serio_raw 12849 0 i2c_i801 16965 0 shpchp 31121 0 snd_pcm 88662 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller snd_timer 26614 1 snd_pcm snd 65244 28 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel soundcore 13026 2 snd,snd_hda_codec evdev 17445 22 processor 28221 0 fuse 83350 11 parport_pc 26300 1 ppdev 16782 0 lp 17074 0 parport 35749 3 lp,ppdev,parport_pc autofs4 35529 2 usb_storage 56215 0 ext4 473802 2 crc16 12343 1 ext4 mbcache 17171 1 ext4 jbd2 82413 1 ext4 hid_generic 12393 0 usbhid 44460 0 hid 102264 2 hid_generic,usbhid sg 29973 0 sd_mod 44356 9 sr_mod 21903 0 crc_t10dif 12431 1 sd_mod cdrom 47424 1 sr_mod crct10dif_generic 12581 0 crct10dif_pclmul 13387 1 crct10dif_common 12356 3 crct10dif_pclmul,crct10dif_generic,crc_t10dif crc32c_intel 21809 0 ahci 33291 7 libahci 27158 1 ahci libata 177457 2 ahci,libahci nouveau 1122419 2 scsi_mod 191405 5 sg,usb_storage,libata,sd_mod,sr_mod mxm_wmi 12515 1 nouveau i2c_algo_bit 12751 1 nouveau drm_kms_helper 49210 1 nouveau ehci_pci 12512 0 xhci_hcd 148881 0 ttm 77862 1 nouveau ehci_hcd 69837 1 ehci_pci drm 249955 5 ttm,drm_kms_helper,nouveau r8169 68262 0 mii 12675 1 r8169 usbcore 195340 6 usblp,usb_storage,ehci_hcd,ehci_pci,usbhid,xhci_hcd i2c_core 46012 5 drm,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau usb_common 12440 1 usbcore wmi 17339 3 mxm_wmi,nouveau,asus_wmi fan 12681 0 thermal 17559 0 video 18096 2 nouveau,asus_wmi thermal_sys 27642 6 fan,video,intel_powerclamp,thermal,processor,x86_pkg_temp_thermal button 12944 1 nouveau okapi@Jessie82:~$

Quant à dmidecode, il est tellement long que je vais passer sous Arch pour l’envoyer via pastebin dans quelque minutes.

A+

EDIT : Voici le lien pastebin qui reprend le résultat de dmidecode :

http://pastebin.archlinux.fr/1652958

#2

Bonjour,

Pour voir une belle animation (splashscreen) à la place d’un curseur clignotant, installer plymouth.

$ sudo apt install plymouth-x11

Puis configurer GRUB en modifiant le fichier /etc/default/grub pour y mettre cette ligne

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Mettre à jour les fichiers de GRUB

$ sudo update-grub

Eventuellement, modifier le thème de plymouth (lines est le thème de Debian 8 )

$ sudo plymouth-set-default-theme -R lines

Redémarrer pour vérifier le bon fonctionnement.

#3

Bonjour et merci pour ta réponse.

Malheureusement, elle n’a aucun effet sur le comportement bizarre du boot de Jessie.

Quand je dis qu’elle a aucun effet, je dois y mettre deux bémols :

D’une part, le temps durant lequel l’écran est noir est sensiblement plus long qu’auparavant
D’autre part, j’arrive directement sur mon bureau sans passer par l’écran de connexion graphique

Note que ça fait plusieurs jours que je m’échine à résoudre ce problème (sur un autre site) avec l’aide d’un geek qui a toujours eu réponse à tous les problèmes que j’ai rencontrés sur divers OS linux.

Ce qui est agaçant, c’est que Jessie est la seule distro à avoir ce comportement : Archlinux monte clairement le défilé des lignes du boot et j’ai réussi à installer un beau splash screen sur Linux Mint 17.1.

Quoi qu’il en soit, je te remercie de t’être penché(e ?) sur mon cas.

Cordialement,

#4

bonjour Mimile , on s’est déjà croisé sur arch :wink:

il ne faut pas modifié (quiet) directement sur [mono]grub.cfg[/mono] mais agir sur [mono]/etc/default/grub[/mono] puis faire un [mono]updade-grub[/mono] pour que ce soit pris en compte

#5

J’en perds mon latinux !

plymouth n’a aucun rapport, à ma connaissance, avec la connexion automatique.

#6

[quote=“Mimile”]Le problème que je rencontre avec Jessie est que lors du démarrage, les trois ou 4 premières lignes habituelles s’affichent en blanc sur fonds noir (la 4ème ligne indique que jessie-home est propre) puis ces lignes disparaissent et je reste face à un écran totalement noir avec un underscore immobile dans le coin supérieur gauche.

Cela dure une quinzaine de secondes puis je vois le témoin d’activation du pavé numérique s’allumer, preuve que le boot se poursuit.

Quelque secondes plus tard, mon écran de connexion graphique apparaît demandant mon login et mon password.[/quote]
Lors du démarrage en mode normal, sans l’option [mono]quiet[/mono], Jessie n’affiche rien de plus que ce que tu décris. Par contre chez moi il ne reste pas 15 secondes sur un écran noir.

Je vois deux moments où l’affichage change après le dernier message :

  • Lors du chargement du module qui pilote le GPU, le module “nouveau” dans ton cas, ce qui active le framebuffer en console à la place du mode VGA de base 80x25. Mais chez moi cela n’efface pas l’écran, cela change juste la taille de l’affichage.
  • Lors du lancement de l’interface graphique X.org. A ce moment l’écran se vide avec juste le curseur en haut mais cela ne devrait pas durer 15 secondes, quelques secondes tout au plus.

Tu peux regarder dans les logs du noyau (commande dmesg) et de X.org /var/log/Xorg.0.log pour voir s’il y a quelque chose qui peut expliquer cette durée chez toi.

Il faut modifier le bon fichier grub.cfg. Si tu as fais un multiboot direct depuis le GRUB d’un autre système (Mint), c’est probablement le grub.cfg de celui-ci qu’il faut modifier pour que ce soit pris en compte. Mais comme cela a été souligné, il n’est pas recommandé de modifier directement grub.cfg car ce fichier est souvent (re-)généré automatiquement lors de certaines opérations comme l’installation ou la mise à jour d’un noyau, la reconstruction de l’initramfs suite à l’installation ou la mise à jour de certains paquets… Toute modification directe sera donc écrasée.

Jusqu’à l’apparition de l’écran de connexion graphique ? Cela prend-il le même temps qu’avec [mono]quiet[/mono], ou moins de temps ? Normalement cette option ne devrait pas modifier sensiblement le temps de démarrage (ou l’augmenter s’il y a plus de texte qui défile).

#7

Bonjour,

@ Misaine : il est vrai que je me souviens que nous nous sommes déjà rencontrés sur d’autres forum(s - fora ?).

Depuis plus de huit jours, je cherche désespérément à me débarrasser de cet satané écran noir (durant lequel le boot se poursuit) et ce avec l’aide de Logicien qui est un véritable geek car il ne m’a jamais laissé sans me donner une solution aux problèmes rencontrés.

Sans vouloir te vexer, à force de faire des tentatives tous azimuts, celle que tu m’as données a été expérimentées dans tous les sens sans résultat.

Je te remercie néanmoins d’avoir voulu me venir en aide.

@ PascalHambourg :

[code]Lors du démarrage en mode normal, sans l’option quiet, Jessie n’affiche rien de plus que ce que tu décris. Par contre chez moi il ne reste pas 15 secondes sur un écran noir.

Je vois deux moments où l’affichage change après le dernier message :

  • Lors du chargement du module qui pilote le GPU, le module “nouveau” dans ton cas, ce qui active le framebuffer en console à la place du mode VGA de base 80x25. Mais chez moi cela n’efface pas l’écran, cela change juste la taille de l’affichage.
  • Lors du lancement de l’interface graphique X.org. A ce moment l’écran se vide avec juste le curseur en haut mais cela ne devrait pas durer 15 secondes, quelques secondes tout au plus.
    [/code]

Ca se passe à peu près comme tu le décris : peut-être me trompé-je sur les durées mais j’avoue ne les avoir jamais vraiment chronométrées.

Description du processus de démarrage :

Sur fonds d’écran noir, la 1ère ligne en gros caractères (VGA) apparaît indiquant quelque chose comme loading … please wait et ce pendant très peu de temps.

En effet, presqu’aussitôt, ré-apparition de la première ligne suivie de deux autres lignes le tout affiché en caractères plus petits et bien nets ; il y est question de Jessie-root clean et jessie-home propre.

Ca dure une ou deux secondes et l’affichage des trois lignes devient moins net tout en gardant le même format.

Quelques secondes plus tard, tout disparaît (l’écran est totalement noir) mis à part un underscore dans le coin supérieur gauche.

Cela dure - à vue de nez - 15 secondes et je vois le témoin d’activation du pavé numérique s’allumer, ce qui laisse à penser que le boot se poursuit.

Encore quelques secondes et enfin mon écran de connexion graphique apparaît sur fonds gris ; confirmation que je suis bien l’utilisateur affiché (j’en suis le seul), encodage de mon mot de passe et encore quelques secondes plus tard - enfin - mon bureau Cinnamon.

Petite précision : à l’origine, j’ai installé Jessie 8.2 avec gnome. Comme je trouvais cela plutôt moche, j’ai installé Cinnamon qui, d’un point de vue du confort d’utilisation et de l’esthétique surpasse nettement Gnome.

Enfin, il est exact que le grub de démarrage est celui de Linux Mint 17.1.

Je vais le modifier et reviens dès que possible après les tests.

A+

EDIT : Hourra ! bien vu, le problème provenait effectivement du grub du Linux Mint 17.1 :023

J’ai ajouté “splash” derrière “quiet” dans la ligne du kernel et au redémarrage de Jessie, j’ai un bel écran bleu avec des lignes circulaires tournantes et le mot “DEBIAN 8” au bas de l’écran.

Après quelques secondes, apparition de mon écran de connexion graphique !

Problème résolu donc, sauf que le splash ne me plaît pas vraiment.

Je sais qu’il y a une commande qui donne la liste des splash disponibles (j’avais installé solar) sur ma précédente version de Jessie 8.0 mais comme j’avais commis la gaffe de la passer en sid (ce qui me posait un tas de problèmes), je l’ai remplacée par Jessie 8.2.

En tout cas, GRAND MERCI car ce problème commençait vraiment à m’obséder.

Cordialement,

EDIT : Est-il possible de remplacer l’horrible fonds gris de l’écran de connexion par une image plus agréable ?

Linux Mint, par exemple, déroule un diaporama de belles photos en attendant que je valide mon mot de passe.
Possible sous Debian ou pas ?

#8

Concernant l’enjolivement (“eye candy”) du boot ou du gestionnaire de connexion, dont je me moque éperdument, ce n’est pas moi qui pourrais te répondre.

Chargement du module “nouveau” et activation du framebuffer console en haute résolution.

Je suppose que c’est le changement de la police de caractère (plus fine, ce qui peut la rendre moins nette selon l’écran) par console-setup.

[quote=“Mimile”]Quelques secondes plus tard, tout disparaît (l’écran est totalement noir) mis à part un underscore dans le coin supérieur gauche.

Cela dure - à vue de nez - 15 secondes et je vois le témoin d’activation du pavé numérique s’allumer, ce qui laisse à penser que le boot se poursuit.[/quote]
Donc l’écran noir et ce délai se produit pendant l’initialisation de l’interface graphique X ou le lancement du gestionnaire de connexion. Il y a peut-être une explication pour le délai dans les logs de Xorg.

Je n’ai pas compris le rapport entre le GRUB de Mint et ce long écran noir sous Debian, mais tant mieux si les explications fournies t’ont permis de résoudre le problème. Concernant la configuration de GRUB 2 avec plusieurs distributions, quelques explications supplémentaires.

Sur chaque distribution, [mono]update-grub[/mono] regénère son propre fichier de configuration /boot/grub/grub.cfg à partir des valeurs définies dans /etc/default/grub et des scripts présents dans /etc/grub.d/. Chaque script a un rôle particulier : par exemple 10_linux crée des entrées dans le menu pour les noyaux de la distribution, 30_os-prober détecte les autres systèmes et distributions présents (si le paquet os-prober est installé) et leur créée des entrées, 40_custom ajoute son propre contenu (à personnaliser si besoin) à grub.cfg et 41_custom provoque l’inclusion dynamique lors du boot (pas lors de update-grub, contrairement à 40_custom) du fichier /boot/grub/custom.cfg s’il existe.

A noter que lors de la création des entrées pour un noyau Linux d’une autre distribution détectée par os-prober, les options du noyau présentes dans le fichier /boot/grub/grub.cfg de cette distribution sont reprises. Par conséquent, le processus pour modifier une option devrait être le suivant :

  1. Modification de la variable GRUB_CMDLINE_LINUX_DEFAULT (pour le démarrage normal seulement) ou GRUB_CMDLINE_LINUX (pour le démarrage en mode normal et recovery) dans le fichier /etc/default/grub de la distribution à laquelle le changement doit s’appliquer.
  2. Exécution de [mono]update-grub[/mono] dans cette distribution pour regénérer son grub.cfg.
  3. Exécution de [mono]update-grub[/mono] dans la distribution à laquelle appartient le GRUB principal afin de regénérer son grub.cfg pour tenir compte des modifications du grub.cfg de la distribution secondaire.

Un autre approche consiste à non pas intégrer les noyaux des autres distributions dans le menu de démarrage du GRUB principal, mais à chaîner chaque GRUB secondaire dans le GRUB principal. Cela peut se faire en désactivant os-prober (en le désinstallant ou en ajoutant GRUB_DISABLE_OS_PROBER=“true” dans /etc/default/grub) et en créant manuellement des entrées de chaînage pour chaque chargeur secondaire dans /boot/grub/custom.cfg ou /etc/grub.d/40_custom. En mode BIOS/legacy, on peut utiliser la commande [mono]chainloader[/mono] pour chaîner le secteur d’amorce (PBR) de la partition de boot du système cible, ou bien la commande [mono]multiboot[/mono] pour amorcer directement le fichier core.img d’un autre GRUB (dans /boot/grub ou /boot/grub/i386-pc/ selon la version), ou la commande [mono]ntldr[/mono] pour amorcer le chargeur /ntldr ou /bootmgr de Windows. En mode EFI, on utilise [mono]chainloader[/mono] pour amorcer un autre chargeur EFI qui se trouve dans la même partition système EFI ou dans une autre partition système EFI.

#9

Waaww !

Tu en connais un bout sur grub et ses possibilités.

En ce qui me concerne, je n’ai aucune formation en informatique et ce que je sais, je l’ai appris sur le tas.

Donc, puisque pour le moment tout fonctionne correctement, je laisserai les choses en place car je dois bien avouer que je n’utilise principalement que W7 pour le boulot et Archlinux parce que, d’une part, j’y ai consacré beaucoup de temps et que s’agissant d’une rolling release, elle est toujours à jour (et ce qui ne gâte rien, elle est d’une grande stabilité car je n’ai jamais dû la réinstaller.

En tout cas, merci d’avoir mis le doigt sur le fait que le grub n’était pas celui généré par Jessie, ce qui m’a permis de résoudre un problème qui me cassait les pieds depuis des jours.

Encore merci.

Cordialement