[RESOLU] Installation de Linux Mint 21 sous UEFI (avec un ordi HP)

[Glenic1]

Merci Charlinux
Mais je patauge encore entre le guide d'installation et la réalité quand j'ouvre le terminal sur mon ordi.
C'est que d'après le guide, il faut en passer par qqes lignes de commande.
Toujours d'après le guide, il suffirait de vérifier l'authenticité du fameux fichier SHA256sum.txt pour être rassuré sur l'authenticité de l'image ISO
Pourquoi pas ?
Mais je n'arrive pas à obtenir la bonne réponse indiquée par le guide quand je tape la ligne de commande indiquée :
gpg --verify sha256sum.txt.gpg sha256sum.txt
Le terminal me répond qu'il ne trouve aucun fichier sha256sum.txt.gpg
Bref, le parcours du combattant informatique continue

[Glenic1]

On progresse, mais dans le flou !

Reprise de la vérification de l'authenticité de l'image ISO téléchargée sur le site LinuxMint.com
Téléchargement des 2 fameux fichiers :
sha256sum.txt
et
sha256sum.txt.gpg
Ces 2 fichiers atterrissent tels quels dans le dossier Téléchargements de mon ordinateur.
J'ouvre le terminal (facile puisque je travaille sur mon Acer 7630, déjà équipé de Linux)
J'importe la clef de signature LinuxMint en recopiant la ligne de commande indiquée dans le guide

Code : Tout sélectionner

gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-key "27DE B156 44C6 B3CF 3BD7  D291 300F 846B A25B AE09"

et en la collant dans le terminal.
Voici le résultat

2022-09-10_importation de la clef de signature LinuxMint.png (38.44 Kio) Vu 2129 fois

C'est agaçant de ne pas comprendre ce qu'on fait (ou plutôt ce que fait l'ordinateur), mais enfin passons puisque on obtient une mention rassurante :
"la clef de signature n'est pas modifiée"
Passons maintenant à la 2ème étape préconisée par le guide :
après avoir appliqué la ligne de commande

Code : Tout sélectionner

gpg --verify sha256sum.txt.gpg sha256sum.txt

on doit obtenir la mention la signature du fichier est bonne et elle a été faite avec la clef A25BAE09
Avant de coller la ligne de commande ci-dessus, récupérée sur le guide d'installation, il faut prendre soin de placer le terminal sur le bon répertoire.
C'est l'usage de la commande

Code : Tout sélectionner

cd Téléchargements

Et voici la réponse :

2022-09-10_authenticité image ISO LinuxMint 21.png (59.04 Kio) Vu 2129 fois

Conclusion : la mention Bonne signature de « Linux Mint ISO Signing Key <root@linuxmint.com> » [inconnu] est plutôt rassurante.
Mais les lignes qui suivent :
Attention : cette clef n'est pas certifiée avec une signature de confiance.
Rien n'indique que la signature appartient à son propriétaire.
sont plutôt inquiétantes.
On va quand même considérer que c'est tout bon et on va passer au stade suivant : créer une clef de boot avec Rufus.
A bientôt

[maxoxo]

Merci Charlinux
Mais je patauge encore entre le guide d'installation et la réalité quand j'ouvre le terminal sur mon ordi.
C'est que d'après le guide, il faut en passer par qqes lignes de commande.
Toujours d'après le guide, il suffirait de vérifier l'authenticité du fameux fichier SHA256sum.txt pour être rassuré sur l'authenticité de l'image ISO
Pourquoi pas ?
Mais je n'arrive pas à obtenir la bonne réponse indiquée par le guide quand je tape la ligne de commande indiquée :
gpg --verify sha256sum.txt.gpg sha256sum.txt
Le terminal me répond qu'il ne trouve aucun fichier sha256sum.txt.gpg
Bref, le parcours du combattant informatique continue

Salut,

Tu as deux fichiers à télécharger depuis le mirroir officiel : sha256sum.txt et sha256sum.txt.gpg.

Il faut faire clic droit puis "Enregistrer la cible du lien sous" dans le menu. Si tu cliques juste sur le fichier Firefox va afficher le contenu du fichier.

Ensuite, tout dépend de ce que tu veux faire : sha256sum.txt sert à vérifier l'intégrité du fichier ISO téléchargé. Le fichier sha256sum.txt.gpg sert quant à lui à assurer l'authenticité du premier fichier sha256sum.txt. Hé oui, comment faire confiance à la somme de contrôle fournie si on ne peut pas vérifier sa provenance ? On peut contrôler le fichier par rapport à la somme de contrôle, mais elle pourrait très bien venir d'une source compromise. On aurait donc un fichier parfaitement conforme à la source compromise. C'est bête et méchant l'informatique

L'idée c'est d'avoir ton fichier ISO et ces deux fichiers de contrôle dans le mémoire répertoire. Tu l'ouvres depuis un terminal et tu peux ensuite faire

1. Pour vérifier l'intégrité du fichier ISO :

Code : Tout sélectionner

$ sha256sum -b linuxmint-21-xfce-64bit.iso

Cela va donc comparer le fichier ISO téléchargé avec la somme de contrôle dans le fichier sha256sum.txt

Quand tu commences à taper une commande, tu peux utiliser la touche TAB pour activer la complétion dans le Terminal. Il complétera tout seul le nom de la commande ou du fichier. Par exemple, ici si tu commences juste à taper linuxm que tu appuies sur TAB il écrira le nom du fichier. Si plusieurs solutions sont possibles, il suffit d'appuyer plusieurs fois sur TAB jusqu'à trouver la bonne. Ça permet d'aller beaucoup plus vite dans la saisie des commandes.


Cela va donc comparer le fichier ISO téléchargé avec la somme de contrôle dans le fichier sha256sum.txt

2. Pour vérifier l'authenticité du fichier ISO et de sa somme de contrôle

On a vérifié que le fichier ISO était intègre, mais nous avons ici seulement vérifié que le fichier ISO et la somme de contrôle téléchargés depuis le mirroir étaient conformes entre eux. Comme il y a plusieurs mirroirs, à ce stade, rien ne nous prouve que le fichier et donc sa somme de contrôle sha256 sont bien ceux fournis par Linux Mint.

Pour ça il faut vérifier l'authenticité grâce à une signature GPG.

Pour commencer il est nécessaire d'importer la clé PGP de Linux Mint depuis le serveur de clés (ils utilisent celui d'Ubuntu qui est public) :

