probleme menu grub

J'ajoute que ce problème est apparu il y a deux ou trois mois quand
Linux Mint est passée de version 19.2 à 19.3

Oh! .... Là il y a eu une grosse glissade, en fait
je pensais à ces partitions de boot qui peuvent se
remplir et déborder avec des kernels qu'on y installe,

parfois sans discernement, et ceci n'a rien à voir
avec 12 partitions bootables dont chacune installe
son grub sur /dev/sdbX.

La paralysie est en effect provoquée par cet effet de miroir
qui grossit le fichier de grub, je savais qu'il fallait éviter
que ce fichier grossisse en empêchant les partitions de faire
le update-grub

J'ai donc copié le /etc/default/grub de mon disque interne sur
l'externe. J'ai bien sûr mis la même splashimage sur le disque externe.

J'ai relancé un grub-mkconfig et un update-grub (en étant bien sûr
démarré depuis le disque externe, pas envie de chrooter)

J'ai redémarré sur le disque externe : le problème reste exactement le
même, pas de splashimage, affichage du menu caractère par caractère et
impossible de sélectionner une entrée de menu donc obligé de booter sur
la première...

Le 14-03-2020, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :

Il y a des particularités dans ce fichier /etc/default/grub ?

Aucune, si ce n'est que l'appel à la splashimage "mint_by_pulicoti.tga"
GRUB_BACKGROUND=/boot/grub/mint_by_pulicoti.tga, que j'ai changé la
fonte et que j'ai décommenté la ligne "GRUB_TERMINAL=console" hier soir

/dev/sdb (hd1) disque externe (DOS/MBR)
/dev/sdb3 (hd1,msdos3) UUID:329bdb-9666-4082-abb4-a0d3c12a8e1f racine
disque externe

/dev/sda (hd0) disque interne (GPT)
/dev/sda5 (hd0,gpt5) UUIDj82fdd9-9c51-4034-9cfe-bffd9822b5fd racine
interne

Oui.

Dans ce cas, il y a un petit défaut : en amorçage BIOS, le disque de
boot quel qu'il soit est systématiquement désigné (hd0). Or grub.cfg
contient "--hint-bios=hd1,msdos3" comme aide pour la recherche de la
partition racine du disque externe, ce qui a pour conséquence que GRUB
va d'abord rechercher la partition :sur l'autre disque. Ça peut le
ralentir un peu. Pour l'éviter, il faut forcer la bonne correspondance
entre les disques et leur désignation (hdX) dans /boot/grub/device.map.

Ah...
Comment forcer cette « bonne correspondance » ?
(pas de fichier /boot/grub/device.map sur ce disque externe)

Comment le disque externe est-il connecté ? USB 2, USB 3, eSATA... ?

USB3.

Booter avec grub en console ne m'a pas paru vraiment plus rapide : une
fois connecté et capable d'évaluer la charge machine, je peux tout juste
noter une légère baisse, 500 % au lieu de 700 %

Le 14/03/2020 à 16:07, Lulu a écrit :

Le 14-03-2020, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :

Il y a des particularités dans ce fichier /etc/default/grub ?

Aucune, si ce n'est que l'appel à la splashimage "mint_by_pulicoti.tga"
GRUB_BACKGROUND=/boot/grub/mint_by_pulicoti.tga, que j'ai changé la
fonte et que j'ai décommenté la ligne "GRUB_TERMINAL=console" hier soir

Autant tout remettre par défaut, y compris la police.

/dev/sdb (hd1) disque externe (DOS/MBR)
/dev/sdb3 (hd1,msdos3) UUID:329bdb-9666-4082-abb4-a0d3c12a8e1f racine
disque externe

/dev/sda (hd0) disque interne (GPT)
/dev/sda5 (hd0,gpt5) UUIDj82fdd9-9c51-4034-9cfe-bffd9822b5fd racine
interne

Oui.

