🚲 Tanguy Ortolo a écrit 12224 commentaires

Sauf quand, justement, tu veux refaire la même recherche sur un autre moteur, ou en la modifiant un peu, auquel cas tu dois la saisir à nouveau intégralement.

La zone de recherche intégrée à la barre d'adresse, c'est bon pour ceux qui font d'un coup la bonne requête, sur le bon moteur.

De démarrer dessus en EFI, j'entends. En BIOS, ça marchera sans problème, vu que ça n'utilise pas du tout la partition système EFI.

Et le moment venu ils basculeront sur le nouveau truc à la mode

Ce qui leur prendra quoi, dix minutes ? Multiplié par le nombre total d'utilisateurs dans le monde, ça fait des années, peut-être des siècles de temps qui ne serait pas perdu si ce changement n'était pas nécessaire.

Non, je sais bien comment ça se passe, je l'ai constaté avec des trucs comme MSN Messenger ou Myspace. Mais ça ne change rien à mon propos, chacun de ces changements coûte énormément de temps à l'ensemble des gens.

Oh, GRUB s'y installera sans doute, mais le PC sera incapable de démarrer là-dessus.

Si, c'est un problème, qui se manifeste à chaque fois que l'un de ces services ferme ou tombe en désuétude, ce qui fait perdre un temps énorme cumulé à tout le monde.

En revanche, je ne m'inquiète pas tant que ça pour l'hégémonie de certains acteurs en temps que telle, parce qu'elle ne dure pas, tous ces services finissent tôt ou tard par disparaître d'une façon ou d'une autre, contrairement aux services ouverts, qui perdurent. L'important est pour moi que les gens aient les possibilité de communiquer sur des services ouverts, qu'ils ne le fassent pas est un peu secondaire : le jour où ils en auront besoin, ils pourront toujours le faire.

Par contre, certains fichiers ISO nécessitent une écriture particulière dans le menuentry du fichier de config grub.cfg.

C'est simplement pour que GRUB les monte pour pouvoir aller y lire le noyau et l'initrd qui sont dedans.

Note que, si ça permet bien de charger noyau et initrd, ça ne permet réellement de lancer un système que si celui-ci a été prévu pour cet usage. En effet, l'initrd va demander au noyau de charger un système de fichiers où est installé tout le système d'exploitation, et pour ça, il doit pouvoir le trouver. Si le système, ou plus précisément son initrd, n'a pas été prévu pour être ainsi utilisé avec une image ISO, il cherchera un disque optique, ne trouvera pas, et affichera un beau message d'erreur. S'il a été prévu pour cela, il cherchera soit un disque optique, qu'il ne trouvera pas, soit une clef USB, qu'il trouvera, puis sur laquelle il cherchera une image ISO, qu'il utilisera pour cela.

Si mon PC a un système BIOS classique, je boot sur la 1ère partition ? du nom de bios !

Non. Un BIOS ne démarre pas sur une partition, il ne sait même pas ce que c'est. Il démarre sur un périphérique, qui contient dans sa MBR du code de démarrage. Avec GRUB, ce code de démarrage contient de quoi aller immédiatement exécuter un code situé ailleurs :

• en partitionnement MBR pur, dans l'espace interstitiel entre la MBR et la première partition ;
• en partitionnement GPT, dans une partition dédiée à cela.

Si mon PC a un système EFI, je boot sur la 2ème partition ? du nom de EFI !