Code : Tout sélectionner

gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-key "27DE B156 44C6 B3CF 3BD7  D291 300F 846B A25B AE09"

Puis :

Code : Tout sélectionner

gpg --verify sha256sum.txt.gpg sha256sum.txt

Ces commandes doivent toujours être exécutées depuis le répertoire où se situe les 3 fichiers : linuxmint-21-xfce-64bit.iso, sha256sum.txt et sha256sum.txt.gpg.


Là tout devrait fonctionner, on a tout vérifié et nous sommes en sécurité.

PS : C'est une excellente pratique de vérifier, après personnellement, quand je suis sur des sources officielles je ne prends pas toujours le temps de le faire. Le risque est acceptable pour un particulier. Pour une administration ou une entreprise avec des choses sensibles, je ne tiendrais pas le même discours. Concrètement, si la chaîne d'approvisionnement de Mint est compromise, on le saura bien assez vite.

[maxoxo]

Et voici la réponse :
2022-09-10_authenticité image ISO LinuxMint 21.png
Conclusion : la mention Bonne signature de « Linux Mint ISO Signing Key <root@linuxmint.com> » [inconnu] est plutôt rassurante.
Mais les lignes qui suivent :
Attention : cette clef n'est pas certifiée avec une signature de confiance.
Rien n'indique que la signature appartient à son propriétaire.
sont plutôt inquiétantes.
On va quand même considérer que c'est tout bon et on va passer au stade suivant : créer une clef de boot avec Rufus.
A bientôt

Mince j'ai chargé mon brouillon sans m'apercevoir que tu avais déjà réussi et posté un nouveau message. Désolé, si mon message n'est pas utile, tu peux supprimer.