Dans ce cas, il y a un petit défaut : en amorçage BIOS, le disque de
boot quel qu'il soit est systématiquement désigné (hd0). Or grub.cfg
contient "--hint-bios=hd1,msdos3" comme aide pour la recherche de la
partition racine du disque externe, ce qui a pour conséquence que GRUB
va d'abord rechercher la partition :sur l'autre disque. Ça peut le
ralentir un peu. Pour l'éviter, il faut forcer la bonne correspondance
entre les disques et leur désignation (hdX) dans /boot/grub/device.map.

Ah...
Comment forcer cette « bonne correspondance » ?
(pas de fichier /boot/grub/device.map sur ce disque externe)

Tu peux le créer manuellement, ou le générer avec grub-mkdevicemap puis
le modifier.

Comment le disque externe est-il connecté ? USB 2, USB 3, eSATA... ?

USB3.

Je demande car j'ai déjà constaté de grosses lenteurs de GRUB avec des
disques ou clés connectés en USB 2 sur certaines machines, probablement
liées au BIOS. Pas d'expérience en USB 3.

Booter avec grub en console ne m'a pas paru vraiment plus rapide : une
fois connecté et capable d'évaluer la charge machine, je peux tout juste
noter une légère baisse, 500 % au lieu de 700 %

Minute ! On parle de quoi, là ? De lenteur de GRUB ou de lenteur du
système Linux qui démarre ensuite ? La seule chose qui peut influer sur
le système Linux est les paramètres de la ligne de commande du noyau
spécifiés dans GRUB_CMDLINE_LINUX_*. En revanche, ça n'a aucune
influence sur GRUB lui-même.

Sur tes conseils, j'inverse les deux lignes pour avoir :
(hd0) /dev/disk/by-id/usb-TOSHIBA_External_USB_3.0_20161227009043F-0:0
(hd1) /dev/disk/by-id/ata-SAMSUNG_MZNTY256HDHP-000L2_S304NB0H717596

Je relance un update-grub

suivi d'un grub-install /dev/sdb et reboote.

Booter avec grub en console ne m'a pas paru vraiment plus rapide : une
fois connecté et capable d'évaluer la charge machine, je peux tout juste
noter une légère baisse, 500 % au lieu de 700 %

Minute ! On parle de quoi, là ? De lenteur de GRUB ou de lenteur du
système Linux qui démarre ensuite ? La seule chose qui peut influer sur
le système Linux est les paramètres de la ligne de commande du noyau
spécifiés dans GRUB_CMDLINE_LINUX_*. En revanche, ça n'a aucune
influence sur GRUB lui-même.

