Forum-Francophone-LinuxMint.fr

Bonjour à toutes et à tous.

Mon Asus R700V étant non accepté pour windows 11, je viens de tester linux mint, une bonne découverte!
Seulement, quand j'ai booté la première fois sur une clé usb créée avec Rufus, j'ai interrompu l'installation croyant qu'il ne se passait rien étant donné que je ne voyais pas de progression. Au deuxième démarrage sur la clé je reçois ce message d'erreur "failed to open efi boot mmx64.efi".

En suivant un post sur ce message d'erreur, je suis le conseil d'un utilisateur qui indique de changer le nom du fichier grubx64.efi en mmx64.efi dans le répertoire /EFI/BOOT. J'ai eu ensuite ce message d'erreur:
"error: shim_lock protocol not found.
error: you need to load the kernel first.

Press any key to continue..."
Un autre forum indique alors de désactiver le secure boot pour contourner ce problème, ce que je fait et qui permet de lancer de nouveau Linux mint et l'installer sur mon disque.

Je suis novice en informatique et du coup me pose la question du bien fondé de ces manipulations en terme de sécurité. Linux en tout cas démarre bien suite à la réactivation du secure boot, mais ma question est de savoir si j'ai bien fait de suivre ces forums? Y a t'il un moyen de vérifier la sécurité de mon installation?

Merci d'avance pour vos aides

Bonjour Cyrille,

d'abord merci pour la réponse. Elle rejoint la manip que j'ai faite. Cependant, le fait de modifier ces fichiers liés à la sécurité ne pose pas de problèmes?

Bonjour Laulau.

Si c'est la désactivation de secure boot qui t'inquiète, non ça ne nuit pas à la sécurité.
C'est pour t'empêcher d'installer des logiciels non agréés par M$. Ce qui de mon point de vue n'est pas un gage de sécurité. Un logiciel Linux sera toujours plus sécure qu'un logiciel agréé par M$

Bonjour Alain, merci à toi aussi pour ta réponse! j'ai lu que la communauté Linux était réactive, et franchement pour mon premier post ça se confirme!
Ca donne encore plus envie de s'éloigner de Windows....

En tout cas pour être précis, ce qui m'inquiétait en plus de la désactivation du sécure boot est le fait de renommer le fichier grubx64.efi en mmx64.efi. Je ne connais rien à tout ça, notamment l'utilité de ces fichiers, donc le risque de les renommer, le risque de corrompre l'intégrité de l'OS

Je ne connais pas grand-chose sur les différentes interdictions imposées par Microsoft.
Mais à relire ton premier message, je pense que si tu avais désactivé le secureboot avant de modifier grubx64.efi en mmx64.efi, tu n'aurais pas eu à le faire.

Mais cela dépend tellement des bios que je ne peux pas te le garantir à 100%.

Comme tu as pu installer et que c'est qu'au second démarrage que tu as eu "failed to open efi boot mmx64.efi", je pense même que tu aurais dû avoir à le faire avec le secureboot désactivé.

A mon avis, ton ordinateur a dû être installé avec une version OEM de windows qui a installé une clé MOK quelque part dans ton bios (dans le secureboot?) MOK= Machine Owner Key ou clé du propriétaire de la machine. Cette clé interdit l'installation de système d'exploitation, de pilotes (Nvidia et certains wifi) et de certains logiciels comme Virtual Box et certainement beaucoup d'autres.

Voilà pourquoi je pense que si le secureboot avait été désactivé dès le départ, tu n'aurais pas dû avoir ce message, mais là où ma théorie tombe à l'eau, tu n'aurais pas pu installer ton linux. Quoique Linux Mint a été généreusement autorisé par microsoft avec son secureboot.
À moins ! À moins... Qu'après ton premier démarrage tu aies essayé d'installer un pilote ou un logiciel "interdit" (par microsoft) ? . Cela expliquerait pourquoi il t'a dit "failed to open efi boot mmx64.efi" il cherchait la clé pour ce que tu avais installé.

Ces pratiques de microsoft étant illégales en Europe, microsoft a été obligé de permettre la désactivation du secureboot. Mais comme ils ne sont pas à court d'idées, ils ont inventé la clé MOK qui est tout autant interdite. Ce qui fait qu'ils autorisent le renommage du fichier grubx64.efi en mmx64.efi . C'est exactement le même sauf qu'il a un nom différent, du coup ce nom utilisé pour un chargeur signé Microsoft (Shim), reconnu par l’UEFI te laisse installer n'importe quel OS, pilote, etc... En fait ça fait croire au programme de démarrage que tu as du 100% microsoft.