Pour le message d'avertissement, Linux Mint indique eux-mêmes dans le guide que tu auras cet avertissement et que c'est normal (bon ça ne l'est pas vraiment mais bon...)

Je cite le guide accessible ici : https://linuxmint-installation-guide.re ... erify.html

GPG might warn you that the Linux Mint signature is not trusted by your computer. This is expected and perfectly normal.

L'explication tient au fonctionnement de GPG qui est décentralisé et ne fait pas référence à des autorités de certification de confiance et reconnues comme telles par tous le systèmes. Du coup, localement ton ordinateur t'indique qu'il ne sait pas s'il doit faire confiance à la clé GPG que tu as importée. Tu pourrais lui dire manuellement qu'elle est de confiance.
Normalement quand on importe une clé GPG sur un système, nous sommes censés la certifier en vérifiant auprès de son détenteur légitime que l'empreinte est bien celle de sa clé publique. Ici, ça va être difficile de vérifier auprès des développeurs de Mint

Du coup, effectivement, pour un puriste de la sécurité c'est une hérésie. Car là, tu as un site Internet qui te dit que la bonne empreinte est

Code : Tout sélectionner

27DE B156 44C6 B3CF 3BD7 D291 300F 846B A25B AE09

Un pirate pourrait très bien diffuser une clé avec cette empreinte et modifier le site pour te dire que c'est la bonne.

Cependant, il y a ici un aspect raisonnable dans le contrôle de sécurité. Pour compromettre l'ISO, il faudrait donc que les pirates réussissent plusieurs choses complexes. D'abord compromettre l'ISO, puis fournir une somme de contrôle correspondant à l'ISO piratée (et il faudrait arriver à le faire sur tous les miroirs). Ensuite il faudrait réussir à diffuser une clé GPG
non légitime, puis enfin pirater le site de documentation de Linux Mint pour donner la mauvaise empreinte. Ça fait beaucoup !

Ces contrôles ne sont pas anodins. En 2016, les mirroirs de Mint avaient été corrompus et des ISOS vérolées avaient été distribuées (voir https://blog.linuxmint.com/?p=2994). D'où ces procédures de vérification qui permettent de limiter les risques (mais comme je le disais, aujourd'hui depuis une source officielle, le risque est désormais limité).

[Glenic1]

Merci Maxoxo d'avoir confirmé que la certification de mon image ISO était correcte (intégrité + authenticité).
Effectivement, je n'avais pas fait le lien entre la phrase inquiétante en français à l'issue de la vérification et le commentaire en anglais sur le site LinuxMint.com qui avertissait sur cette bizarrerie.

Donc, maintenant que mon image ISO est certifiée, en avant pour la transformer en clef de boot compatible UEFI via Rufus !

Merci également pour le lien vers le blog.linuxmint.com
J'ai été lire la page indiquée. C'est édifiant même si le piratage était très limité. Cela rejoint les doutes sur la sécurité des systèmes Linux que tu as déjà exprimées dans ces colonnes !
Face à ces doutes il y a des précautions à prendre et tout se passe bien !

[Glenic1]

Hello,
Après une pause, je reprends le circuit pour arriver à installer LinuxMint 21.
J'en suis à l'étape "Rufus" pour fabriquer ma clef de boot (voir le post de Maxoxo du 28 août et celui de Charlinux du 7 septembre plus haut dans ce sujet).
Voici ce que donne l'écran de contrôle de Rufus

2022-09-20_Rufus.ie.jpg (376.06 Kio) Vu 2055 fois

Je suis perplexe !

De haut en bas :
- Le périphérique est le bon. Ma clef USB avec l'image ISO a été correctement détectée par Rufus.
- je suppose que la méthode de démarrage est la bonne. Il fallait choisir entre "image disque" et "ISO". Perso je ne vois pas la différence puisque on parle bien d'une "image ISO". En cliquant sur le bouton "sélection", j'ai pu choisir le nom du fichier tel qu'il figure sur la clef USB
- taille de partition persistente : ?????? (bref, passons)
- schéma de partition : que choisir entre MBR et GPT les 2 options proposées ????
- système de destination : contrairement à ce qu'a dit Maxoxo dans son post du 28 août, l'option "UEFI" (seul) n'est pas disponible. Peut-on se contenter du seul choix affiché : "BIOS ou UEFI" ?
- je passe sur les "options de périphérique avancées" qui paraissent être utiles seulement dans les cas particuliers. Il y a par exemple une option "compatibilité pour vieux BIOS"

Pour les options de formatage :
- le nom du volume, attribué automatiquement par Rufus, me convient. Je le laisse tel quel.
- l'option de formatage est posée en FAT 32 par défaut. Mais NFTS est aussi disponible. Faut-il tenter NFTS ? En principe, c'est mieux que FAT 32
- taille d'unité d'allocation : il y a plusieurs choix possibles. Je vais laisser la valeur par défaut de 8 192 octets, puisque je ne vois pas quel est l'intérêt de choisir une autre valeur.

Dans les options de formatage avancées, il y a 3 lignes :
- formatage rapide (pré-coché)
- ajouter un label étendu et une icône (pré-coché) -> pourquoi pas ? je laisse la case cochée
- vérification de mauvais blocs en 1 passe ou en plusieurs. Je coche cette case par sécurité et je laisse la vérification se faire en une seule passe.

Mais à ce stade la barre sous le mot "statut" est encore de couleur grise. L'opération n'est pas prête.

Il y a une dernière astuce : il faut cliquer sur la coche située entre le type de démarrage et le bouton "sélection"

Ce clic déclenche un (nouveau) contrôle du SHA256 ! !

Le résultat est aussi sibyllin que dans la méthode de contrôle indiquée par Linux Mint : la somme de contrôle s'affiche et Rufus nous invite à cliquer sur "OK". On voit pas d'indication comme quoi le contrôle est correct....

Une fois le bouton OK cliqué, le statut de la clef USB passe au vert. Il n'y a plus qu'à appuyer sur le bouton "démarrer"

Ce n'est pas l'envie qui m'en manque ce soir mais je vais quand même attendre vos avis sur les options proposées.
Je déplore qu'il n'y ait pas de manuel d'aide concernant les différentes options proposées.
Heureusement que le forum permet les échanges à distance sur ces questions !

[maxoxo]

Salut,

Quelques réponses après quote

- je suppose que la méthode de démarrage est la bonne. Il fallait choisir entre "image disque" et "ISO". Perso je ne vois pas la différence puisque on parle bien d'une "image ISO". En cliquant sur le bouton "sélection", j'ai pu choisir le nom du fichier tel qu'il figure sur la clef USB

Oui c'est bon. C'est bien ISO qu'il faut que tu prennes. Je crois que pour l'image disque il attend un fichier en format .IMG

- taille de partition persistente : ?????? (bref, passons)

Pas utile dans ton cas. Cela permet de créer une partition sur la clé USB qui servira à du stockage persistant. Par exemple, si tu utilises le système en Live-USB, tu ne peux rien sauvegarder, les données sont perdues à chaque reboot. Cette partition persistante sert donc à permettre de stocker des éléments que tu retrouveras à chaque utilisation "Live".

- schéma de partition : que choisir entre MBR et GPT ????
- système de destination : contrairement à ce qu'a dit Maxoxo dans son post du 28 août, l'option "UEFI" (seul) n'est pas disponible. Peut-on se contenter de "BIOS ou UEFI" ?

MBR (Master Boot Record) = Ancien format de table de partitions qui fonctionne nativement sur les systèmes BIOS (donc non UEFI). Il contient un secteur d'amorçage (le secteur 0) qui contient le bootloader (chargeur d'amorçage, GRUB dans ton cas). C'est mécanique, le BIOS est bête il sait seulement amorcer électriquement un périphérique mais est incapable de choisir quelle partition il faut démarrer. C'est la raison pour laquelle on installe un programme sur le premier secteur du disque afin qu'il s'exécute directement après le BIOS et soit capable de choisir la bonne partition à démarrer celle qui contient l'OS donc. Le format MBR est limité : on ne peut pas gérer des disques de plus de 2To et on ne peut pas avoir plus de 4 partitions primaires (partitions que l'on peut directement amorcer).

