Support "universel" MBR/GPT
.eric Messages postés 989 Date d'inscription Statut Membre Dernière intervention -
Bonjour à tout.e.s :D,
J'ai depuis plusieurs années, un projet un peu fou qui me taraude l'esprit. Celui de créer un support amorçable, telle une clé USB, qui serait amorcée indépendamment du système d'amorçage BIOS/UEFI.
En effet, certaines vielles machines ne peuvent amorcer que les supports MBR alors que les récentes ont la possibilité d'amorcer GPT et BIOS "hérité" (legacy ou CMS), mais pour basculer de l'un à l'autre, il faut aller le modifier dans l'interface UEFI.
Comme je comprends les choses, pour un support GPT amorcé par un système UEFI, le premier secteur lu est un MBR "protecteur", sorte de MBR classique dont la routine (Master Boot Code) est ignorée et qui définit une unique partition (source). Voir aussi Comprendre le MBR de protection dans les disques partitionnés en GPT. Partie 1.
Je ne suis pas sûr de ce que peut faire une routine MBR (sans doute ce qu'on veut), mais dans le cas d'un MBR "protecteur" ne pourrait-on pas la modifier pour obtenir la même finalité que ce que fait un BIOS en le faisant pointer sur la "bonne" partition d'amorçage ? Quitte à la faire exécuter un autre code situé ailleurs sur le support et ce pour étendre ses limites physiques de 446 octets.
Ainsi, en supposant que j'ai créé une table de partition GPT sur mon support USB, avec la "modification-qui-va-bien", si je l'amorce depuis une machine avec UEFI, le GPT sera reconnu (la routine ignorée) et tout fonctionnera comme attendu et si je l'amorce depuis une machine BIOS, la routine modifiée fera comme si je faisais un amorçage BIOS.
Je ne sais pas si je suis clair, si c'est conceptuellement possible et pas trop compliqué à implémenter (peut être que la solution existe déjà toute faite par ailleurs). Et si ce n'est pas possible, qu'est ce qui est bloquant et pourquoi ? Quid de la sécurité ?
Si quelqu'un d'expérimenté peut m'éclairer sur le sujet que je ne maîtrise pas vraiment, je lui en serais très reconnaissant.
Avec adelphité,
lnj
Linux / Firefox 115.0
- Mbr vs gpt
- Udp vs tcp - Guide
- Gat gpt - Accueil - Guide Intelligence artificielle
- Chat gpt gratuit - Télécharger - Outils Internet
- Mac gpt - Accueil - Guide Intelligence artificielle
- Comment aller à la ligne sur chat gpt ✓ - Forum MacOS
3 réponses
Bonjour,
La question ne se pose pas avec un ISO et un lecteur de CD (à condition d'en avoir un) ce qui montre que la question tient davantage à l'amorçage de la clé qu'au système d'exploitation lui-même.
La question tient largement au mode de création de la clé; c'est impossible avec Rufus, certaines sources, je n'ai pas vérifié, disent que Ventoy outrepasserait la table de partitions de la clé, sans quoi elle tient à une préparation spéciale du support d'installation qui doit être partitionné, voir par exemple pour Windows 10 et Ubuntu.
https://answers.microsoft.com/fr-fr/windows/forum/all/tutoriel-sur-la-cr%C3%A9ation-dun-support/d5b8312e-e7f6-435d-aee7-548d099b6fe2
https://askubuntu.com/questions/1015709/mbr-or-gpt-partition-when-making-ubuntu-bootable-live-usb
D'une manière générale, il y a une "subtilité" entre une clé d'installation et une Live USB.
Cette dernière n'installe pas dans un premier temps l'OS sur le disque, on peut donc supposer qu'un certain nombre de Live USB de la famille Linux vont fonctionner indépendamment de la table de partitions du disque puis permettre, si on y fait l'installation réelle (Ubuntu, Linux Mint...) de choisir la table de partitions qui convient.
Bonjour
MBR ou GPT c'est du "partitionnement de disque", du physique.
Chaque disque ne peut être que d'un seul type à la fois.
La table utilisée ne correspondra qu'à un des 2 types.
_______
La "subtilité" d'une session live only, c'est que le système d'exploitation n'est sur aucun support physique, plus exactement il tourne principalement en RAM qui peut disparaître lors d'une coupure de courant, utilisant les différents supports disponibles quand même mais sans être défini comme obligatoirement attaché physiquement à l'un d'eux sur une seule partition définitivement. IL peut enregistrer, ou pas du tout ce qui se passe pendant une session live. Il y a donc bien une source en lecture des fichiers systèmes mais si sauvegarde il y a elle peut être prévue à la base avant (parfois sur le disque cd, un enregistrement à la suite des précédents, ou pas encore et laissée à la créativité de l'utilisateur lors d'une nouvelle installation avec nouveau support).
__________
Windows n'est pas si universel que ça. Il arrive a se rendre indispensable en empêchant les autres d'agir c'est plus cela qui se produit.
Il gère les disques en privé, pour lui, met éventuellement de la place à disposition d'un autre système à côté de lui, mais qu'il surveille, et n'est pas toujours ni aussi souple ni aussi capable de faire certaines actions que par exemple linux. Il met des freins c'est sur, et souvent gênants.
Bonjour,
La question n'est pas de savoir si c'est du physique ce qui n'est d'ailleurs pas vrai, il s'agit seulement d'agencer un disque qui selon le cas sera amorcé par MBR ou par une partition EFI.
Elle est de savoir si un support USB peut comporter plusieurs types d'installateurs selon que la table de partitions du disque est MBR ou GPT ou si le support est vierge proposer l'un ou l'autre (c'est le cas de certaines distro Linux) et que l'architecture est 32 ou 64 bits.
Dans le cas d'un disque qui n'est pas vierge (ou qui l'est mais où le Bios a tel impératif), on devrait alors théoriquement pouvoir exécuter à partir de la clé USB un script qui le détectera et choisira l'installateur approprié en conséquence ou moins difficilement, un peu comme dans l'exemple de clé multiboot que j'ai évoqué, le faire à partir de Ventoy ou easy2boot et d'un menu manuel où l'utilisateur exécutera parmi tous les ISO sur ce support celui correspondant à la situation.
-Demande "outil" qui ne dépendrait pas de la table de partition, et indépendamment du système d'amorçage BIOS/UEFI.
> pour moi la réponse c'était bien "les systèmes en live" linux ou win bart pe le font ou l'ont fait, il n'y a plus que 32 ou 64 bits qui sont imposés par le processeur, avant en 32 bits, maintenant en 64 bits. C'est matériel dans le processeur, très récent ou très ancien.
"D'une manière générale, il y a une "subtilité" entre une clé d'installation et une Live USB.
Cette dernière n'installe pas dans un premier temps l'OS sur le disque, on peut donc supposer qu'un certain nombre de Live USB de la famille Linux vont fonctionner indépendamment de la table de partitions du disque, c'est vrai." Démonstration brucine.
"la plupart des distros Linux se fichent de savoir si c'est de l'UEFI ou du MBR et l'installateur fait un "choix intelligent"; pour schématiser, le problème n'est alors que celui de l'architecture si la cible est une machine ancienne en 32 bits." Démonstration brucine.
"Avec plein de isos sur un "outil" on s'adapte à la situation. (Ventoy ou easy2boot)". Démonstration brucine.
"La question ne se pose pas avec un ISO et un lecteur de CD (à condition d'en avoir un) ce qui montre que la question tient davantage à l'amorçage de la clé qu'au système d'exploitation lui-même." Démonstration brucine.
>C'est windows qui a "supprimé" la possibilité de valider un système comme pe sur un simple cd par exemple; linux ne bloque pas toutes les distributions "sur un ordinateur". Windows a failli faire de même pendant quelques mois avec GO, mais s'est rétracté, puis a failli proposer linux à côté de windows11 peut-être en début 2025, les tutos à peine sortis ils n'ont plus marché, une orientation différente dans l'évolution de windows 11 a fait disparaître cette solution?
Condition imposée à l'outil:
"créer un support amorçable, telle une clé USB, qui serait amorcée indépendamment du système d'amorçage BIOS/UEFI."
Il semble que "la question d'amorçage" n'est imposée que si on cherche un "disque support accessible en clé ou disque USB", on n'avait pas le problème avec le lecteur de cd/dvd par exemple, on n'a pas le problème avec les distributions "live" en ram, on résout le problème sur les serveurs partout où on loue de l'équivalent puissance de calcul facturé en "CPU", "carte graphique" "Ram" et "volume de stockage en Go ou To", avec des systèmes d'exploitations nominatifs installés sur des serveurs, même windows 11 avec chacun sa licence payée appartenant à la société qui "loue de l'informatique dans le cloud".
Si ce n'était pas les questions de "pas pratique", "mettre des isos nombreux qui correspondent à la situation", "pas le même pour un ancien 32 bits ou un récent 64 bits", on a déjà la solution, on lève chaque fois la difficulté par un contournement, déjà avec les clés et maintenant les disques durs externes multi-ISOS sous ventoy ou easy2boot, il y a de nombreux intervenants qui travaillent déjà avec ces outils il me semble avec bien sur des précautions, travail à distance en "réseaux privés" avec leurs clients etc. et souvent un pc complet en plus de la "clé" ou du "disque usb" seuls, ce qui enlève encore un peu d'intérêt à ces "os transportables de poche sans pc autour".
Mais comme dit brucine si on le fait un peu pour la gloire et en mettant le temps nécessaire on doit déjà pouvoir remplir une belle collection d'outils "portables" puisque le mot existe pour des programmes spécialement adaptés à ce fonctionnement itinérant.
On nous enlève peut-être aussi les démarrages depuis clés usb ou disques usb, pour des raisons de sécurité sur beaucoup d'appareils. On ne démarre plus aussi facilement les systèmes d'exploitation qui sont sur n'importe quelle clé que l'on branche.
Là aussi la cause ne vient pas du support qui ne serait pas "universel".
Salut Brucine et merci pour ta réponse :D,
La procédure pour Windows 10 que tu me proposes tend à confirmer l'intuition que j'ai, quand à la possibilité de pouvoir créer des supports "universels" (c'est marrant l'auteur de la procédure utilise le même terme) qui ne seront pas dépendants des réglages BIOS/UEFI.
Je vais essayer de la tester/simuler en virtualisation car je suis sous Linux et n'ai pas de Windows à disposition.
Le but que je vise c'est d'avoir une unique grosse clé USB "outils" au lieu d'en avoir une 15aine comme actuellement.
En particulier je cherche à créer un support USB amorçable Clonezilla universel pour pouvoir sauvegarder/restaurer et réparer des systèmes et ce indépendamment de l'architecture matérielle 32/64 bits et indépendamment du système d'amorçage BIOS/UEFI.
Pour le support Clonezilla, je viens de tester et confirmer que le MBR est identique que ce soit pour une architecture 32 ou 64 bits (sous Linux hexdump affiche des séquences identiques sauf pour la signature de disque, puisque chaque création donne un identifiant différent). Maintenant je vais essayer de les intégrer dans une même installation.
Si j'arrive à créer un tel support, il faudra que j'arrive enfin à créer un système analogue à celui de l'installation universelle Windows 10 et pour ça je ne sais pas comment faire.
Bonjour,
Comme j'ai illustré, la procédure semble plus ou moins OS dépendante (différente pour Windows 10 et Ubuntu).
Sur la clé, elle semble plus tenir à son partitionnement qu'à sa table de partitions quitte à y multiplier les partitions qui y existent.
Dans un temps jadis et plus pour le fun qu'autre chose, j'avais réalisé sur une clé de seulement 2 Go (d'une part on n'avait pas trop le choix et d'autre part plus gros
Ms Dos n'aurait pas démarré) quelque chose de ce genre qui multibootait
Ms Dos 7, Dos pour les réseaux, Puppy Linux et Bart PE mais ce qui réclame toutes sortes d'artifices.
Schématiquement Hitachi pour que la clé soit vue comme un disque dur, utilitaire de partitionnement type Gparted, utilitaire pour écrire les secteurs de démarrage (mkbt), menu en cascade Grub et Syslinux y compris rendre le dernier bootable, ordre à respecter strictement pour que les uns n'écrasent pas les autres...
Ce n'est plus très pertinent puisqu'il n'y a plus aucun moyen de créer Bart PE en 64 bits, cela se contente d'en illustrer les relatives difficultés, je veux bien te mettre le tuto en ligne seulement donc pour l'exemple.
De nos jours, une clé Ventoy sera sûrement plus souple si elle autorise plusieurs images hétéroclites en dehors de la table de partitions.
Bref, à moins que tu aies beaucoup de temps à perdre et pour la gloire, tu as sûrement plus vite fait de réaliser un jeu de différentes clés USB.
D'autres sources rapportent qu'à cet égard Easy2boot serait encore plus tolérant que Ventoy que d'ailleurs il inclut, je n'ai jamais goûté.
https://easy2boot.xyz/
Vu de l'autre côté de la lorgnette, la plupart des distros Linux se fichent de savoir si c'est de l'UEFI ou du MBR et l'installateur fait un "choix intelligent"; pour schématiser, le problème n'est alors que celui de l'architecture si la cible est une machine ancienne en 32 bits.
C'est donc un problème typiquement Windows, et même pas: là aussi, les machines et versions Windows récentes ne laissent plus vraiment le choix, c'est quasiment toujours de l'UEFI en 64 bits; le problème ne devrait théoriquement exister là aussi qu'en fonction de l'architecture pour Windows 10 rarement en 32 bits mais pourquoi pas, et pas du tout avant puisque sauf erreur de ma part Windows 7 et précédents ne veulent pas entendre parler d'UEFI.