Là, pour le coup, EFI sait ce que c'est qu'une partition. Quand on lui demande de démarrer sur un périphérique amovible, il va chercher dedans une partition de type “EFI system partition”, lit son système de fichiers (s'il le prend en charge, sinon c'est mort, donc n'essaie pas de faire des partitions système EFI en Ext2, ça ne sera certainement pas pris en charge) et y cherche un fichier nommé /efi/boot/boot<platform>.efi, c'est à dire dans le cas le plus courant bootx64.efi, pour l'exécuter.

Alors, à quoi sert la 3ème partition sur laquelle ils installent grub?

À rien.

Bah, comme pour les systèmes précédents, jusqu'au jour où ça fermera. Notez l'utilisation du futur et non du conditionnel.

Donc si je comprends bien, la manip faite sous arch linux concerne les BIOS type BIOS et EFI.
L'OS supporté avec toutes ces partitions est linux, non windows.

En effet.

Heu, !! On se fou de savoir si windows sait lire toutes les partitions puisqu'on utilise la clé au démarrage seulement.

Elle ne sera pas utilisée qu'au démarrage, mais également lors de l'utilisation du système que tu auras ainsi démarré, évidemment.

Donc la partition distri en ext2 et le tour est joué alors !?

Ça dépend, quel tour ? Si tu parles de l'étape inutile d'installation de GRUB sur l'espace réservé d'une partition, oui, si elle est en Ext2, ça marchera, mais comme ça ne sert à rien, ce n'est pas la peine de te fatiguer avec ça.

À mon avis, c'est un peu trop prosélyte comme ton, notamment dans des passages comme :

La communauté des hackers, féru de liberté et d'autonomie des utilisateurs et des peuples de la terre a de son côté, calmement, développé une technologie décentralisée, XMPP [2], normalisé comme standard ouvert par l’IETF, l’organisation de normalisation des protocoles de l’Internet.
[…]
Mais ! aucune des ces sociétés privées n'a pu résister à la tentation de pervertir leur usage du standard. Ils ont chacun modifié leurs codes source privateurs et ils ont fermé leurs différents réseaux centralisés. Les utilisateurs de chacun de ces différents réseaux sont ainsi isolés des autres réseaux.

Mieux vaut à mon avis insister sur le fait que tous les services centralisés passent, que ceux qu'ils ont déjà utilisés ont fermé, que ceux qu'ils utilisent aujourd'hui fermeront tôt où tard, et que seuls subsistent les services ouverts, dont le meilleur exemple est le courrier électronique.

Ce n'est pas tout à fait ça, c'était plutôt :

• Ils font pas ça.
• Roh ! Les nuls !
• En fait ils le font peut être, mais s'ils le font, ils ne l'indiquent aucunement.
• Roh ! Les nuls !

Et là, je maintiens. Utiliser un standard ouvert sans le dire, et en développant un truc propriétaire pour cela, qui donnerait vraiment l'impression qu'on n'utilise rien de standard, ce n'est pas grave, c'est seulement très con. Mais bon, ce n'est pas ce qu'ils font de toute façon.

Et pour le coup, non, je ne fais pas de jugement de délit de faciès pour StartCom. Je me serais réjoui de voir une autre autorité tirer parti du protocole ACME, et si continuer dans l'idée de l'automatisation est une excellente chose, je trouve affligeant de développer dans son coin un truc incompatible.

Vivement qu'une autre autorité de certification fasse de même, mais correctement, cette fois.

Ben non, désolé, mais quand il y a un standard qui a été conçu de façon ouverte, avec un souci de permettre la concurrence, et qu'en réaction, plutôt que de l'utiliser, quitte à l'étendre ou à le faire évoluer, on fait un truc incompatible dans son coin, ça s'appelle le syndrome NIH.

Et quand, dans le même contexte, on utilise ce standard — c'est l'hypothèse la moins affligeante, mais ce n'est pas le cas, cf. https://news.ycombinator.com/item?id=11903513 — en codant un client propriétaire et sans même mentionner qu'on utilise un standard, ce qui serait pratique pour développer des usages innovants, c'est une ingratitude tout à fait débile.

Bah ils l’utilisent peut-être (c’est ce que je ferais à leur place, à mon avis c’est la meilleure réaction que pourrait avoir une CA traditionnelle qui se sentirait menacée par Let’s Encrypt), mais au vu de ce qu’ils disent on n’en sait rien du tout.

Ben, si par hasard ils l'utilisent sans le dire, ce sont des boulets aussi. Quand on utilise un truc standard, on ne le cache pas !

Et pour relancer le même recherche, un peu modifier pour l'affiner ? Il faudrait aussi que ça permette de la récupérer pour l'éditer : ce serait parfait, mais j'ai du mal à imaginer comment un truc pareil pourrait être intégré à la zone d'adresse.

Pas la peine de te fatiguer, comme le mentionne ce tutoriel de façon un peu laconique et simplifiée, Windows est incapable de lire plusieurs partitions sur un périphérique externe, et s'arrêtera à la première. Quoi que tu fasse, toutes les autres seront inaccessibles depuis ce système d'exploitation, il est donc inutile d'essayer de les adapter, ça ne changera rien.

C'est ce qui a été fait :

sudo grub2-install --target=i386-pc --boot-directory=/mnt/DISTRI/boot --recheck /dev/sdc && sync

Parfait. Ça installer l'exécutable de GRUB sur la partition que tu as dédiée à cela, puis ça installe dans la MBR un code qui demande au BIOS de l'exécuter.

Mais dans la partition DISTRI, je ne suis pas sur que grub2 trouve tout seul les .iso que je vais mettre dans /DISTRI/_ISO/.

Ça c'est sûr, il ne les trouvera pas « tout seul ». GRUB n'est pas un outil magique, il fait ce que tu lui dit, et il est certes capable de lire le contenu d'une image de système de fichiers, mais encore faut-il le lui demander.

C'est bête mais j'ai déjà installé grub avec cette ligne :

sudo grub2-install --target=x86_64-efi --efi-directory=/mnt/EFI --boot-directory=/mnt/DISTRI/boot --removable --recheck && sync

Tu as effectivement déjà installer GRUB pour UEFI, ce qui a mis l'exécutable correspondant dans /mnt/EFI, où je suppose que tu avais montée la partition système EFI que tu avais définie et formatée précédemment. Il est normal de devoir utiliser une seconde commande pour installer GRUB pour BIOS (autrement dit GRUB PC), si tu veux que ta clef soit démarrable sur les deux systèmes.

Pourquoi ne pas installer lancer cette ligne de la même manière? (--boot-directory=/mnt/DISTRI/boot)

sudo grub2-install --target=i386-pc --boot-directory=/mnt/DISTRI/boot --removable --recheck && sync

Parce que, là où GRUB EFI s'installer sur le système de fichiers d'un partition système EFI (--efi-directory=/mnt/EFI), GRUB PC s'installer sur un périphérique complet (/dev/sdc).

Il faut modifier le fichier grub.cfg mais ou le modifier aussi, …

Alors là, ça va dépendre de ce que tu veux faire. À ce niveau de personnalisation de clef USB démarrable, il faut vraiment que tu te familiarise avec le fonctionnement de GRUB et sa configuration.

Dans DISTRI, j'ai le dossier grub2 avec :
-dossier fonts
-fichier grubenv
-dossier i386-pc
-locale
-x86_64-efi

C'est normal, même si je trouve vraiment affreux de mettre ça dans …/DISTRI plutôt que le standard …/boot.

Elle sert à embarqué des OS sous format ISO.

Non, elle ne sert pas à ça. Vraiment, ça n'a rien à voir.

Pourquoi elle ne sert à rien du tout?

Parce que, elle installe GRUB en début de partition, dans un espace non utilisé par le système de fichiers, du moins elle le ferait si le système de fichier en question était prévu pour cela, ce qui n'est pas le cas avec FAT. Et que, à moins d'utiliser ensuite un micro-chargeur de démarrage qui va charger ce code, cette installation sera tout simplement inutilisée.

*4ème partition : 4,7 Go DISTRIBUTION type FAT32 => permet de lancer plusieurs distributions avec grub2

Au fait, pourquoi FAT 32 ? Cette partition n'est pas destinée à être utilisée sous Windows, et il devrait sembler évident que FAT 32 n'est pas le système de fichier idéal pour travailler sous Linux, tant il est déficient (pas de liens symboliques, notamment).

Pour info, si tu avais utilisé quelque chose comme Ext2, ta dernière commande, d'installation de GRUB embarqué dans une partition, aurait correctement fonctionné, bien qu'elle ne serve en pratique à rien du tout.

Le système FAT32 n'est pas supporté par GRUB?

Non, en tout cas pas pour y embarquer GRUB. J'explique. Pour pouvoir être chargé au démarrage par un BIOS, GRUB doit être écrit quelque part sur le périphérique, de façon linéaire. Traditionnellement, il s'installait ainsi dans l'espace interstitiel situé entre la MBR et la première partition. Ce n'est pas possible avec un partitionnement GPT, où cet espace n'existe pas, c'est pourquoi il faut alors dédier une partition à GRUB, ce que tu as fait.

l existe une autre alternative, qui consiste à l'embarquer dans une zone dédiée à cela dans un système de fichier prévu pour cet usage, c'est à dire un système de fichier qui laisse volontairement sur sa partition une zone qu'il n'utilisera pas. Avec ta commande grub-install […] /dev/sdc4, c'est ce que tu essaies de faire, sans doute par erreur : installer GRUB dans un espace libre sur /dev/sdc4. Sauf que cette partition est formatée en FAT, et que le système de fichiers FAT n'a pas de zone réservée à cet usage, d'où :

grub2-install : attention : Le système de fichiers « fat » ne prend pas en charge l'embarquage.

Il y a une autre possibilité, qui consiste à installer GRUB comme un fichier, qui peut donc très bien se retrouver sur le périphérique en plusieurs blocs non adjacents, et qui ne pourra donc pas être chargé tel quel par le BIOS. Il faut ensuite déterminer les adresses de ces blocs, et créer un code qui demande au BIOS de charger ces blocs. Cette méthode utilise une liste de blocs, et c'est effectivement moins fiable, donc refusé par GRUB par défaut :

grub2-install : attention : L'embarquage est impossible. GRUB ne peut être installé sur cette configuration qu'en utilisant les listes de blocs. Cependant, les listes de blocs ne sont PAS fiables et leur utilisation est déconseillée..
grub2-install : erreur : refus de continuer avec les listes de blocs.

Il faut donc que tu utilises la méthode standard, en demandant à GRUB de s'installer sur ta clef, et non pas sur une partition, avec un grub-install /dev/sdc. Il trouvera tout seul la partition que tu lui as dédiée, et s'y installera sans problème.

Aussi, que signifie le système de fichier EF02 et EF00?

Ce ne sont pas des systèmes de fichiers, mais des types de partition, ou plus exactement, des identifiants utilisés par les outils de partitionnement GPT fdisk pour désigner les types de partition suivants :

• EFI system partition : c'est ce qui indique qu'une partition donnée doit être prise en compte par l'UEFI de la carte mère, qui va chercher à y lire un système de fichiers FAT (ou éventuellement autre chose qu'elle prendrait en charge, comme un HFS+ chez Apple) pour y chercher un fichier à exécuter comme chargeur de démarrage. Dans ton cas, cette partition sera formatée en FAT 32 et contiendra l'exécutable principal de GRUB.
• BIOS boot partition : c'est ce qui indique à un chargeur de démarrage pour BIOS qu'il peut s'y installer. C'est nécessaire parce qu'en partitionnement MBR, ou dans la MBR de compatibilité d'une GPT, la place pour le code de démarrage est réduite à 512 octets, ce qui est insuffisant pour y placer quelque chose comme GRUB. Avec une pure MBR, il y a un espace interstitiel entre la table de partition et la première partition, où GRUB peut aller installer son code. En revanche, avec une GPT, cet espace n'existe pas et il est donc nécessaire de dédier une partition à cet usage. À noter que cette partition n'est pas destinée à être formatée, GRUB ira simplement y écrire linérairement son code, sans système de fichier.