GPT (GUUID Partition Table) = Le nouveau format de table de partitions qui est arrivé avec UEFI. Il n'a pas de limitations, on peut avoir autant de partitions primaires que l'on veut et il peut gérer des disques de très très très grande taille (je ne sais plus quelle est la limite, mais je crois qu'elle en exaoctets ! ). UEFI sait exploiter directement ce format de partitions et il est capable de choisir directement une partition à démarrer sans avoir besoin d'installer un chargeur d'amorçage supplémentaire (contrairement au MBR qui nécessite obligatoirement que le chargeur d'amorçage soit sur le secteur 0). Le GPT facilite donc le multiboot car on peut configurer les partitions à l'envie et gérer plusieurs chargeurs d'amorçage si on veut.
UEFI gère nativement le GPT tandis que le BIOS n'en est pas capable (sans une configuration très complexe pour créer un environnement hybride MBR puis GPT, un truc sans intérêt à l'heure actuelle).

Je pense que pour avoir le mode UEFI uniquement, il faut mettre "Schéma de partition" sur GPT. Maintenant, ça n'a pas grand sens ici puisqu'il s'agit de la clé d'installation. UEFI sait gérer du MBR donc Rufus propose un mode de compatibilité "BIOS ou UEFI". En théorie ta clé devrait être capable de faire les deux. C'est donc toi qui choisira au démarrage si tu travailles en UEFI ou en BIOS à l'ancienne (mode appelé CSM).

[Glenic1]

Merci Maxoxo pour ces précisions qui manquent sur le site de Rufus.
Je vais maintenant pouvoir créer ma clef de boot LinuxMint 21 sans risquer de m'égarer dans les options.

[Glenic1]

Les ennuis continuent....
Après avoir mouliné pendant 2 bonnes heures, Rufus affiche une "belle" barre rouge avec le mot "échec".
D'après la boite de dialogue, Rufus ne pouvait pas accéder au fichier car l'explorateur Windows était ouvert sur ce fichier.

Je croyais que la clef était "entamée" et devait être reprise pour y coller une nouvelle fois l'image ISO de LinuxMint 21 mais apparemment il n'en est rien.
J'ai repris le processus Rufus au début après avoir ré-inséré la clef et on recommence !
Je déconnecte de suite l'explorateur Windows bien sûr.

Résultat dans 2 heures environ...

[Glenic1]

Bonjour,
Rufus s'est arrêté en cours de route pour cause de découverte d'un secteur défectueux sur la clef.
Ce matin, la clef USB est réellement inutilisable et il faut tout reprendre à zéro : téléchargement de l'image ISO, etc....
(quant à Windows 10, il se porte très bien.....)