BOOT : Ecran noir au démarrage pendant plus de 3 minutes

fg92 · Le 22/04/2020, à 13:10

Bonjour.

J'ai donc mis en oeuvre la procédure décrite dans mon précédent post (#24), en l'améliorant en peu.
Elle n'est effectivement sans doute pas très orthodoxe, mais elle a fonctionné : le délai entre le BIOS et GRUB s'est bien réduit et est redevenu tout à fait acceptable.

Comme je ne connaissais pas vraiment le comportement de GRUB, je l'ai d'abord quelque peu étudié sur un autre ordinateur.
J'ai acquis une conviction sur l'origine de mon problème :
- ce n'est pas mes réglages qui ont causé ce fichier /boot/grub/grub.cfg énorme et ce délai énorme associé,
- mais c'est simplement GRUB qui s'est marché sur les pieds au moment d'un sudo update-grub.

Voici donc la procédure que j'ai employée :

0- Avant tout, je rappelle que j'ai 4 Linux sur mon ordinateur.

1- J'ai choisi le Linux dont GRUB utiliserait (dans un premier temps) le fichier /boot/grub/grub.cfg.
Je me suis loggé à ce Linux (on l'appellera Linux1).
J'ai exécuté la commande sudo grub-install /dev/sdL (avec L étant la lettre de mon disque dur : soit a pour moi).

2- Je me suis loggé à chacun des 3 autres Linux.
Et à chaque fois, j'ai renommé (en root) le fichier /boot/grub/grub.cfg en /boot/grub/grub.cfg.old.

3- Je me suis reloggé à Linux1.
Là aussi (et seulement à ce moment-là), j'ai renommé (en root) le fichier /boot/grub/grub.cfg en /boot/grub/grub.cfg.old.
Puis, j'ai configuré comme je le souhaite le fichier /etc/default/grub (cela est optionnel).
Et enfin, j'ai exécuté la commande sudo update-grub.

4- Pour parfaire le lancement des 3 autres Linux (et ainsi "supprimer" les lignes affichées à l'écran lors du démarrage de ces 3 autres Linux), j'ai fait pour chacun de ces 3 Linux :
* me loger au Linux ;
* configurer le fichier /etc/default/grub (optionnel) ;
* exécuter la commande sudo update-grub.

5- Et enfin, je suis retourné sous Linux1.
Et j'ai ré-exécuté la commande sudo update-grub.

Et ainsi, la lancement de GRUB s'est rétabli comme il l'était avant ce délai énorme (près de 20 minutes, avec un /boot/grub/grub.cfg d'un peu plus de 2 Mo...).

geole · Le 22/04/2020, à 13:51

Bonjour
C'est effectivement une solution... Mais tu continues de refuser de déactiver la recherche des O.S au point 4. (sudo chmod -x /etc/grub.d/30*) . Donc tu as réamorcé le piège.
Regarde un peu sous Linux1 le contenu du fichier /boot/grub/grub.cfg. Tu vas voir, il commence à "radoter"

Donc il faut que tu continues en bootant sur chacun des trois autres O.S. et faire les deux commandes

sudo chmod -x /etc/grub.d/30
sudo update-grub

Puis lorsque cela sera fait pour les trois, retourner au premier et faire seulement

sudo update-grub

Tu pourras regarder la taille du nouveau fichier. Elle sera enfin normale.

Dernière modification par geole (Le 22/04/2020, à 14:04)

fg92 · Le 22/04/2020, à 14:24

Merci geole pour ces précisions.

Mais, avant de faire ce que tu proposes à la fin de ton post précédent #27 pour compléter ma procédure de mon post #26, je souhaiterais comprendre quelques choses :
- que fait exactement la commande sudo chmod -x /etc/grub.d/30* ?
- une fois que j'aurai passer toutes ces commandes complémentaires, que va-t-il arriver le jour où un des 3 Linux (autres que Linux1) exécutera automatiquement un sudo update-grub et un sudo grub-install /dev/sda ? mon ordinateur ne risque-t-il pas de devenir automatiquement bancal ? si oui, dans quelles mesures ?

geole · Le 22/04/2020, à 14:45

Pour savoir ce que fait une commande, la faire précéder un mot man
Dans ce contexte, tu vas supprimer l'autorisation d'exécution de tous les programmes commençant par 30 du répertoire /etc/grub-d , il y en a deux dont le fameux os-prober qui qui va regarder ce qu'il y a ailleurs.

Si un de ces fichus O.S. s'autorise à écraser la structure de boot, il n'y a que lui qui pourra booter. Lorsqu'il aura booté, il faut que tu l'autorises à aller voir ailleurs en rétablissant son autorisation de récupérer les autres.

sudo chmod +x /etc/grub.d/30*
sudo update-grub

évidemment, dans celui qui n'est plus le chef, il faut que tu le lui dises

sudo chmod -x /etc/grub.d/30*
sudo update-grub

et que tu reviennes dans le nouveau chef pour qu'il récupère quelque chose de correct

sudo update-grub

Dernière modification par geole (Le 22/04/2020, à 16:34)

ar barzh paour · Le 22/04/2020, à 16:19

EDIT : j'ai répondu au post 25 , je n'avais pas vu qu'il y avait une 2ème page !!!

le dernière version est ici
https://forum.ubuntu-fr.org/viewtopic.p … #p21675743
il faut que je modifie le post du lien précédent

Dernière modification par ar barzh paour (Le 22/04/2020, à 16:29)

fg92 · Le 04/05/2020, à 11:55

Bonjour ar barzh paour.

Merci pour ce script.
Quand faut-il le lancer ? Est-ce régulièrement ?

Babdu89 · Le 04/05/2020, à 14:22

Bonjour.

Ha bon, le bug de Grub version 2,0 et suivantes, toujours pas résolu, depuis 2017?.
Est-il déclaré au moins? . Je ne sais pas faire çà.

À l'époque, ayant compris ce qu'il se passe, ma parade est la suivante;

https://forum.ubuntu-fr.org/viewtopic.p … #p21675801

Ou bien, l'utilisation du script du sujet dont tu parles.

Quand faut-il le lancer ? Est-ce régulièrement ?

_Normalement à chaque mise à jour du grub du système maître.

_Mais aussi, lorsqu'il y a mise à jour de tous les systèmes avec changement de version du noyau, il y a maj de Grub. Donc il faut finir par les maj systèmes des Os, par l'Os maître pour la prise en compte des changements de versions de noyau des autres Os.
Important , depuis les dernières versions de Ubuntu qui nettoie les versions du noyau, avec les maj système suivantes, pour ne garder que les deux dernières. Si on ne fait pas un peut de "maintenance" de nos systèmes, on se retrouve avec un système qui n'a pas la bonne version de noyau dans le menuentry qui le concerne dans le Grub de l'Os Maître. Il ne peut pas démarrer.

_Lorsque il y a aussi une maj de Grub; maj mineur, sans changement de version, maj majeur, avec changement de version, il y a maj de grub.

_Et pour ne rien arrangé, c'est rare, mais çà arrive. J'ai fais des maj majeures de Grub, qui ont vu une réinstallation de Grub dans un des Os autres que l'Os maître. Alors dans ce cas on change d'Os maître, pour ne rien arrangé.

_Et aussi à chaque nouvelle installation, qui prend aussi la place d'Os maître de la config.

En fait à chaque mise à jour de Grub, il y a exécution de la commande "os-prober" , commande qui recherche tous les systèmes installés dans nos config, pour les proposer au menu Grub. C'est çà qui allonge le fichier grub.cfg de l'Os maître depuis lequel on démarre.
Lors des maj de Grub, cette commande est lancée par le script /etc/grub.d/30_os-prober
Il faut donc empêcher l'exécution de ce script dans tous les Os non maîtres de la config. Et n'autoriser l'exécution de ce script que dans l'Os maître, pour avoir au menu Grub la proposition de tous les Os de la config.

Sauf que l'on à un souci, lorsque il y a changement de l'Os maître. Il faut réinstaller Grub dans l'Os maître que l'on avait choisi au départ.

Je me demande bien si ce bug sera résolu un jour.

@+. Babdu89 .

Dernière modification par Babdu89 (Le 04/05/2020, à 14:59)

fg92 · Le 04/05/2020, à 17:33

Merci Babdu89 pour tous ces détails.

En clair, tous les contournements connus sont à répéter de façon régulière.
Il y a pas de contournement perenne.

Pour ma part, mon contournement préféré est l'utilisation du paramètre GRUB_DISABLE_OS_PROBER dans le fichier /etc/default/grub.
En positionnant ce paramètre à la valeur true, on obtient le même résultat qu'avec la commande sudo chmod -x /etc/grub.d/30*.
Et, personnellement, cela me paraît plus orthodoxe.

ar barzh paour · Le 05/05/2020, à 09:45

fg92 a écrit :

Quand faut-il le lancer ? Est-ce régulièrement ?

oui le traitement n'a lieu que si on le lance manuellement , il y aurait bien moyen de le rendre automatique mais je ne préfère pas ....
personnellement je le lance dès qu'il y a une mise à jour de grub (soit par le système soit manuellement
voilà le menu grub que j'obtiens

U20-04 : Ubuntu
U16.04-P10-64b : Ubuntu 16.04.6 LTS (16.04) (sur /dev/sda10)
M16.04-a12-64b : Ubuntu 16.04.5 LTS (16.04) (sur /dev/sda12) 
U18.04-a2-64b : Ubuntu 18.04.4 LTS (18.04) (sur /dev/sda2)
U14.04-a5-64b : Ubuntu 14.04.5 LTS (14.04) (sur /dev/sda5) 
U16.04-a7-32b : Ubuntu 16.04.5 LTS (16.04) (sur /dev/sda7) 
X16.04-a9-32b : Ubuntu 16.04.6 LTS (16.04) (sur /dev/sda9) 
Windows NT/2000/XP (sur /dev/sdb1)
U16.04-b5-64b : Ubuntu 16.04.6 LTS (16.04) (sur /dev/sdb5)
Windows NT/2000/XP (sur /dev/sdc1)
U18-04-c11 : Ubuntu 18.04.4 LTS (18.04) (sur /dev/sdc11)
gnome : Ubuntu 17.04 (17.04) (sur /dev/sdc9)
U18.04-d1 : Ubuntu 18.04.4 LTS (18.04) (sur /dev/sdd1)
18-4-EFI : Ubuntu 18.04.4 LTS (18.04) (sur /dev/sde2) 
lancer mes isos" {

ça fait un moment que je veux re-écrire ce script mais je n'arrive pas à m'y mettre (il me donne satisfaction) (attention quand même je n'ai pas pu tester toutes les configurations
à la fin du traitement , le script demande si l'on veut remplacer le grub par celui qui a été modifié
on peur répondre oui ou non , si on répond non , on peut analyser le résultat et faire le remplacement manuellement
un conseil : avoir à disposition un moyen de remettre le grub d'origine en cas d'anomalie

Dernière modification par ar barzh paour (Le 05/05/2020, à 09:52)

ar barzh paour · Le 05/05/2020, à 09:57

@fg92
si tu considères comme résolue ta discussion
transforme le titre en modifiant le post #1
ajoute [Résolu] au début du titre
BOOT : Ecran noir au démarrage pendant plus de 3 minutes
devient
[Résolu] BOOT : Ecran noir au démarrage pendant plus de 3 minutes
merci

Dernière modification par ar barzh paour (Le 05/05/2020, à 09:59)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 22/04/2020, à 13:10

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#27 Le 22/04/2020, à 13:51

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#28 Le 22/04/2020, à 14:24

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#29 Le 22/04/2020, à 14:45

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#30 Le 22/04/2020, à 16:19

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#31 Le 04/05/2020, à 11:55

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#32 Le 04/05/2020, à 14:22

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#33 Le 04/05/2020, à 17:33

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#34 Le 05/05/2020, à 09:45

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

#35 Le 05/05/2020, à 09:57

Re : BOOT : Ecran noir au démarrage pendant plus de 3 minutes

Pied de page des forums