Il ne s'agit pas d'un problème de démarrage : j'ai installé grub sur un
disque externe et je peux booter sur ce disque externe :
Sortie de 'dpkg -l | grep grub' :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
ii grub-common 2.02-2ubuntu8.14 amd64 GRand Unified Bootloader (common files)
ii grub-gfxpayload-lists 0.7 amd64 GRUB gfxpayload blacklist
ii grub-pc 2.02-2ubuntu8.14 amd64 GRand Unified Bootloader, version 2 (PC/BIOS version)
ii grub-pc-bin 2.02-2ubuntu8.14 amd64 GRand Unified Bootloader, version 2 (PC/BIOS binaries)
ii grub2 2.02-2ubuntu8.14 amd64 GRand Unified Bootloader, version 2 (dummy package)
ii grub2-common 2.02-2ubuntu8.14 amd64 GRand Unified Bootloader (common files for version 2)
/bin/bash: q : commande introuvable
ii grub2-theme-mint 1.2.2 all Grub2 theme for Linux Mint
8<-----------8<---------8<----------8<----------8<----------8<----------8<
Non...
Le problème est qu'il m'est impossible de sélectionner autre chose que
la première entrée...
Déjà, très bizarre : le menu de grub s'affiche caractère par caractère
(au début, j'ai pensé que c'était un effet voulu, pour singer
l'informatique des années 1975 - 1980 ;-)
Mais dès que je tape la touche "flèche bas" pour aller sélectionner une
des 5 ou 6 lignes du menu, ledit menu se redessine, caractère par
caractère, et aucune ligne n'est "highlightée"...
Bref : ce menu est inutilisable. (Et j'aimerais bien que ce menu me
permette de booter sur le disque interne du PC sur lequel ce disque
externe est branché, me servant ainsi de démarrage de secours).
D'autant plus bizarre que la même version de GrUB est installée sur le
disque interne et ne pose aucun problème.
Il s'agit d'un disque externe sur lequel une Linux Mint 19.3 (tricia) à
jour est installée.
Si jamais ça devait aidé à trouvé le problème : sur ce disque, le
splashscreen de GRUB a toujours été affiché en 16 (ou 256 ?) couleurs :
très moche alors que sur toutes mes autres installations de GRuB, c'est
du 32 bits.
En 25 lignes Pascal Hambourg a écrit dans news:5e75ed52$0$9915$ le samedi, 21 mars 2020 à 11:32:48 :
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI.
Cette précision est d'importance capitale.
Ubuntu, comme les autres distributions qui supportent le secure boot (openSUSE, Debian, je suppose Fedora...), a acheté à Microsoft une clé signée avec la clé de Microsoft qui est reconnue par défaut par tous les firmwares UEFI.
Et il y en a sans doute d'autres, RedHat a du prendre aussi le train.
Pas forcément une bonne nouvelle, car les kernels qu'on compile soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du noyau pour ajouter des pilotes non libres non inclus en standard (Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...), ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas ..... dyrmak -- ¿ De quién fue la culpa ? No sé de la suerte ++++ --- ++++ Linux operating system ++++ --- ++++
En 25 lignes Pascal Hambourg a écrit
dans news:5e75ed52$0$9915$426a34cc@news.free.fr
le samedi, 21 mars 2020 à 11:32:48 :
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI.
Cette précision est d'importance capitale.
Ubuntu, comme les autres distributions qui supportent le secure boot
(openSUSE, Debian, je suppose Fedora...), a acheté à Microsoft une clé
signée avec la clé de Microsoft qui est reconnue par défaut par tous les
firmwares UEFI.
Et il y en a sans doute d'autres, RedHat a du prendre aussi le train.
Pas forcément une bonne nouvelle, car les kernels qu'on compile
soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du
noyau pour ajouter des pilotes non libres non inclus en standard
(Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...),
ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI
qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas .....
dyrmak
--
¿ De quién fue la culpa ? No sé de la suerte
++++ --- ++++
Linux operating system
++++ --- ++++
En 25 lignes Pascal Hambourg a écrit dans news:5e75ed52$0$9915$ le samedi, 21 mars 2020 à 11:32:48 :
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI.
Cette précision est d'importance capitale.
Ubuntu, comme les autres distributions qui supportent le secure boot (openSUSE, Debian, je suppose Fedora...), a acheté à Microsoft une clé signée avec la clé de Microsoft qui est reconnue par défaut par tous les firmwares UEFI.
Et il y en a sans doute d'autres, RedHat a du prendre aussi le train.
Pas forcément une bonne nouvelle, car les kernels qu'on compile soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du noyau pour ajouter des pilotes non libres non inclus en standard (Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...), ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas ..... dyrmak -- ¿ De quién fue la culpa ? No sé de la suerte ++++ --- ++++ Linux operating system ++++ --- ++++
Pascal Hambourg
Le 22/03/2020 à 02:12, dyrmak a écrit :
En 25 lignes Pascal Hambourg a écrit dans news:5e75ed52$0$9915$ le samedi, 21 mars 2020 à 11:32:48 :
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI.
Cette précision est d'importance capitale.
Oui. Le secure boot n'est qu'une fonctionnalité optionnelle (pour le moment) de l'amorçage UEFI. L'amorçage UEFI sans secure boot ne nécessite pas de chaîne d'amorçage signée.
Pas forcément une bonne nouvelle, car les kernels qu'on compile soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du noyau pour ajouter des pilotes non libres non inclus en standard (Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...), ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Que veux-tu dire ?
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas .....
Mais si, j'ai vu des machines dont le setup contenait des options pour manipuler les clés secure boot.
Le 22/03/2020 à 02:12, dyrmak a écrit :
En 25 lignes Pascal Hambourg a écrit
dans news:5e75ed52$0$9915$426a34cc@news.free.fr
le samedi, 21 mars 2020 à 11:32:48 :
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI.
Cette précision est d'importance capitale.
Oui. Le secure boot n'est qu'une fonctionnalité optionnelle (pour le
moment) de l'amorçage UEFI. L'amorçage UEFI sans secure boot ne
nécessite pas de chaîne d'amorçage signée.
Pas forcément une bonne nouvelle, car les kernels qu'on compile
soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du
noyau pour ajouter des pilotes non libres non inclus en standard
(Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...),
ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Que veux-tu dire ?
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI
qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas .....
Mais si, j'ai vu des machines dont le setup contenait des options pour
manipuler les clés secure boot.
En 25 lignes Pascal Hambourg a écrit dans news:5e75ed52$0$9915$ le samedi, 21 mars 2020 à 11:32:48 :
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI.
Cette précision est d'importance capitale.
Oui. Le secure boot n'est qu'une fonctionnalité optionnelle (pour le moment) de l'amorçage UEFI. L'amorçage UEFI sans secure boot ne nécessite pas de chaîne d'amorçage signée.
Pas forcément une bonne nouvelle, car les kernels qu'on compile soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du noyau pour ajouter des pilotes non libres non inclus en standard (Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...), ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Que veux-tu dire ?
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas .....
Mais si, j'ai vu des machines dont le setup contenait des options pour manipuler les clés secure boot.
Lulu
Le 21-03-2020, Pascal Hambourg a écrit :
Le 17/03/2020 à 00:55, Lulu a écrit :
Le 16-03-2020, Pascal Hambourg a écrit :
As-tu comparé les temps de démarrage des deux installations depuis les deux GRUB, soit 4 mesures ?
Sur le disque externe, grub graphique ou non, les temps sont grosso-modo ceux que j'indique dans le message auquel tu réponds: 2 minutes pour avoir le splashscreen de connexion puis une grosse minute pour que le bureau s'affiche. Quand je boote sur mon disque interne (un SSD il est vrai) avec le grub 'graphique' qui marche sans problème, il s'écoule 24 secondes avant que j'obtienne le splashscreen qui me permet de saisir mon mot de passe : 12 secondes plus tard, mon bureau s'affiche (ceci avec un grub "graphique") et la charge machine, juste après que mon bureau soit affiché ne vaut que 136%. Si je teste avec un grub 'non-graphique' (GRUB_TERMINAL=console), les temps sont les mêmes à la seconde près.
Je n'ai pas dû être assez clair : les deux GRUB dont je parle ne sont pas le même GRUB tantôt en mode texte et tantôt en mode graphique mais le GRUB du SSD interne et le GRUB du disque externe USB. Les 4 démarrages à mesurer sont les suivants :
0K, j'ai compris :
GRUB interne -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12 secondes pour l'affichage du bureau.
Menu texte ou graphique, peu importe du moment que ça permet de sélectionner le système à démarrer (notamment dans le 3e cas).
J'observe que le démarrage est quasi-exactement cinq fois plus rapide depuis mon disque interne (en SSD) que depuis mon disque externe (en USB3), mais mon petit doigt me dit que ça a plus à voir avec une mis-configuration du grub qu'avec la technologie du disque dur.
Les résultats des tests croisés suggérés ci-dessus devraient permettre de confirmer ou infirmer cette hypothèse.
Tu en concluerais donc que ça n'est pas grub qui pose problème ?
Le 21-03-2020, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Le 17/03/2020 à 00:55, Lulu a écrit :
Le 16-03-2020, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
As-tu comparé les temps de démarrage des deux installations depuis
les deux GRUB, soit 4 mesures ?
Sur le disque externe, grub graphique ou non, les temps sont grosso-modo
ceux que j'indique dans le message auquel tu réponds: 2 minutes pour
avoir le splashscreen de connexion puis une grosse minute pour que le
bureau s'affiche.
Quand je boote sur mon disque interne (un SSD il est vrai) avec le grub
'graphique' qui marche sans problème, il s'écoule 24 secondes avant que
j'obtienne le splashscreen qui me permet de saisir mon mot de passe : 12
secondes plus tard, mon bureau s'affiche (ceci avec un grub "graphique")
et la charge machine, juste après que mon bureau soit affiché ne vaut
que 136%.
Si je teste avec un grub 'non-graphique' (GRUB_TERMINAL=console), les
temps sont les mêmes à la seconde près.
Je n'ai pas dû être assez clair : les deux GRUB dont je parle ne sont
pas le même GRUB tantôt en mode texte et tantôt en mode graphique mais
le GRUB du SSD interne et le GRUB du disque externe USB. Les 4
démarrages à mesurer sont les suivants :
0K, j'ai compris :
GRUB interne -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour
l'affichage du bureau.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes
pour le bureau (avec une charge de 600 à 700 %)
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour
l'affichage du bureau.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12
secondes pour l'affichage du bureau.
Menu texte ou graphique, peu importe du moment que ça permet de
sélectionner le système à démarrer (notamment dans le 3e cas).
J'observe que le démarrage est quasi-exactement cinq fois plus rapide
depuis mon disque interne (en SSD) que depuis mon disque externe (en
USB3), mais mon petit doigt me dit que ça a plus à voir avec une
mis-configuration du grub qu'avec la technologie du disque dur.
Les résultats des tests croisés suggérés ci-dessus devraient permettre
de confirmer ou infirmer cette hypothèse.
Tu en concluerais donc que ça n'est pas grub qui pose problème ?
As-tu comparé les temps de démarrage des deux installations depuis les deux GRUB, soit 4 mesures ?
Sur le disque externe, grub graphique ou non, les temps sont grosso-modo ceux que j'indique dans le message auquel tu réponds: 2 minutes pour avoir le splashscreen de connexion puis une grosse minute pour que le bureau s'affiche. Quand je boote sur mon disque interne (un SSD il est vrai) avec le grub 'graphique' qui marche sans problème, il s'écoule 24 secondes avant que j'obtienne le splashscreen qui me permet de saisir mon mot de passe : 12 secondes plus tard, mon bureau s'affiche (ceci avec un grub "graphique") et la charge machine, juste après que mon bureau soit affiché ne vaut que 136%. Si je teste avec un grub 'non-graphique' (GRUB_TERMINAL=console), les temps sont les mêmes à la seconde près.
Je n'ai pas dû être assez clair : les deux GRUB dont je parle ne sont pas le même GRUB tantôt en mode texte et tantôt en mode graphique mais le GRUB du SSD interne et le GRUB du disque externe USB. Les 4 démarrages à mesurer sont les suivants :
0K, j'ai compris :
GRUB interne -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12 secondes pour l'affichage du bureau.
Menu texte ou graphique, peu importe du moment que ça permet de sélectionner le système à démarrer (notamment dans le 3e cas).
J'observe que le démarrage est quasi-exactement cinq fois plus rapide depuis mon disque interne (en SSD) que depuis mon disque externe (en USB3), mais mon petit doigt me dit que ça a plus à voir avec une mis-configuration du grub qu'avec la technologie du disque dur.
Les résultats des tests croisés suggérés ci-dessus devraient permettre de confirmer ou infirmer cette hypothèse.
Tu en concluerais donc que ça n'est pas grub qui pose problème ?
Pascal Hambourg
Le 23/03/2020 à 08:01, Lulu a écrit :
GRUB interne -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12 secondes pour l'affichage du bureau.
Le résultat du dernier test est assez inattendu : c'est le plus rapide pourtant dans la configuration a priori la plus défavorable. S'il ne s'agit pas d'une erreur de manipulation, la seule explication qui me vient est une différence dans les paramètres passés par les deux GRUB au noyau du système externe.
Le 23/03/2020 à 08:01, Lulu a écrit :
GRUB interne -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour
l'affichage du bureau.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes
pour le bureau (avec une charge de 600 à 700 %)
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour
l'affichage du bureau.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12
secondes pour l'affichage du bureau.
Le résultat du dernier test est assez inattendu : c'est le plus rapide
pourtant dans la configuration a priori la plus défavorable.
S'il ne s'agit pas d'une erreur de manipulation, la seule explication
qui me vient est une différence dans les paramètres passés par les deux
GRUB au noyau du système externe.
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12 secondes pour l'affichage du bureau.
Le résultat du dernier test est assez inattendu : c'est le plus rapide pourtant dans la configuration a priori la plus défavorable. S'il ne s'agit pas d'une erreur de manipulation, la seule explication qui me vient est une différence dans les paramètres passés par les deux GRUB au noyau du système externe.
dyrmak
En 34 lignes Pascal Hambourg a écrit dans news:5e771cb4$0$5877$ le dimanche, 22 mars 2020 à 09:07:15 :
Cette précision est d'importance capitale.
Oui. Le secure boot n'est qu'une fonctionnalité optionnelle (pour le moment) de l'amorçage UEFI. L'amorçage UEFI sans secure boot ne nécessite pas de chaîne d'amorçage signée.
Tout cela évolue étape par étape, d'abord le bios, puis après bios+uefi, puis bios+uefi+boot sécurisé optionnel....
Pas forcément une bonne nouvelle, car les kernels qu'on compile soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du noyau pour ajouter des pilotes non libres non inclus en standard (Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...), ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Que veux-tu dire ?
Avant je compilais un petit module pour faire apparaître un message personnalisé, son chargement était silencieux et après ont commencé les messages "this module taint the kernel" et autres alarmes ... C'est pénible de voir ça quand on a d'autres soucis pour faire fonctionner un périphérique qui s'obstine à ne pas fonctionner, avec les modules de virtualbox ou de nvidia il y avait festival d'alarmes à tel point que parfois je me demande si tout cela va finir par s'arranger, enfin bon, je ne sais pas si on arrive à saisir mon semblant d'explication....
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas .....
Mais si, j'ai vu des machines dont le setup contenait des options pour manipuler les clés secure boot.
J'aimerais avoir un jour une de ces machines là. Mais nous entrons dans une nouvelle ère d'adaptation, avec ma propre clé comment pourrais-je la faire accepter par le kernel pour qu'il me laisse tranquillement compiler ce que je veux? Signer ses modules c'est une chose, mais j'ai l'impression que ce n'est pas si simple que ça .... dyrmak -- ¿ Cómo era aquello del rayo verde ? ++++ --- ++++ Linux operating system ++++ --- ++++
En 34 lignes Pascal Hambourg a écrit
dans news:5e771cb4$0$5877$426a74cc@news.free.fr
le dimanche, 22 mars 2020 à 09:07:15 :
Cette précision est d'importance capitale.
Oui. Le secure boot n'est qu'une fonctionnalité optionnelle (pour le
moment) de l'amorçage UEFI. L'amorçage UEFI sans secure boot ne
nécessite pas de chaîne d'amorçage signée.
Tout cela évolue étape par étape, d'abord le bios, puis après bios+uefi,
puis bios+uefi+boot sécurisé optionnel....
Pas forcément une bonne nouvelle, car les kernels qu'on compile
soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du
noyau pour ajouter des pilotes non libres non inclus en standard
(Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...),
ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Que veux-tu dire ?
Avant je compilais un petit module pour faire
apparaître un message personnalisé, son chargement était
silencieux et après ont commencé les messages "this module taint the
kernel" et autres alarmes ... C'est pénible de voir ça quand
on a d'autres soucis pour faire fonctionner un périphérique qui
s'obstine à ne pas fonctionner, avec les modules de virtualbox ou de
nvidia il y avait festival d'alarmes à tel point que parfois je me
demande si tout cela va finir par s'arranger, enfin bon, je ne sais
pas si on arrive à saisir mon semblant d'explication....
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI
qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas .....
Mais si, j'ai vu des machines dont le setup contenait des options pour
manipuler les clés secure boot.
J'aimerais avoir un jour une de ces machines là. Mais nous entrons
dans une nouvelle ère d'adaptation, avec ma propre clé comment
pourrais-je la faire accepter par le kernel pour qu'il me laisse
tranquillement compiler ce que je veux? Signer ses modules c'est
une chose, mais j'ai l'impression que ce n'est pas si simple
que ça ....
dyrmak
--
¿ Cómo era aquello del rayo verde ?
++++ --- ++++
Linux operating system
++++ --- ++++
En 34 lignes Pascal Hambourg a écrit dans news:5e771cb4$0$5877$ le dimanche, 22 mars 2020 à 09:07:15 :
Cette précision est d'importance capitale.
Oui. Le secure boot n'est qu'une fonctionnalité optionnelle (pour le moment) de l'amorçage UEFI. L'amorçage UEFI sans secure boot ne nécessite pas de chaîne d'amorçage signée.
Tout cela évolue étape par étape, d'abord le bios, puis après bios+uefi, puis bios+uefi+boot sécurisé optionnel....
Pas forcément une bonne nouvelle, car les kernels qu'on compile soi-même sont ou seraient hors jeu ....;[
Non seulement les noyaux mais aussi les modules compilés en dehors du noyau pour ajouter des pilotes non libres non inclus en standard (Nvidia, VirtualBox, certains pilotes pour cartes réseaux/wifi...), ainsi que le chargeur d'amorçage (GRUB).
Ce serait ôte-toi d'là que je m'y mette!?
Que veux-tu dire ?
Avant je compilais un petit module pour faire apparaître un message personnalisé, son chargement était silencieux et après ont commencé les messages "this module taint the kernel" et autres alarmes ... C'est pénible de voir ça quand on a d'autres soucis pour faire fonctionner un périphérique qui s'obstine à ne pas fonctionner, avec les modules de virtualbox ou de nvidia il y avait festival d'alarmes à tel point que parfois je me demande si tout cela va finir par s'arranger, enfin bon, je ne sais pas si on arrive à saisir mon semblant d'explication....
Pour que cela fonctionne avec le secure boot, il faut un firmware UEFI qui permette d'importer sa propre clé avec laquelle on signe ses binaires.
Et ce firmware n'existe pas .....
Mais si, j'ai vu des machines dont le setup contenait des options pour manipuler les clés secure boot.
J'aimerais avoir un jour une de ces machines là. Mais nous entrons dans une nouvelle ère d'adaptation, avec ma propre clé comment pourrais-je la faire accepter par le kernel pour qu'il me laisse tranquillement compiler ce que je veux? Signer ses modules c'est une chose, mais j'ai l'impression que ce n'est pas si simple que ça .... dyrmak -- ¿ Cómo era aquello del rayo verde ? ++++ --- ++++ Linux operating system ++++ --- ++++
Lulu
Le 23-03-2020, Pascal Hambourg a écrit :
Le 23/03/2020 à 08:01, Lulu a écrit :
GRUB interne -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
Ça, c'est bon.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
Ça, c'est bon
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
Ça, c'est bon.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12 secondes pour l'affichage du bureau.
Le résultat du dernier test est assez inattendu : c'est le plus rapide pourtant dans la configuration a priori la plus défavorable. S'il ne s'agit pas d'une erreur de manipulation, la seule explication qui me vient est une différence dans les paramètres passés par les deux GRUB au noyau du système externe.
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
Je vais regarder tout de même les paramètres passés au noyau.
Le 23-03-2020, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Le 23/03/2020 à 08:01, Lulu a écrit :
GRUB interne -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour
l'affichage du bureau.
Ça, c'est bon.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes
pour le bureau (avec une charge de 600 à 700 %)
Ça, c'est bon
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour
l'affichage du bureau.
Ça, c'est bon.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12
secondes pour l'affichage du bureau.
Le résultat du dernier test est assez inattendu : c'est le plus rapide
pourtant dans la configuration a priori la plus défavorable.
S'il ne s'agit pas d'une erreur de manipulation, la seule explication
qui me vient est une différence dans les paramètres passés par les deux
GRUB au noyau du système externe.
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes
pour le bureau (avec une charge de 600 à 700 %)
Je vais regarder tout de même les paramètres passés au noyau.
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
Ça, c'est bon.
GRUB interne -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
Ça, c'est bon
GRUB externe -> système interne
splashscreen de connexion après 24 secondes puis encore 12 secondes pour l'affichage du bureau.
Ça, c'est bon.
GRUB externe -> système externe
splashscreen de connexion après 22 ou 23 secondes puis encore 10/12 secondes pour l'affichage du bureau.
Le résultat du dernier test est assez inattendu : c'est le plus rapide pourtant dans la configuration a priori la plus défavorable. S'il ne s'agit pas d'une erreur de manipulation, la seule explication qui me vient est une différence dans les paramètres passés par les deux GRUB au noyau du système externe.
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
Je vais regarder tout de même les paramètres passés au noyau.
Pascal Hambourg
Le 25/03/2020 à 20:10, Lulu a écrit :
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
Donc le résultat est le même quel que soit le GRUB qui amorce le système, et la logique est respectée : le démarrage sur SSD interne est beaucoup plus rapide que sur disque dur externe en USB. La différence de vitesse entre les deux supports ne suffirait-elle pas à expliquer l'écart, même si cela n'exclut pas qu'une différence dans les paramètres du noyau des deux système puisse aussi jouer un rôle ?
Le 25/03/2020 à 20:10, Lulu a écrit :
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes
pour le bureau (avec une charge de 600 à 700 %)
Donc le résultat est le même quel que soit le GRUB qui amorce le
système, et la logique est respectée : le démarrage sur SSD interne est
beaucoup plus rapide que sur disque dur externe en USB. La différence de
vitesse entre les deux supports ne suffirait-elle pas à expliquer
l'écart, même si cela n'exclut pas qu'une différence dans les paramètres
du noyau des deux système puisse aussi jouer un rôle ?
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
Donc le résultat est le même quel que soit le GRUB qui amorce le système, et la logique est respectée : le démarrage sur SSD interne est beaucoup plus rapide que sur disque dur externe en USB. La différence de vitesse entre les deux supports ne suffirait-elle pas à expliquer l'écart, même si cela n'exclut pas qu'une différence dans les paramètres du noyau des deux système puisse aussi jouer un rôle ?
Lulu
Le 25-03-2020, Pascal Hambourg a écrit :
Le 25/03/2020 à 20:10, Lulu a écrit :
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
Donc le résultat est le même quel que soit le GRUB qui amorce le système, et la logique est respectée : le démarrage sur SSD interne est beaucoup plus rapide que sur disque dur externe en USB. La différence de vitesse entre les deux supports ne suffirait-elle pas à expliquer l'écart, même si cela n'exclut pas qu'une différence dans les paramètres du noyau des deux système puisse aussi jouer un rôle ?
Effectivement, c'est la conclusion que j'en tire, même si le rapport entre le temps de démarrage sur le disque externe par rapport au disque interne, soit 120s / 24s = 5 me semble un peu énorme. Mais à l'origine, je venais ici pour essayer de comprendre pourquoi le grub graphique du disque externe (pourtant configuré exactement comme celui du disque interne) affichait les caractères un par un, avec l'impossibilité de sélectionner une autre ligne que la première puisque la frappe de la moindre touche relance le dessin, caractère par caractère, du menu. Mais bon... Puisque passer ce grub en mode texte a résolu l'impossibilité de sélectionner les autres lignes de grub, je vais laisser tomber cette histoire de dessin des caractères un par un. C'est pas que j'aime laisser en plan une incompréhension, mais l'enjeu ne justifie plus l'investissement. Merci pour ton aide dans cette investigation.
Le 25-03-2020, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Le 25/03/2020 à 20:10, Lulu a écrit :
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse
minutes pour le bureau (avec une charge de 600 à 700 %)
Donc le résultat est le même quel que soit le GRUB qui amorce le
système, et la logique est respectée : le démarrage sur SSD interne
est beaucoup plus rapide que sur disque dur externe en USB. La
différence de vitesse entre les deux supports ne suffirait-elle pas à
expliquer l'écart, même si cela n'exclut pas qu'une différence dans
les paramètres du noyau des deux système puisse aussi jouer un rôle ?
Effectivement, c'est la conclusion que j'en tire, même si le rapport entre
le temps de démarrage sur le disque externe par rapport au disque
interne, soit 120s / 24s = 5 me semble un peu énorme.
Mais à l'origine, je venais ici pour essayer de comprendre pourquoi le
grub graphique du disque externe (pourtant configuré exactement comme
celui du disque interne) affichait les caractères un par un, avec
l'impossibilité de sélectionner une autre ligne que la première puisque
la frappe de la moindre touche relance le dessin, caractère par
caractère, du menu.
Mais bon...
Puisque passer ce grub en mode texte a résolu l'impossibilité de
sélectionner les autres lignes de grub, je vais laisser tomber cette
histoire de dessin des caractères un par un.
C'est pas que j'aime laisser en plan une incompréhension, mais l'enjeu
ne justifie plus l'investissement.
Cette dernière mesure est une erreur de ma part. Il fallait lire :
GRUB externe -> système externe
splashscreen de connexion après 2 minutes puis encore une grosse minutes pour le bureau (avec une charge de 600 à 700 %)
Donc le résultat est le même quel que soit le GRUB qui amorce le système, et la logique est respectée : le démarrage sur SSD interne est beaucoup plus rapide que sur disque dur externe en USB. La différence de vitesse entre les deux supports ne suffirait-elle pas à expliquer l'écart, même si cela n'exclut pas qu'une différence dans les paramètres du noyau des deux système puisse aussi jouer un rôle ?
Effectivement, c'est la conclusion que j'en tire, même si le rapport entre le temps de démarrage sur le disque externe par rapport au disque interne, soit 120s / 24s = 5 me semble un peu énorme. Mais à l'origine, je venais ici pour essayer de comprendre pourquoi le grub graphique du disque externe (pourtant configuré exactement comme celui du disque interne) affichait les caractères un par un, avec l'impossibilité de sélectionner une autre ligne que la première puisque la frappe de la moindre touche relance le dessin, caractère par caractère, du menu. Mais bon... Puisque passer ce grub en mode texte a résolu l'impossibilité de sélectionner les autres lignes de grub, je vais laisser tomber cette histoire de dessin des caractères un par un. C'est pas que j'aime laisser en plan une incompréhension, mais l'enjeu ne justifie plus l'investissement. Merci pour ton aide dans cette investigation.
Pascal Hambourg
Le 28/03/2020 à 20:16, Lulu a écrit :
Le 25-03-2020, Pascal Hambourg a écrit :
Donc le résultat est le même quel que soit le GRUB qui amorce le système, et la logique est respectée : le démarrage sur SSD interne est beaucoup plus rapide que sur disque dur externe en USB. La différence de vitesse entre les deux supports ne suffirait-elle pas à expliquer l'écart, même si cela n'exclut pas qu'une différence dans les paramètres du noyau des deux système puisse aussi jouer un rôle ?
Effectivement, c'est la conclusion que j'en tire, même si le rapport entre le temps de démarrage sur le disque externe par rapport au disque interne, soit 120s / 24s = 5 me semble un peu énorme.
Je ne trouve pas, au contraire. Les SSD ont un temps d'accès négligeable et peuvent atteindre des débits de plusieurs centaines de Mo/s. Les disques durs externes ont généralement un format 2,5" et une vitesse de rotation basse (~5000 t/mn) et sont optimisés pour une faible consommation plutôt que pour la performance, ce qui se traduit par un temps d'accès et et un débit plutôt médiocres. Tu peux comparer leurs débits séquentiels avec hdparm -t.
Mais à l'origine, je venais ici pour essayer de comprendre pourquoi le grub graphique du disque externe (pourtant configuré exactement comme celui du disque interne) affichait les caractères un par un, avec l'impossibilité de sélectionner une autre ligne que la première puisque la frappe de la moindre touche relance le dessin, caractère par caractère, du menu.
Je n'ai pas d'explication, seulement des hypothèses. 1) Si GRUB doit faire des accès disque pour redessiner l'écran (je ne vois pas bien pourquoi mais on ne sait jamais), la lenteur de l'accès au disque externe (due à ses performances intrinsèques et/ou au pilote du BIOS) pourrait jouer. 2) Le mode graphique est-il le même pour les deux GRUB ? à vérifier avec vbeinfo ou videoinfo dans le shell de GRUB. 3) L'image de fond est-elle la la même pour les deux GRUB ? As-tu essayé en mode graphique mais sans image de fond ?
Le 28/03/2020 à 20:16, Lulu a écrit :
Le 25-03-2020, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Donc le résultat est le même quel que soit le GRUB qui amorce le
système, et la logique est respectée : le démarrage sur SSD interne
est beaucoup plus rapide que sur disque dur externe en USB. La
différence de vitesse entre les deux supports ne suffirait-elle pas à
expliquer l'écart, même si cela n'exclut pas qu'une différence dans
les paramètres du noyau des deux système puisse aussi jouer un rôle ?
Effectivement, c'est la conclusion que j'en tire, même si le rapport entre
le temps de démarrage sur le disque externe par rapport au disque
interne, soit 120s / 24s = 5 me semble un peu énorme.
Je ne trouve pas, au contraire.
Les SSD ont un temps d'accès négligeable et peuvent atteindre des débits
de plusieurs centaines de Mo/s. Les disques durs externes ont
généralement un format 2,5" et une vitesse de rotation basse (~5000
t/mn) et sont optimisés pour une faible consommation plutôt que pour la
performance, ce qui se traduit par un temps d'accès et et un débit
plutôt médiocres. Tu peux comparer leurs débits séquentiels avec hdparm -t.
Mais à l'origine, je venais ici pour essayer de comprendre pourquoi le
grub graphique du disque externe (pourtant configuré exactement comme
celui du disque interne) affichait les caractères un par un, avec
l'impossibilité de sélectionner une autre ligne que la première puisque
la frappe de la moindre touche relance le dessin, caractère par
caractère, du menu.
Je n'ai pas d'explication, seulement des hypothèses.
1) Si GRUB doit faire des accès disque pour redessiner l'écran (je ne
vois pas bien pourquoi mais on ne sait jamais), la lenteur de l'accès au
disque externe (due à ses performances intrinsèques et/ou au pilote du
BIOS) pourrait jouer.
2) Le mode graphique est-il le même pour les deux GRUB ? à vérifier avec
vbeinfo ou videoinfo dans le shell de GRUB.
3) L'image de fond est-elle la la même pour les deux GRUB ? As-tu essayé
en mode graphique mais sans image de fond ?
Donc le résultat est le même quel que soit le GRUB qui amorce le système, et la logique est respectée : le démarrage sur SSD interne est beaucoup plus rapide que sur disque dur externe en USB. La différence de vitesse entre les deux supports ne suffirait-elle pas à expliquer l'écart, même si cela n'exclut pas qu'une différence dans les paramètres du noyau des deux système puisse aussi jouer un rôle ?
Effectivement, c'est la conclusion que j'en tire, même si le rapport entre le temps de démarrage sur le disque externe par rapport au disque interne, soit 120s / 24s = 5 me semble un peu énorme.
Je ne trouve pas, au contraire. Les SSD ont un temps d'accès négligeable et peuvent atteindre des débits de plusieurs centaines de Mo/s. Les disques durs externes ont généralement un format 2,5" et une vitesse de rotation basse (~5000 t/mn) et sont optimisés pour une faible consommation plutôt que pour la performance, ce qui se traduit par un temps d'accès et et un débit plutôt médiocres. Tu peux comparer leurs débits séquentiels avec hdparm -t.
Mais à l'origine, je venais ici pour essayer de comprendre pourquoi le grub graphique du disque externe (pourtant configuré exactement comme celui du disque interne) affichait les caractères un par un, avec l'impossibilité de sélectionner une autre ligne que la première puisque la frappe de la moindre touche relance le dessin, caractère par caractère, du menu.
Je n'ai pas d'explication, seulement des hypothèses. 1) Si GRUB doit faire des accès disque pour redessiner l'écran (je ne vois pas bien pourquoi mais on ne sait jamais), la lenteur de l'accès au disque externe (due à ses performances intrinsèques et/ou au pilote du BIOS) pourrait jouer. 2) Le mode graphique est-il le même pour les deux GRUB ? à vérifier avec vbeinfo ou videoinfo dans le shell de GRUB. 3) L'image de fond est-elle la la même pour les deux GRUB ? As-tu essayé en mode graphique mais sans image de fond ?
dyrmak
En 42 lignes Pascal Hambourg a écrit dans news:5e8099f2$0$15190$ le dimanche, 29 mars 2020 à 14:52:01 :
3) L'image de fond est-elle la la même pour les deux GRUB ? As-tu essayé en mode graphique mais sans image de fond ?
.... L'image de fond du disque externe avec cette extension peu commune *.tga, *tva ? qu'il m'est semble avoir vu sur la configuration grub de son disque externe attirait déjà mon attention, elle n'existe pas dans mon arborescence.... D'où provient cette image ? dyrmak -- ¿ Cómo era aquello del rayo verde ? ++++ --- ++++ Linux operating system ++++ --- ++++
En 42 lignes Pascal Hambourg a écrit
dans news:5e8099f2$0$15190$426a74cc@news.free.fr
le dimanche, 29 mars 2020 à 14:52:01 :
3) L'image de fond est-elle la la même pour les deux GRUB ? As-tu essayé
en mode graphique mais sans image de fond ?
.... L'image de fond du disque externe avec cette extension peu
commune *.tga, *tva ? qu'il m'est semble avoir vu sur la configuration
grub de son disque externe attirait déjà mon attention, elle n'existe pas
dans mon arborescence.... D'où provient cette image ?
dyrmak
--
¿ Cómo era aquello del rayo verde ?
++++ --- ++++
Linux operating system
++++ --- ++++
En 42 lignes Pascal Hambourg a écrit dans news:5e8099f2$0$15190$ le dimanche, 29 mars 2020 à 14:52:01 :
3) L'image de fond est-elle la la même pour les deux GRUB ? As-tu essayé en mode graphique mais sans image de fond ?
.... L'image de fond du disque externe avec cette extension peu commune *.tga, *tva ? qu'il m'est semble avoir vu sur la configuration grub de son disque externe attirait déjà mon attention, elle n'existe pas dans mon arborescence.... D'où provient cette image ? dyrmak -- ¿ Cómo era aquello del rayo verde ? ++++ --- ++++ Linux operating system ++++ --- ++++