À me relire, j'ai l'impression de ne pas être très clair, mais l'important à savoir c'est que ces différentes interdictions imposées par microsoft n'ajoutent aucune autre sécurité à part la sécurité d'utiliser uniquement les logiciels reconnus par microsoft. Et comme je te le disais plus haut, pour moi, ça serait plus un gage d'insécurité. Donc aucune inquiétude à avoir, d'autant plus qu'en ce qui concerne grubx64.efi et mmx64.efi, ce sont exactement les mêmes fichiers, il n'y a que le nom qui change. Tu es obligé de mettre mmx64.efi, car c'est le nom que le system attend pour démarrer et non grubx64.efi. Ce nom de mmx64.efi viendrait de : " Microsoft Management x64 EFI ", mais les avis sont partagés, microsoft ne communiquant rien sur ses magouilles.

Je pense que la plupart des pays se sont alignés sur l'UE pour interdire ce genre de pratique, c'est pour cela que microsoft permet (contraint et forcé) de les contourner. Alors pourquoi ne pas les virer carrément, vas-tu me dire ? Je pense que peut être cela arrange certains pays ? Mais surtout que ça décourage beaucoup de gens voulant passer sous Linux. Ce n'est déjà pas facile de changer de système d'exploitation, si en plus, il faut faire des recherches pour faire sauter ces interdictions, pas toujours claires et solutions différentes suivant les bios, ça décourage beaucoup de monde. Toi, tu as persévéré, c'est bien . Mais combien de windowsiens iront jusqu'au bout des recherches que tu as faites ?

PS: Je viens de voir que je n'ai pas répondu à une de tes questions :

Laulau a écrit : mer. 16 avr. 2025 22:27 le fichier grubx64.efi en mmx64.efi. Je ne connais rien à tout ça, notamment l'utilité de ces fichiers

C'est le programme de démarrage qui est installé dans la partition boot EFI dans le cas d'un bios UEFI.
Le fait de le renommer ne change rien à son contenu, en revanche le bios UEFI, dans ton cas, cherchait le programme de démarrage qu'i s'appelle mmx64.efi et comme le tient s'appelait grubx64.efi, il ne le trouvait pas. cqfd....

alain a écrit : jeu. 17 avr. 2025 02:23À me relire, j'ai l'impression de ne pas être très clair...

C'est parfaitement clair, mais ce qui l'est beaucoup moins c'est la raison pour laquelle les fabricants de cartes-mère ont laissé Microsoft faire ce qu'il voulait dans l'UEFI !

Ce post très intéressant montre bien que c'est loin d'être gagné pour installer une distribution Linux sur un ordinateur récent ( équipé de tous les verrous et blocages voulus par Microsoft) et que c'est souvent très efficace pour dégoûter quelqu'un d'installer un autre OS que Windows, d'autant plus qu'il y a autant de problèmes différents que de méthodes diverses à mettre en œuvre suivant les marques d'ordis et les versions de leur BIOS!
On ne peut pas malheureusement faire pire pour freiner le passage de Windows 10 à Linux! Après un essai raté, le gars va acheter un ordi neuf et balance son ancien ordi " dépassé"...
Je réalise souvent des installations sur des ordis différents et je désactive systématiquement le Secure Boot ( et je ne le réactive pas par la suite)

capdeframint a écrit : jeu. 17 avr. 2025 11:53Après un essai raté, le gars va acheter un ordi neuf et balance son ancien ordi " dépassé"...

Je doute franchement que les PC de toute entrée de gamme avec Windows 11 soient capables de tourner correctement.

@Nerva: c'est même une évidence qu'une config basique, très légère mais ayant des composants qui acceptent Windows 11, sera vite à l'agonie alors qu'une config solide, seulement compatible avec Windows 10, ferait bien mieux l'affaire si Microsoft la rendait compatible avec la version 11 mais surtout elle fera une excellente config pour une installation de Linux.
Mais pour cela il faudrait que les BIOS soient moins verrouillés, juste pour emmerder le monde...

Nerva a écrit : jeu. 17 avr. 2025 11:09 C'est parfaitement clair, mais ce qui l'est beaucoup moins c'est la raison pour laquelle les fabricants de cartes-mère ont laissé Microsoft faire ce qu'il voulait dans l'UEFI !

Histoires de gros sous, certainement