Le système, une fois démarré n'est pas lent. Quelques minutes après le
boot, la charge machine est normale.
Mais, en dehors du fait que le grub graphique me fait défiler les
caractères un à un, il faut deux minutes (chrono à l'appui) entre la
sélection du noyau et le splashscreen qui me permet de me connecter à ma
session puis encore une bonne minute pour que mon bureau s'affiche.
Et ceci même si je boote après avoir repassé le grub en non-graphique.

Je viens de refaire un boot avec grub graphique : à nouveau affichage
des caractères un par un et impossibilité de sélectionner une autre
entrée que la première.

J'ai posté une première réponse avec mon dmesg, mais il n'apparaît
pas...

Le 16/03/2020 à 01:06, Lulu a écrit :

Sur tes conseils, j'inverse les deux lignes pour avoir :
(hd0) /dev/disk/by-id/usb-TOSHIBA_External_USB_3.0_20161227009043F-0:0
(hd1) /dev/disk/by-id/ata-SAMSUNG_MZNTY256HDHP-000L2_S304NB0H717596

Je relance un update-grub

Ok.

suivi d'un grub-install /dev/sdb et reboote.

Je ne pense pas que réinstaller GRUB soit utile. Quand le contenu de
/boot/grub est dans une partition "simple" (système de fichiers sans
LVM, RAID, chiffrement...) sur le même disque que la boot image et la
core image de GRUB, cette dernière enregistre le numéro de cette
partition donc ne cherche pas d'UUID et n'a pas besoin d'aide pour la
numérotation des disques.

Booter avec grub en console ne m'a pas paru vraiment plus rapide :
une fois connecté et capable d'évaluer la charge machine, je peux
tout juste noter une légère baisse, 500 % au lieu de 700 %

Minute ! On parle de quoi, là ? De lenteur de GRUB ou de lenteur
du système Linux qui démarre ensuite ? La seule chose qui peut
influer sur le système Linux est les paramètres de la ligne de
commande du noyau spécifiés dans GRUB_CMDLINE_LINUX_*. En
revanche, ça n'a aucune influence sur GRUB lui-même.

Le système, une fois démarré n'est pas lent. Quelques minutes après
le boot, la charge machine est normale.
Mais, en dehors du fait que le grub graphique me fait défiler les
caractères un à un, il faut deux minutes (chrono à l'appui) entre la
sélection du noyau et le splashscreen qui me permet de me connecter à
ma session puis encore une bonne minute pour que mon bureau
s'affiche.
Et ceci même si je boote après avoir repassé le grub en
non-graphique.

Ça peut venir du temps nécessaire au chargement par GRUB de l'image
du noyau (vmlinuz) et de l'initramfs (initrd), qui sont d'assez gros
fichiers, en faisant appel aux fonctions d'accès disque du BIOS qui
peuvent être assez lentes. Une fois le noyau actif en revanche,
celui-ci utilise ses propres pilotes pour accéder aux disques.

As-tu comparé les temps de démarrage des deux installations depuis
les deux GRUB, soit 4 mesures ?

Je viens de refaire un boot avec grub graphique : à nouveau affichage
des caractères un par un et impossibilité de sélectionner une autre
entrée que la première.

Et avec GRUB en console ? Est-ce qu'il est possible de sélectionner une
autre entrée de menu que celle par défaut ?

J'ai posté une première réponse avec mon dmesg, mais il n'apparaît
pas...

Si en pièce jointe, elle a dû être supprimée par ton serveur. En
principe, les binaires sont interdits dans fr.*.

Le 16/03/2020 à 01:06, Lulu a écrit :

Sur tes conseils, j'inverse les deux lignes pour avoir :
(hd0) /dev/disk/by-id/usb-TOSHIBA_External_USB_3.0_20161227009043F-0:0
(hd1) /dev/disk/by-id/ata-SAMSUNG_MZNTY256HDHP-000L2_S304NB0H717596

Je relance un update-grub

Ok.

suivi d'un grub-install /dev/sdb et reboote.

Je ne pense pas que réinstaller GRUB soit utile. Quand le contenu de
/boot/grub est dans une partition "simple" (système de fichiers sans
LVM, RAID, chiffrement...) sur le même disque que la boot image et la
core image de GRUB, cette dernière enregistre le numéro de cette
partition donc ne cherche pas d'UUID et n'a pas besoin d'aide pour la
numérotation des disques.

Booter avec grub en console ne m'a pas paru vraiment plus rapide :
une fois connecté et capable d'évaluer la charge machine, je peux
tout juste noter une légère baisse, 500 % au lieu de 700 %

Minute ! On parle de quoi, là ? De lenteur de GRUB ou de lenteur
du système Linux qui démarre ensuite ? La seule chose qui peut
influer sur le système Linux est les paramètres de la ligne de
commande du noyau spécifiés dans GRUB_CMDLINE_LINUX_*. En
revanche, ça n'a aucune influence sur GRUB lui-même.

Le système, une fois démarré n'est pas lent. Quelques minutes après
le boot, la charge machine est normale.
Mais, en dehors du fait que le grub graphique me fait défiler les
caractères un à un, il faut deux minutes (chrono à l'appui) entre la
sélection du noyau et le splashscreen qui me permet de me connecter à
ma session puis encore une bonne minute pour que mon bureau
s'affiche.
Et ceci même si je boote après avoir repassé le grub en
non-graphique.

Ça peut venir du temps nécessaire au chargement par GRUB de l'image
du noyau (vmlinuz) et de l'initramfs (initrd), qui sont d'assez gros
fichiers, en faisant appel aux fonctions d'accès disque du BIOS qui
peuvent être assez lentes. Une fois le noyau actif en revanche,
celui-ci utilise ses propres pilotes pour accéder aux disques.

As-tu comparé les temps de démarrage des deux installations depuis
les deux GRUB, soit 4 mesures ?

Je viens de refaire un boot avec grub graphique : à nouveau affichage
des caractères un par un et impossibilité de sélectionner une autre
entrée que la première.

Et avec GRUB en console ? Est-ce qu'il est possible de sélectionner une
autre entrée de menu que celle par défaut ?

J'ai posté une première réponse avec mon dmesg, mais il n'apparaît
pas...

Si en pièce jointe, elle a dû être supprimée par ton serveur. En
principe, les binaires sont interdits dans fr.*.

Le 16/03/2020 à 01:06, Lulu a écrit :

Sur tes conseils, j'inverse les deux lignes pour avoir :
(hd0) /dev/disk/by-id/usb-TOSHIBA_External_USB_3.0_20161227009043F-0:0
(hd1) /dev/disk/by-id/ata-SAMSUNG_MZNTY256HDHP-000L2_S304NB0H717596

Je relance un update-grub

Ok.

suivi d'un grub-install /dev/sdb et reboote.

Je ne pense pas que réinstaller GRUB soit utile. Quand le contenu de
/boot/grub est dans une partition "simple" (système de fichiers sans
LVM, RAID, chiffrement...) sur le même disque que la boot image et la
core image de GRUB, cette dernière enregistre le numéro de cette
partition donc ne cherche pas d'UUID et n'a pas besoin d'aide pour la
numérotation des disques.

Booter avec grub en console ne m'a pas paru vraiment plus rapide :
une fois connecté et capable d'évaluer la charge machine, je peux
tout juste noter une légère baisse, 500 % au lieu de 700 %

Minute ! On parle de quoi, là ? De lenteur de GRUB ou de lenteur
du système Linux qui démarre ensuite ? La seule chose qui peut
influer sur le système Linux est les paramètres de la ligne de
commande du noyau spécifiés dans GRUB_CMDLINE_LINUX_*. En
revanche, ça n'a aucune influence sur GRUB lui-même.

Le système, une fois démarré n'est pas lent. Quelques minutes après
le boot, la charge machine est normale.
Mais, en dehors du fait que le grub graphique me fait défiler les
caractères un à un, il faut deux minutes (chrono à l'appui) entre la
sélection du noyau et le splashscreen qui me permet de me connecter à
ma session puis encore une bonne minute pour que mon bureau
s'affiche.
Et ceci même si je boote après avoir repassé le grub en
non-graphique.

Ça peut venir du temps nécessaire au chargement par GRUB de l'image
du noyau (vmlinuz) et de l'initramfs (initrd), qui sont d'assez gros
fichiers, en faisant appel aux fonctions d'accès disque du BIOS qui
peuvent être assez lentes. Une fois le noyau actif en revanche,
celui-ci utilise ses propres pilotes pour accéder aux disques.

As-tu comparé les temps de démarrage des deux installations depuis
les deux GRUB, soit 4 mesures ?

Je viens de refaire un boot avec grub graphique : à nouveau affichage
des caractères un par un et impossibilité de sélectionner une autre
entrée que la première.

Et avec GRUB en console ? Est-ce qu'il est possible de sélectionner
une autre entrée de menu que celle par défaut ?

J'ai posté une première réponse avec mon dmesg, mais il n'apparaît
pas...

Si en pièce jointe, elle a dû être supprimée par ton serveur. En
principe, les binaires sont interdits dans fr.*.

dmesg_MinTosh500 dmesg_MinTosh500: ASCII text