Ce n'est pas cela que je reproche à une zone d'adresse et de recherche unifiée, mais l'impossibilité de rejouer une recherche dans un moteur différent sans avoir à la saisir à nouveau, puisqu'elle aura été remplacée par une URL.

Relis mon second paragraphe, qui répond exactement à ton objection :

Je vois venir une objection évidente : la zone d'URL peut très bien proposer une recherche sur plusieurs moteurs. Sauf que, une fois la recherche effectuée, on se retrouve sur une page dont l'adresse a remplacé les termes de la recherche, et par conséquent, si on s'aperçoit que la carte OpenStreetMap du village de Saint-Mathieu-en-Cambrousse n'a pas les noms des rues, pour rechercher le même endroit sur Yahoo! Maps, on doit saisir à nouveau la recherche. Alors qu'avec la zone de recherche dédiée, pour relancer la recherche, il suffit de retourner dans celle-ci, qui contient toujours les termes de la recherche, et de la relancer sur un autre moteur.

Je ne sais pas quel est le problème chez toi, mais Let's Encrypt émet sans problème des certificats pour plusieurs noms de domaine, même servis par un serveur qui n'a qu'une seul adresse IP publique.

Personnellement je développe des interfaces web, et j'utilise le JavaScript, et pas uniquement pour "embellir" l'interface (ajouter des effets qui améliore l'expérience utilisateur (UX pour les intimes)), mais également pour récupérer des données JSON san devoir recharger toute l'interface.

Pour que ça « aille plus vite » en somme ? C'est amusant, parce qu'en désactivant JavaScript, ça ne va généralement pas plus lentement, plutôt beaucoup, beaucoup plus vite.