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.
Le Tue, 17 Mar 2020 00:49:24 +0100, Lulu a écrit :
dmesg_MinTosh500 dmesg_MinTosh500: ASCII text
C'est juste (à peine) un peu gros pour usenet. Paste.bin est ton ami.
Merci du conseil, céparla --> https://pastebin.com/GtZDUdRW On voit qu'entre la ligne 797 (97 secondes) et la ligne 798 (143 secondes), le système ne fait rien... Et pareil entre la ligne 790 (143 secondes) et la ligne 791 (247 secondes). J'ai le bluetooth farceur ? Comme je ne m'en sers pas, comment le désactiver (rien vu dans le BIOS setup). Pour info, quand je boote sur le SSD interne, les 10 dernières lignes du dmesg sont: [ 19.647511] iwlwifi 0000:02:00.0 wlp2s0: disabling HE/HT/VHT due to WEP/TKIP use [ 19.647515] iwlwifi 0000:02:00.0 wlp2s0: disabling HT as WMM/QoS is not supported by the AP [ 19.647517] iwlwifi 0000:02:00.0 wlp2s0: disabling VHT as WMM/QoS is not supported by the AP [ 19.648041] wlp2s0: associate with 00:90:4c:91:00:01 (try 1/3) [ 19.650560] wlp2s0: RX AssocResp from 00:90:4c:91:00:01 (capab=0x411 status=0 aid=1) [ 19.651923] wlp2s0: associated [ 19.666243] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready [ 35.170243] Bluetooth: RFCOMM TTY layer initialized [ 35.170255] Bluetooth: RFCOMM socket layer initialized [ 35.170270] Bluetooth: RFCOMM ver 1.11 Merci de votre aide
Le 17-03-2020, Jo Engo <yl@icite.fr> a écrit :
Le Tue, 17 Mar 2020 00:49:24 +0100, Lulu a écrit :
dmesg_MinTosh500 dmesg_MinTosh500: ASCII text
C'est juste (à peine) un peu gros pour usenet. Paste.bin est ton ami.
Merci du conseil, céparla --> https://pastebin.com/GtZDUdRW
On voit qu'entre la ligne 797 (97 secondes) et la ligne 798 (143
secondes), le système ne fait rien...
Et pareil entre la ligne 790 (143 secondes) et la ligne 791 (247
secondes).
J'ai le bluetooth farceur ?
Comme je ne m'en sers pas, comment le désactiver (rien vu dans le BIOS
setup).
Pour info, quand je boote sur le SSD interne, les 10 dernières lignes du
dmesg sont:
[ 19.647511] iwlwifi 0000:02:00.0 wlp2s0: disabling HE/HT/VHT due to WEP/TKIP use
[ 19.647515] iwlwifi 0000:02:00.0 wlp2s0: disabling HT as WMM/QoS is not supported by the AP
[ 19.647517] iwlwifi 0000:02:00.0 wlp2s0: disabling VHT as WMM/QoS is not supported by the AP
[ 19.648041] wlp2s0: associate with 00:90:4c:91:00:01 (try 1/3)
[ 19.650560] wlp2s0: RX AssocResp from 00:90:4c:91:00:01 (capab=0x411 status=0 aid=1)
[ 19.651923] wlp2s0: associated
[ 19.666243] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
[ 35.170243] Bluetooth: RFCOMM TTY layer initialized
[ 35.170255] Bluetooth: RFCOMM socket layer initialized
[ 35.170270] Bluetooth: RFCOMM ver 1.11
Le Tue, 17 Mar 2020 00:49:24 +0100, Lulu a écrit :
dmesg_MinTosh500 dmesg_MinTosh500: ASCII text
C'est juste (à peine) un peu gros pour usenet. Paste.bin est ton ami.
Merci du conseil, céparla --> https://pastebin.com/GtZDUdRW On voit qu'entre la ligne 797 (97 secondes) et la ligne 798 (143 secondes), le système ne fait rien... Et pareil entre la ligne 790 (143 secondes) et la ligne 791 (247 secondes). J'ai le bluetooth farceur ? Comme je ne m'en sers pas, comment le désactiver (rien vu dans le BIOS setup). Pour info, quand je boote sur le SSD interne, les 10 dernières lignes du dmesg sont: [ 19.647511] iwlwifi 0000:02:00.0 wlp2s0: disabling HE/HT/VHT due to WEP/TKIP use [ 19.647515] iwlwifi 0000:02:00.0 wlp2s0: disabling HT as WMM/QoS is not supported by the AP [ 19.647517] iwlwifi 0000:02:00.0 wlp2s0: disabling VHT as WMM/QoS is not supported by the AP [ 19.648041] wlp2s0: associate with 00:90:4c:91:00:01 (try 1/3) [ 19.650560] wlp2s0: RX AssocResp from 00:90:4c:91:00:01 (capab=0x411 status=0 aid=1) [ 19.651923] wlp2s0: associated [ 19.666243] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready [ 35.170243] Bluetooth: RFCOMM TTY layer initialized [ 35.170255] Bluetooth: RFCOMM socket layer initialized [ 35.170270] Bluetooth: RFCOMM ver 1.11 Merci de votre aide
dyrmak
En 79 lignes Lulu a écrit dans news: le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne comme avec bios legacy, mais pourquoi ne pas booter sur le disque de l'ordinateur et forcer le grub à s'installer sur le USB ? Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire.... Mais si ça marchait, ton grub externe n'est pas bon.... Et si on mettait le disque sur USB2 au lieu de USB3 ? Mes ordis ont plusieurs prises, deux USB2 et une (en bleu) USB3... dyrmak -- Se hace camino al andar ++++ --- ++++ Linux operating system ++++ --- ++++
En 79 lignes Lulu a écrit
dans news:slrnr6numh.2u7.lulu042@MinTosh500.rock-n-Roll.org
le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne
comme avec bios legacy, mais pourquoi ne pas booter sur le disque
de l'ordinateur et forcer le grub à s'installer sur le USB ?
Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire....
Mais si ça marchait, ton grub externe n'est pas bon....
Et si on mettait le disque sur USB2 au lieu de USB3 ? Mes ordis ont
plusieurs prises, deux USB2 et une (en bleu) USB3...
dyrmak
--
Se hace camino al andar
++++ --- ++++
Linux operating system
++++ --- ++++
En 79 lignes Lulu a écrit dans news: le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne comme avec bios legacy, mais pourquoi ne pas booter sur le disque de l'ordinateur et forcer le grub à s'installer sur le USB ? Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire.... Mais si ça marchait, ton grub externe n'est pas bon.... Et si on mettait le disque sur USB2 au lieu de USB3 ? Mes ordis ont plusieurs prises, deux USB2 et une (en bleu) USB3... dyrmak -- Se hace camino al andar ++++ --- ++++ Linux operating system ++++ --- ++++
Sergio
Le 17/03/2020 à 16:15, dyrmak a écrit :
En 79 lignes Lulu a écrit dans news: le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne comme avec bios legacy, mais pourquoi ne pas booter sur le disque de l'ordinateur et forcer le grub à s'installer sur le USB ? Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire.... Mais si ça marchait, ton grub externe n'est pas bon....
Pour info : Je possède un notebook UEFI (non débrayable) : J'ai installé un LinuxMint 19.3 sans problème (et en bi-boot avec le Windows 10 d'origine) sans problème. J'ai le Grub graphique. Le seul défaut que j'ai constaté, c'est l'absence du memtest86 (mais c'est normal). -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 17/03/2020 à 16:15, dyrmak a écrit :
En 79 lignes Lulu a écrit
dans news:slrnr6numh.2u7.lulu042@MinTosh500.rock-n-Roll.org
le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne
comme avec bios legacy, mais pourquoi ne pas booter sur le disque
de l'ordinateur et forcer le grub à s'installer sur le USB ?
Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire....
Mais si ça marchait, ton grub externe n'est pas bon....
Pour info : Je possède un notebook UEFI (non débrayable) :
J'ai installé un LinuxMint 19.3 sans problème (et en bi-boot avec le Windows 10 d'origine) sans problème.
J'ai le Grub graphique. Le seul défaut que j'ai constaté, c'est l'absence du memtest86 (mais c'est normal).
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
En 79 lignes Lulu a écrit dans news: le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne comme avec bios legacy, mais pourquoi ne pas booter sur le disque de l'ordinateur et forcer le grub à s'installer sur le USB ? Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire.... Mais si ça marchait, ton grub externe n'est pas bon....
Pour info : Je possède un notebook UEFI (non débrayable) : J'ai installé un LinuxMint 19.3 sans problème (et en bi-boot avec le Windows 10 d'origine) sans problème. J'ai le Grub graphique. Le seul défaut que j'ai constaté, c'est l'absence du memtest86 (mais c'est normal). -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
dyrmak
En 35 lignes Pascal Hambourg a écrit dans news:5e6bd94c$0$21621$ le vendredi, 13 mars 2020 à 20:04:43 :
Pas besoin d'en arriver à cette extrémité qui n'est pas une solution viable : à un moment donné il faudra bien exécuter update-grub pour mettre à jour grub.cfg après l'installation d'un nouveau noyau. Comme je l'ai écrit, il suffit de désactiver os-prober sur les installations qui ne gèrent pas le GRUB qui s'exécute au démarrage. Dans /etc/default/grub : GRUB_DISABLE_OS_PROBER=true Ainsi les grub.cfg de ces installations produits par update-grub ne prendront en compte que leurs propres noyaux et pas ceux inclus dans les grub.cfg des autres installations, et le grub.cfg principal ne les incluera qu'une fois, sans répétitions possibles.
Très sincèrement je garderai ça bien en tête pour la prochaine fois, tu as tout à fait raison! Je vais faire mon apprentissage sur trois partitions bootables pour bien faire sur virtualbox, avec mint ou debian mx-linux et netrunner, comme ça je partirai avec quelque chose de récent et je verrai bien pour m'éviter les pièges ou les étourderies. dyrmak -- A la hora de la ahora ++++ --- ++++ Linux operating system ++++ --- ++++
En 35 lignes Pascal Hambourg a écrit
dans news:5e6bd94c$0$21621$426a74cc@news.free.fr
le vendredi, 13 mars 2020 à 20:04:43 :
Pas besoin d'en arriver à cette extrémité qui n'est pas une solution
viable : à un moment donné il faudra bien exécuter update-grub pour
mettre à jour grub.cfg après l'installation d'un nouveau noyau.
Comme je l'ai écrit, il suffit de désactiver os-prober sur les
installations qui ne gèrent pas le GRUB qui s'exécute au démarrage. Dans
/etc/default/grub :
GRUB_DISABLE_OS_PROBER=true
Ainsi les grub.cfg de ces installations produits par update-grub ne
prendront en compte que leurs propres noyaux et pas ceux inclus dans les
grub.cfg des autres installations, et le grub.cfg principal ne les
incluera qu'une fois, sans répétitions possibles.
Très sincèrement je garderai ça bien en tête pour la prochaine fois,
tu as tout à fait raison! Je vais faire mon apprentissage sur trois
partitions bootables pour bien faire sur virtualbox, avec mint ou debian
mx-linux et netrunner, comme ça je partirai avec quelque chose de récent
et je verrai bien pour m'éviter les pièges ou les étourderies.
dyrmak
--
A la hora de la ahora
++++ --- ++++
Linux operating system
++++ --- ++++
En 35 lignes Pascal Hambourg a écrit dans news:5e6bd94c$0$21621$ le vendredi, 13 mars 2020 à 20:04:43 :
Pas besoin d'en arriver à cette extrémité qui n'est pas une solution viable : à un moment donné il faudra bien exécuter update-grub pour mettre à jour grub.cfg après l'installation d'un nouveau noyau. Comme je l'ai écrit, il suffit de désactiver os-prober sur les installations qui ne gèrent pas le GRUB qui s'exécute au démarrage. Dans /etc/default/grub : GRUB_DISABLE_OS_PROBER=true Ainsi les grub.cfg de ces installations produits par update-grub ne prendront en compte que leurs propres noyaux et pas ceux inclus dans les grub.cfg des autres installations, et le grub.cfg principal ne les incluera qu'une fois, sans répétitions possibles.
Très sincèrement je garderai ça bien en tête pour la prochaine fois, tu as tout à fait raison! Je vais faire mon apprentissage sur trois partitions bootables pour bien faire sur virtualbox, avec mint ou debian mx-linux et netrunner, comme ça je partirai avec quelque chose de récent et je verrai bien pour m'éviter les pièges ou les étourderies. dyrmak -- A la hora de la ahora ++++ --- ++++ Linux operating system ++++ --- ++++
dyrmak
En 22 lignes Sergio a écrit dans news:5e70eb4e$0$16819$ le mardi, 17 mars 2020 à 16:22:54 :
Le 17/03/2020 à 16:15, dyrmak a écrit :
En 79 lignes Lulu a écrit dans news: le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne comme avec bios legacy, mais pourquoi ne pas booter sur le disque de l'ordinateur et forcer le grub à s'installer sur le USB ? Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire.... Mais si ça marchait, ton grub externe n'est pas bon....
Pour info : Je possède un notebook UEFI (non débrayable) : J'ai installé un LinuxMint 19.3 sans problème (et en bi-boot avec le Windows 10 d'origine) sans problème. J'ai le Grub graphique. Le seul défaut que j'ai constaté, c'est l'absence du memtest86 (mais c'est normal).
Bonjour, Excellent! Question: Comment ça se passe pour le secure boot? Pourquoi pas de memtest86 ? ( Quelque chose m'échappe ) dyrmak -- La alta montaña de Guadalupe ++++ --- ++++ Linux operating system ++++ --- ++++
En 22 lignes Sergio a écrit
dans news:5e70eb4e$0$16819$426a74cc@news.free.fr
le mardi, 17 mars 2020 à 16:22:54 :
Le 17/03/2020 à 16:15, dyrmak a écrit :
En 79 lignes Lulu a écrit
dans news:slrnr6numh.2u7.lulu042@MinTosh500.rock-n-Roll.org
le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne
comme avec bios legacy, mais pourquoi ne pas booter sur le disque
de l'ordinateur et forcer le grub à s'installer sur le USB ?
Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire....
Mais si ça marchait, ton grub externe n'est pas bon....
Pour info : Je possède un notebook UEFI (non débrayable) :
J'ai installé un LinuxMint 19.3 sans problème (et en bi-boot avec le Windows 10 d'origine)
sans problème.
J'ai le Grub graphique. Le seul défaut que j'ai constaté, c'est l'absence du memtest86
(mais c'est normal).
Bonjour,
Excellent! Question: Comment ça se passe pour le secure boot?
Pourquoi pas de memtest86 ? ( Quelque chose m'échappe )
dyrmak
--
La alta montaña de Guadalupe
++++ --- ++++
Linux operating system
++++ --- ++++
En 22 lignes Sergio a écrit dans news:5e70eb4e$0$16819$ le mardi, 17 mars 2020 à 16:22:54 :
Le 17/03/2020 à 16:15, dyrmak a écrit :
En 79 lignes Lulu a écrit dans news: le vendredi, 13 mars 2020 à 22:27:45 :
Toujours pareil : fait chier !
Installation UEFI ? Je ne sais pas si grub install /device fonctionne comme avec bios legacy, mais pourquoi ne pas booter sur le disque de l'ordinateur et forcer le grub à s'installer sur le USB ? Je n'ai pas d'expérience concrète sur UEFI et je ne saurais dire.... Mais si ça marchait, ton grub externe n'est pas bon....
Pour info : Je possède un notebook UEFI (non débrayable) : J'ai installé un LinuxMint 19.3 sans problème (et en bi-boot avec le Windows 10 d'origine) sans problème. J'ai le Grub graphique. Le seul défaut que j'ai constaté, c'est l'absence du memtest86 (mais c'est normal).
Bonjour, Excellent! Question: Comment ça se passe pour le secure boot? Pourquoi pas de memtest86 ? ( Quelque chose m'échappe ) dyrmak -- La alta montaña de Guadalupe ++++ --- ++++ Linux operating system ++++ --- ++++
Sergio
Le 17/03/2020 à 16:34, dyrmak a écrit :
Bonjour, Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Pourquoi pas de memtest86 ? ( Quelque chose m'échappe )
memetest86 est une application 16 bits. Ça passe, même avec un processeur 64 bits, mais pas avec l'EFI. Il existe un memtest compatible UEFI, mais non libre. -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 17/03/2020 à 16:34, dyrmak a écrit :
Bonjour,
Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Pourquoi pas de memtest86 ? ( Quelque chose m'échappe )
memetest86 est une application 16 bits. Ça passe, même avec un processeur 64 bits, mais pas avec l'EFI.
Il existe un memtest compatible UEFI, mais non libre.
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Bonjour, Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Pourquoi pas de memtest86 ? ( Quelque chose m'échappe )
memetest86 est une application 16 bits. Ça passe, même avec un processeur 64 bits, mais pas avec l'EFI. Il existe un memtest compatible UEFI, mais non libre. -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
dyrmak
En 16 lignes Sergio a écrit dans news:5e70f35e$0$6465$ le mardi, 17 mars 2020 à 16:57:18 :
Le 17/03/2020 à 16:34, dyrmak a écrit :
Bonjour, Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Pas forcément une bonne nouvelle, car les kernels qu'on compile soi-même sont ou seraient hors jeu ....;[
Pourquoi pas de memtest86 ? ( Quelque chose m'échappe )
memetest86 est une application 16 bits. Ça passe, même avec un processeur 64 bits, mais pas avec l'EFI. Il existe un memtest compatible UEFI, mais non libre.
ok vu ! Merci pour les info ! dyrmak -- Cantó alegre aquel huapango porque la vida se apaga ++++ --- ++++ Linux operating system ++++ --- ++++
En 16 lignes Sergio a écrit
dans news:5e70f35e$0$6465$426a74cc@news.free.fr
le mardi, 17 mars 2020 à 16:57:18 :
Le 17/03/2020 à 16:34, dyrmak a écrit :
Bonjour,
Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Pas forcément une bonne nouvelle, car les kernels qu'on compile
soi-même sont ou seraient hors jeu ....;[
Pourquoi pas de memtest86 ? ( Quelque chose m'échappe )
memetest86 est une application 16 bits. Ça passe, même avec un processeur 64 bits, mais pas avec l'EFI.
Il existe un memtest compatible UEFI, mais non libre.
ok vu !
Merci pour les info !
dyrmak
--
Cantó alegre aquel huapango porque la vida se apaga
++++ --- ++++
Linux operating system
++++ --- ++++
En 16 lignes Sergio a écrit dans news:5e70f35e$0$6465$ le mardi, 17 mars 2020 à 16:57:18 :
Le 17/03/2020 à 16:34, dyrmak a écrit :
Bonjour, Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Pas forcément une bonne nouvelle, car les kernels qu'on compile soi-même sont ou seraient hors jeu ....;[
Pourquoi pas de memtest86 ? ( Quelque chose m'échappe )
memetest86 est une application 16 bits. Ça passe, même avec un processeur 64 bits, mais pas avec l'EFI. Il existe un memtest compatible UEFI, mais non libre.
ok vu ! Merci pour les info ! dyrmak -- Cantó alegre aquel huapango porque la vida se apaga ++++ --- ++++ Linux operating system ++++ --- ++++
Pascal Hambourg
Le 17/03/2020 à 17:10, dyrmak a écrit :
En 16 lignes Sergio a écrit
Le 17/03/2020 à 16:34, dyrmak a écrit :
Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI. 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.
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). 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.
Le 17/03/2020 à 17:10, dyrmak a écrit :
En 16 lignes Sergio a écrit
Le 17/03/2020 à 16:34, dyrmak a écrit :
Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI.
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.
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).
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.
Excellent! Question: Comment ça se passe pour le secure boot?
je crois qu'Ubuntu a passé des acdcords pour pouvoir utiliser l'UEFI (question de signature)
Le secure boot, pas l'UEFI. 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.
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). 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.
Pascal Hambourg
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 : GRUB interne -> système interne GRUB interne -> système externe GRUB externe -> système interne GRUB externe -> système externe 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.
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.*.
Je croyais qu'un dmesg était du texte...
Oui, mais ça reste une pièce jointe.
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 :
GRUB interne -> système interne
GRUB interne -> système externe
GRUB externe -> système interne
GRUB externe -> système externe
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.
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.*.
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 : GRUB interne -> système interne GRUB interne -> système externe GRUB externe -> système interne GRUB externe -> système externe 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.
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.*.
Je croyais qu'un dmesg était du texte...
Oui, mais ça reste une pièce jointe.
Pascal Hambourg
Le 17/03/2020 à 14:39, Lulu a écrit :
Merci du conseil, céparla --> https://pastebin.com/GtZDUdRW On voit qu'entre la ligne 797 (97 secondes) et la ligne 798 (143 secondes), le système ne fait rien...
Il ne fait rien qui mérite un message dans les logs du noyau, nuance. Ça peut correspondre au lancement de divers services par le gestionnaire d'init.
Le 17/03/2020 à 14:39, Lulu a écrit :
Merci du conseil, céparla --> https://pastebin.com/GtZDUdRW
On voit qu'entre la ligne 797 (97 secondes) et la ligne 798 (143
secondes), le système ne fait rien...
Il ne fait rien qui mérite un message dans les logs du noyau, nuance.
Ça peut correspondre au lancement de divers services par le gestionnaire
d'init.
Merci du conseil, céparla --> https://pastebin.com/GtZDUdRW On voit qu'entre la ligne 797 (97 secondes) et la ligne 798 (143 secondes), le système ne fait rien...
Il ne fait rien qui mérite un message dans les logs du noyau, nuance. Ça peut correspondre au lancement de divers services par le gestionnaire d'init.
