dans ma nouvelle installation de mint19 dans le gestionnaire de pilote
on ne me propose pas une mise a jour du firmware microcode du processeur
intel ,j'ai crains que dans la version 18 de mint ça me fasse le bordel
et je ne l'ai jamais installée ,mais dans la version 19 ce serait fait ?
C'est faux. Il est aussi possible de faire charger le microcode par l'initramfs ou par le système final. Apparemment ArchLinux justifie le chargement au plus tôt du microcode par le fait que sur les processeurs Intel Broadwell et Haswell le chargement tardif ferait planter le noyau. <https://bugs.archlinux.org/task/59841>
Oui ils disent bien : "What's the whole point of placing it there if it can't be loaded late? Intel microcode updates need a reboot. Applying it without reboot is recipe for crashes and weird bugs."
Il y a quand même un détail qui me chiffonne : apparemment un chargeur GRUB non patché comprend quand même la syntaxe à deux arguments, alors que ce n'est pas documenté dans <https://www.gnu.org/software/grub/manual/grub/grub.html#initrd>.
En épluchant les changelogs de GRUB, j'ai trouvé qu'il supporte le chargement d'initrd multiples depuis la version 2.00. Mais cela ne semble vrai que pour le chargeur lui-même, pas pour les scripts utilisés par grub-mkconfig pour construire grub.cfg.
Ok, je pige en gros le script, mais je note ceci : "Needless to say, this method is not the most flexible one because it requires rebuilding the kernel each time updated microcode from the CPU vendor is available." <https://www.kernel.org/doc/Documentation/x86/microcode.txt>
Automatic method grub-mkconfig will automatically detect the microcode update and configure GRUB appropriately.
Apparemment non, cf. supra. Sachant cela, il aurait été parfaitement possible pour Arch/Manjaro de construire un initramfs multi-segment incluant les microcodes au lieu d'utiliser la fonctionnalité de chargement d'initrd multiples du chargeur qui n'est pas supportée automatiquement par les autres distributions.
Bon, il me semble que les autres distributions y arrivent, mais comment ? Je n'ai pas les compétences pour le comprendre... Toutefois, je n'ai pas l'impression que les gens derrière Arch sont des rigolos. Merci pour ces informations complémentaires ! -- jp willm http://perso.orange.fr/willms/index.html
Le 28/12/2018 à 18:56, Pascal Hambourg a écrit :
Microcode must be loaded by the boot loader.
C'est faux. Il est aussi possible de faire charger le microcode par
l'initramfs ou par le système final. Apparemment ArchLinux justifie le
chargement au plus tôt du microcode par le fait que sur les processeurs
Intel Broadwell et Haswell le chargement tardif ferait planter le noyau.
<https://bugs.archlinux.org/task/59841>
Oui ils disent bien :
"What's the whole point of placing it there if it can't be loaded late?
Intel microcode updates need a reboot. Applying it without reboot is
recipe for crashes and weird bugs."
Il y a quand même un détail qui me chiffonne : apparemment un
chargeur GRUB non patché comprend quand même la syntaxe à deux
arguments, alors que ce n'est pas documenté dans
<https://www.gnu.org/software/grub/manual/grub/grub.html#initrd>.
En épluchant les changelogs de GRUB, j'ai trouvé qu'il supporte le
chargement d'initrd multiples depuis la version 2.00. Mais cela ne
semble vrai que pour le chargeur lui-même, pas pour les scripts utilisés
par grub-mkconfig pour construire grub.cfg.
Ok, je pige en gros le script, mais je note ceci :
"Needless to say, this method is not the most flexible one because it
requires rebuilding the kernel each time updated microcode from the CPU
vendor is available."
grub-mkconfig will automatically detect the microcode update and
configure GRUB appropriately.
Apparemment non, cf. supra. Sachant cela, il aurait été parfaitement
possible pour Arch/Manjaro de construire un initramfs multi-segment
incluant les microcodes au lieu d'utiliser la fonctionnalité de
chargement d'initrd multiples du chargeur qui n'est pas supportée
automatiquement par les autres distributions.
Bon, il me semble que les autres distributions y arrivent, mais comment ?
Je n'ai pas les compétences pour le comprendre...
Toutefois, je n'ai pas l'impression que les gens derrière Arch sont des
rigolos.
C'est faux. Il est aussi possible de faire charger le microcode par l'initramfs ou par le système final. Apparemment ArchLinux justifie le chargement au plus tôt du microcode par le fait que sur les processeurs Intel Broadwell et Haswell le chargement tardif ferait planter le noyau. <https://bugs.archlinux.org/task/59841>
Oui ils disent bien : "What's the whole point of placing it there if it can't be loaded late? Intel microcode updates need a reboot. Applying it without reboot is recipe for crashes and weird bugs."
Il y a quand même un détail qui me chiffonne : apparemment un chargeur GRUB non patché comprend quand même la syntaxe à deux arguments, alors que ce n'est pas documenté dans <https://www.gnu.org/software/grub/manual/grub/grub.html#initrd>.
En épluchant les changelogs de GRUB, j'ai trouvé qu'il supporte le chargement d'initrd multiples depuis la version 2.00. Mais cela ne semble vrai que pour le chargeur lui-même, pas pour les scripts utilisés par grub-mkconfig pour construire grub.cfg.
Ok, je pige en gros le script, mais je note ceci : "Needless to say, this method is not the most flexible one because it requires rebuilding the kernel each time updated microcode from the CPU vendor is available." <https://www.kernel.org/doc/Documentation/x86/microcode.txt>
Automatic method grub-mkconfig will automatically detect the microcode update and configure GRUB appropriately.
Apparemment non, cf. supra. Sachant cela, il aurait été parfaitement possible pour Arch/Manjaro de construire un initramfs multi-segment incluant les microcodes au lieu d'utiliser la fonctionnalité de chargement d'initrd multiples du chargeur qui n'est pas supportée automatiquement par les autres distributions.
Bon, il me semble que les autres distributions y arrivent, mais comment ? Je n'ai pas les compétences pour le comprendre... Toutefois, je n'ai pas l'impression que les gens derrière Arch sont des rigolos. Merci pour ces informations complémentaires ! -- jp willm http://perso.orange.fr/willms/index.html
Pascal Hambourg
Le 30/12/2018 à 12:37, jp willm a écrit :
Le 28/12/2018 à 18:56, Pascal Hambourg a écrit :
En épluchant les changelogs de GRUB, j'ai trouvé qu'il supporte le chargement d'initrd multiples depuis la version 2.00. Mais cela ne semble vrai que pour le chargeur lui-même, pas pour les scripts utilisés par grub-mkconfig pour construire grub.cfg.
Ok, je pige en gros le script, mais je note ceci : "Needless to say, this method is not the most flexible one because it requires rebuilding the kernel each time updated microcode from the CPU vendor is available." <https://www.kernel.org/doc/Documentation/x86/microcode.txt>
De quel script parles-tu ? La phrase que tu cites concerne l'intégration des microcodes dans l'image du noyau, pas dans un initrd chargé séparément de l'image du noyau par le chargeur d'amorçage.
grub-mkconfig will automatically detect the microcode update and configure GRUB appropriately.
Apparemment non, cf. supra. Sachant cela, il aurait été parfaitement possible pour Arch/Manjaro de construire un initramfs multi-segment incluant les microcodes au lieu d'utiliser la fonctionnalité de chargement d'initrd multiples du chargeur qui n'est pas supportée automatiquement par les autres distributions.
Bon, il me semble que les autres distributions y arrivent, mais comment ?
En ce qui concerne Debian 9/Stretch, le générateur d'initramfs par défaut, initramfs-tools, peut construire un initramfs multi-segment incluant les microcodes.
Le 30/12/2018 à 12:37, jp willm a écrit :
Le 28/12/2018 à 18:56, Pascal Hambourg a écrit :
En épluchant les changelogs de GRUB, j'ai trouvé qu'il supporte le
chargement d'initrd multiples depuis la version 2.00. Mais cela ne
semble vrai que pour le chargeur lui-même, pas pour les scripts
utilisés par grub-mkconfig pour construire grub.cfg.
Ok, je pige en gros le script, mais je note ceci :
"Needless to say, this method is not the most flexible one because it
requires rebuilding the kernel each time updated microcode from the CPU
vendor is available."
De quel script parles-tu ? La phrase que tu cites concerne l'intégration
des microcodes dans l'image du noyau, pas dans un initrd chargé
séparément de l'image du noyau par le chargeur d'amorçage.
grub-mkconfig will automatically detect the microcode update and
configure GRUB appropriately.
Apparemment non, cf. supra. Sachant cela, il aurait été parfaitement
possible pour Arch/Manjaro de construire un initramfs multi-segment
incluant les microcodes au lieu d'utiliser la fonctionnalité de
chargement d'initrd multiples du chargeur qui n'est pas supportée
automatiquement par les autres distributions.
Bon, il me semble que les autres distributions y arrivent, mais comment ?
En ce qui concerne Debian 9/Stretch, le générateur d'initramfs par
défaut, initramfs-tools, peut construire un initramfs multi-segment
incluant les microcodes.
En épluchant les changelogs de GRUB, j'ai trouvé qu'il supporte le chargement d'initrd multiples depuis la version 2.00. Mais cela ne semble vrai que pour le chargeur lui-même, pas pour les scripts utilisés par grub-mkconfig pour construire grub.cfg.
Ok, je pige en gros le script, mais je note ceci : "Needless to say, this method is not the most flexible one because it requires rebuilding the kernel each time updated microcode from the CPU vendor is available." <https://www.kernel.org/doc/Documentation/x86/microcode.txt>
De quel script parles-tu ? La phrase que tu cites concerne l'intégration des microcodes dans l'image du noyau, pas dans un initrd chargé séparément de l'image du noyau par le chargeur d'amorçage.
grub-mkconfig will automatically detect the microcode update and configure GRUB appropriately.
Apparemment non, cf. supra. Sachant cela, il aurait été parfaitement possible pour Arch/Manjaro de construire un initramfs multi-segment incluant les microcodes au lieu d'utiliser la fonctionnalité de chargement d'initrd multiples du chargeur qui n'est pas supportée automatiquement par les autres distributions.
Bon, il me semble que les autres distributions y arrivent, mais comment ?
En ce qui concerne Debian 9/Stretch, le générateur d'initramfs par défaut, initramfs-tools, peut construire un initramfs multi-segment incluant les microcodes.
De quel script parles-tu ? La phrase que tu cites concerne l'intégration des microcodes dans l'image du noyau, pas dans un initrd chargé séparément de l'image du noyau par le chargeur d'amorçage.
Ah flûte, j'ai confondu :-/
En ce qui concerne Debian 9/Stretch, le générateur d'initramfs par défaut, initramfs-tools, peut construire un initramfs multi-segment incluant les microcodes.
Et du moment qu'il charge le microcode au boot sans faire planter les nouveau processeurs intel, c'est tout bon. -- jp willm http://perso.orange.fr/willms/index.html
De quel script parles-tu ? La phrase que tu cites concerne l'intégration
des microcodes dans l'image du noyau, pas dans un initrd chargé
séparément de l'image du noyau par le chargeur d'amorçage.
Ah flûte, j'ai confondu :-/
En ce qui concerne Debian 9/Stretch, le générateur d'initramfs par
défaut, initramfs-tools, peut construire un initramfs multi-segment
incluant les microcodes.
Et du moment qu'il charge le microcode au boot sans faire planter les
nouveau processeurs intel, c'est tout bon.
De quel script parles-tu ? La phrase que tu cites concerne l'intégration des microcodes dans l'image du noyau, pas dans un initrd chargé séparément de l'image du noyau par le chargeur d'amorçage.
Ah flûte, j'ai confondu :-/
En ce qui concerne Debian 9/Stretch, le générateur d'initramfs par défaut, initramfs-tools, peut construire un initramfs multi-segment incluant les microcodes.
Et du moment qu'il charge le microcode au boot sans faire planter les nouveau processeurs intel, c'est tout bon. -- jp willm http://perso.orange.fr/willms/index.html
Eric Masson
jp willm writes: 'Lut,
Et du moment qu'il charge le microcode au boot sans faire planter les nouveau processeurs intel, c'est tout bon.
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012) et a été développé à cette fin : https://www.kernel.org/doc/Documentation/x86/microcode.txt Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par défaut sur les distributions courantes. -- Alors la ca dépasse l'entendemment, même clara dans sa splendeur n'était pas aussi dérangée ... A chacun de ses post j'entend la petite musique de la quatrième dimension -+- AM in GNU-SE : La dimension de l'infiniment con -+-
Et du moment qu'il charge le microcode au boot sans faire planter les
nouveau processeurs intel, c'est tout bon.
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012)
et a été développé à cette fin :
https://www.kernel.org/doc/Documentation/x86/microcode.txt
Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par
défaut sur les distributions courantes.
--
Alors la ca dépasse l'entendemment, même clara dans sa splendeur
n'était pas aussi dérangée ... A chacun de ses post j'entend la
petite musique de la quatrième dimension
-+- AM in GNU-SE : La dimension de l'infiniment con -+-
Et du moment qu'il charge le microcode au boot sans faire planter les nouveau processeurs intel, c'est tout bon.
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012) et a été développé à cette fin : https://www.kernel.org/doc/Documentation/x86/microcode.txt Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par défaut sur les distributions courantes. -- Alors la ca dépasse l'entendemment, même clara dans sa splendeur n'était pas aussi dérangée ... A chacun de ses post j'entend la petite musique de la quatrième dimension -+- AM in GNU-SE : La dimension de l'infiniment con -+-
Pascal Hambourg
Le 30/12/2018 à 18:00, Eric Masson a écrit :
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012) Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par défaut sur les distributions courantes.
Je ne vois pas le rapport. La probabilité que ces failles soient exploitables dans les phases initiales du démarrage (avant le lancement de tout service ou programme dont l'exécution pourrait être influencée par un tiers) me paraît mince.
Le 30/12/2018 à 18:00, Eric Masson a écrit :
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012)
Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par
défaut sur les distributions courantes.
Je ne vois pas le rapport. La probabilité que ces failles soient
exploitables dans les phases initiales du démarrage (avant le lancement
de tout service ou programme dont l'exécution pourrait être influencée
par un tiers) me paraît mince.
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012) Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par défaut sur les distributions courantes.
Je ne vois pas le rapport. La probabilité que ces failles soient exploitables dans les phases initiales du démarrage (avant le lancement de tout service ou programme dont l'exécution pourrait être influencée par un tiers) me paraît mince.
Eric Masson
Pascal Hambourg writes: 'Re,
Je ne vois pas le rapport. La probabilité que ces failles soient exploitables dans les phases initiales du démarrage (avant le lancement de tout service ou programme dont l'exécution pourrait être influencée par un tiers) me paraît mince.
Je ne dis pas le contraire, je dis juste que le déploiement par défaut fait suite à ces failles alors que cela aurait pu être le cas depuis bien longtemps déjà. -- Mouarf ! Evidemment, aucune opération QuickDraw n'est jamais accélérée, et tous les petits pixels jusqu'au dernier sont dessiné par le p'tit G3 à la mimine. ;-) -+- Ol. in Guide du Macounet Pervers : Carte vidéo? Kesako? -+-
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
'Re,
Je ne vois pas le rapport. La probabilité que ces failles soient
exploitables dans les phases initiales du démarrage (avant le
lancement de tout service ou programme dont l'exécution pourrait être
influencée par un tiers) me paraît mince.
Je ne dis pas le contraire, je dis juste que le déploiement par défaut
fait suite à ces failles alors que cela aurait pu être le cas depuis
bien longtemps déjà.
--
Mouarf ! Evidemment, aucune opération QuickDraw n'est jamais accélérée,
et tous les petits pixels jusqu'au dernier sont dessiné par le p'tit G3
à la mimine. ;-)
-+- Ol. in Guide du Macounet Pervers : Carte vidéo? Kesako? -+-
Je ne vois pas le rapport. La probabilité que ces failles soient exploitables dans les phases initiales du démarrage (avant le lancement de tout service ou programme dont l'exécution pourrait être influencée par un tiers) me paraît mince.
Je ne dis pas le contraire, je dis juste que le déploiement par défaut fait suite à ces failles alors que cela aurait pu être le cas depuis bien longtemps déjà. -- Mouarf ! Evidemment, aucune opération QuickDraw n'est jamais accélérée, et tous les petits pixels jusqu'au dernier sont dessiné par le p'tit G3 à la mimine. ;-) -+- Ol. in Guide du Macounet Pervers : Carte vidéo? Kesako? -+-
Pascal Hambourg
Le 30/12/2018 à 20:11, Eric Masson a écrit :
Pascal Hambourg writes:
Je ne vois pas le rapport. La probabilité que ces failles soient exploitables dans les phases initiales du démarrage (avant le lancement de tout service ou programme dont l'exécution pourrait être influencée par un tiers) me paraît mince.
Je ne dis pas le contraire, je dis juste que le déploiement par défaut fait suite à ces failles alors que cela aurait pu être le cas depuis bien longtemps déjà.
Que veux-tu dire exactement par "déploiement par défaut" ? Cette fonctionnalité est présente dans Debian depuis plusieurs années.
Le 30/12/2018 à 20:11, Eric Masson a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
Je ne vois pas le rapport. La probabilité que ces failles soient
exploitables dans les phases initiales du démarrage (avant le
lancement de tout service ou programme dont l'exécution pourrait être
influencée par un tiers) me paraît mince.
Je ne dis pas le contraire, je dis juste que le déploiement par défaut
fait suite à ces failles alors que cela aurait pu être le cas depuis
bien longtemps déjà.
Que veux-tu dire exactement par "déploiement par défaut" ?
Cette fonctionnalité est présente dans Debian depuis plusieurs années.
Je ne vois pas le rapport. La probabilité que ces failles soient exploitables dans les phases initiales du démarrage (avant le lancement de tout service ou programme dont l'exécution pourrait être influencée par un tiers) me paraît mince.
Je ne dis pas le contraire, je dis juste que le déploiement par défaut fait suite à ces failles alors que cela aurait pu être le cas depuis bien longtemps déjà.
Que veux-tu dire exactement par "déploiement par défaut" ? Cette fonctionnalité est présente dans Debian depuis plusieurs années.
jp willm
Le 30/12/2018 à 18:00, Eric Masson a écrit :
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012) et a été développé à cette fin : https://www.kernel.org/doc/Documentation/x86/microcode.txt
Ok, j'ai vu. Donc, si j'ai bien compris, pour éviter à l'utilisateur final de recompiler le noyau on a au moins deux solutions : - les mainteneurs de la distribution fournissent un outil pour l'intégration automatique des microcodes dans l'image du noyau selon le matériel sur lequel est installé le système. - un chargeur de démarrage qui charge le microcode.img qui va bien avant initramfs.img. Si j'ai juste, alors pourquoi les gens de chez arch/manjaro préfèrent la seconde solution* à l'opposé des distributions debian et dérivés ? * Il va falloir que je leur pose la question. Pourquoi n'a-t-on pas encore trouvé de consensus à ce sujet ? Bon, je ne suis plus sur le bon groupe là...
Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par défaut sur les distributions courantes.
Sur Arch/Manjaro le microcode.img est chargé avant initramfs.img depuis un bon moment et en tout cas avant Spectre/Meltdown Désolé si je suis parfois à côté, car je ne suis pas informaticien :-/ -- jp willm http://perso.orange.fr/willms/index.html
Le 30/12/2018 à 18:00, Eric Masson a écrit :
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012)
et a été développé à cette fin :
https://www.kernel.org/doc/Documentation/x86/microcode.txt
Ok, j'ai vu.
Donc, si j'ai bien compris, pour éviter à l'utilisateur final de
recompiler le noyau on a au moins deux solutions :
- les mainteneurs de la distribution fournissent un outil pour
l'intégration automatique des microcodes dans l'image du noyau selon le
matériel sur lequel est installé le système.
- un chargeur de démarrage qui charge le microcode.img qui va bien
avant initramfs.img.
Si j'ai juste, alors pourquoi les gens de chez arch/manjaro préfèrent la
seconde solution* à l'opposé des distributions debian et dérivés ?
* Il va falloir que je leur pose la question.
Pourquoi n'a-t-on pas encore trouvé de consensus à ce sujet ?
Bon, je ne suis plus sur le bon groupe là...
Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par
défaut sur les distributions courantes.
Sur Arch/Manjaro le microcode.img est chargé avant initramfs.img depuis
un bon moment et en tout cas avant Spectre/Meltdown
Désolé si je suis parfois à côté, car je ne suis pas informaticien :-/
Le mécanisme, nommé "Early load microcode" n'est pas tout récent (2012) et a été développé à cette fin : https://www.kernel.org/doc/Documentation/x86/microcode.txt
Ok, j'ai vu. Donc, si j'ai bien compris, pour éviter à l'utilisateur final de recompiler le noyau on a au moins deux solutions : - les mainteneurs de la distribution fournissent un outil pour l'intégration automatique des microcodes dans l'image du noyau selon le matériel sur lequel est installé le système. - un chargeur de démarrage qui charge le microcode.img qui va bien avant initramfs.img. Si j'ai juste, alors pourquoi les gens de chez arch/manjaro préfèrent la seconde solution* à l'opposé des distributions debian et dérivés ? * Il va falloir que je leur pose la question. Pourquoi n'a-t-on pas encore trouvé de consensus à ce sujet ? Bon, je ne suis plus sur le bon groupe là...
Il aura fallu attendre Spectre/Meltdown pour que cela soit déployé par défaut sur les distributions courantes.
Sur Arch/Manjaro le microcode.img est chargé avant initramfs.img depuis un bon moment et en tout cas avant Spectre/Meltdown Désolé si je suis parfois à côté, car je ne suis pas informaticien :-/ -- jp willm http://perso.orange.fr/willms/index.html
Eric Masson
Pascal Hambourg writes: 'Lut,
Que veux-tu dire exactement par "déploiement par défaut" ?
Plus exactement que les distributions font maintenant état par défaut d'une fonctionnalité qui était plutôt planquée au fin fond des docs et utilisée en dernier recours pour résoudre des problèmes bien particuliers liés au CPU.
Cette fonctionnalité est présente dans Debian depuis plusieurs années.
Il faut quand même activer non-free et contrib, qui ne le sont pas par défaut. -- j'ai installé Corel Linux qui met un joli menu de boot avec des nimage mais a chque fois je suis obligé d'appuyer sur "MS-Windows" Résultat, j'ai plus le temps d'aller au toilettes après avoir lancé mon PC. -+- TTTT in GNU - PC : tu peux être fier des toilettes, Hue -+-
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
'Lut,
Que veux-tu dire exactement par "déploiement par défaut" ?
Plus exactement que les distributions font maintenant état par défaut
d'une fonctionnalité qui était plutôt planquée au fin fond des docs et
utilisée en dernier recours pour résoudre des problèmes bien
particuliers liés au CPU.
Cette fonctionnalité est présente dans Debian depuis plusieurs années.
Il faut quand même activer non-free et contrib, qui ne le sont pas par
défaut.
--
j'ai installé Corel Linux qui met un joli menu de boot avec des nimage
mais a chque fois je suis obligé d'appuyer sur "MS-Windows" Résultat,
j'ai plus le temps d'aller au toilettes après avoir lancé mon PC.
-+- TTTT in GNU - PC : tu peux être fier des toilettes, Hue -+-
Que veux-tu dire exactement par "déploiement par défaut" ?
Plus exactement que les distributions font maintenant état par défaut d'une fonctionnalité qui était plutôt planquée au fin fond des docs et utilisée en dernier recours pour résoudre des problèmes bien particuliers liés au CPU.
Cette fonctionnalité est présente dans Debian depuis plusieurs années.
Il faut quand même activer non-free et contrib, qui ne le sont pas par défaut. -- j'ai installé Corel Linux qui met un joli menu de boot avec des nimage mais a chque fois je suis obligé d'appuyer sur "MS-Windows" Résultat, j'ai plus le temps d'aller au toilettes après avoir lancé mon PC. -+- TTTT in GNU - PC : tu peux être fier des toilettes, Hue -+-
Pascal Hambourg
Le 31/12/2018 à 10:50, jp willm a écrit :
Donc, si j'ai bien compris, pour éviter à l'utilisateur final de recompiler le noyau on a au moins deux solutions : - les mainteneurs de la distribution fournissent un outil pour l'intégration automatique des microcodes dans l'image du noyau
Tu veux dire dans l'initrd/initramfs ? Pour intégrer les microcodes dans l'image du noyau, il faut précisément reconstruire cette dernière.
- un chargeur de démarrage qui charge le microcode.img qui va bien avant initramfs.img. Si j'ai juste, alors pourquoi les gens de chez arch/manjaro préfèrent la seconde solution* à l'opposé des distributions debian et dérivés ? * Il va falloir que je leur pose la question.
Oui. Le seul avantage que j'y vois est que cela ne nécessite pas de prise en charge des microcodes par le générateur d'initrd. Mais en contrepartie cela nécessite une prise en charge par le chargeur d'amorçage, ce qui est pire à mon avis.
Pourquoi n'a-t-on pas encore trouvé de consensus à ce sujet ?
S'il y avait consensus entre les distributions sur quoi que ce soit, ça se saurait. C'est pour ça que les distributions existent, pour que chacun soit libre de faire ses propres choix.
Le 31/12/2018 à 10:50, jp willm a écrit :
Donc, si j'ai bien compris, pour éviter à l'utilisateur final de
recompiler le noyau on a au moins deux solutions :
- les mainteneurs de la distribution fournissent un outil pour
l'intégration automatique des microcodes dans l'image du noyau
Tu veux dire dans l'initrd/initramfs ? Pour intégrer les microcodes dans
l'image du noyau, il faut précisément reconstruire cette dernière.
- un chargeur de démarrage qui charge le microcode.img qui va bien
avant initramfs.img.
Si j'ai juste, alors pourquoi les gens de chez arch/manjaro préfèrent la
seconde solution* à l'opposé des distributions debian et dérivés ?
* Il va falloir que je leur pose la question.
Oui. Le seul avantage que j'y vois est que cela ne nécessite pas de
prise en charge des microcodes par le générateur d'initrd. Mais en
contrepartie cela nécessite une prise en charge par le chargeur
d'amorçage, ce qui est pire à mon avis.
Pourquoi n'a-t-on pas encore trouvé de consensus à ce sujet ?
S'il y avait consensus entre les distributions sur quoi que ce soit, ça
se saurait. C'est pour ça que les distributions existent, pour que
chacun soit libre de faire ses propres choix.
Donc, si j'ai bien compris, pour éviter à l'utilisateur final de recompiler le noyau on a au moins deux solutions : - les mainteneurs de la distribution fournissent un outil pour l'intégration automatique des microcodes dans l'image du noyau
Tu veux dire dans l'initrd/initramfs ? Pour intégrer les microcodes dans l'image du noyau, il faut précisément reconstruire cette dernière.
- un chargeur de démarrage qui charge le microcode.img qui va bien avant initramfs.img. Si j'ai juste, alors pourquoi les gens de chez arch/manjaro préfèrent la seconde solution* à l'opposé des distributions debian et dérivés ? * Il va falloir que je leur pose la question.
Oui. Le seul avantage que j'y vois est que cela ne nécessite pas de prise en charge des microcodes par le générateur d'initrd. Mais en contrepartie cela nécessite une prise en charge par le chargeur d'amorçage, ce qui est pire à mon avis.
Pourquoi n'a-t-on pas encore trouvé de consensus à ce sujet ?
S'il y avait consensus entre les distributions sur quoi que ce soit, ça se saurait. C'est pour ça que les distributions existent, pour que chacun soit libre de faire ses propres choix.
