Universal MBR/GPT Support
.eric Posted messages 1386 Registration date Status Member Last intervention -
Hello everyone :D,
I have had a somewhat crazy project in my mind for several years. The idea is to create a bootable medium, like a USB key, that would boot independently of the BIOS/UEFI boot system.
Indeed, some older machines can only boot from MBR media, while recent ones have the option to boot from GPT and "legacy" (or CMS) BIOS. However, to switch from one to the other, you need to modify it in the UEFI interface.
As I understand it, for a GPT medium booted by a UEFI system, the first sector read is a "protective" MBR, a sort of classic MBR whose routine (Master Boot Code) is ignored and which defines a single partition (source). See also Understanding the protective MBR in GPT-partitioned disks. Part 1.
I'm not sure what an MBR routine can do (probably whatever we want), but in the case of a "protective" MBR, couldn't we modify it to achieve the same outcome as a BIOS does by pointing to the "correct" boot partition? Even if it means executing other code located elsewhere on the medium to extend its physical limits of 446 bytes.
Thus, assuming I have created a GPT partition table on my USB medium, with the "right-modification," if I boot it from a UEFI machine, the GPT will be recognized (the routine ignored) and everything will work as expected, and if I boot it from a BIOS machine, the modified routine will act as if I were booting a BIOS.
I’m not sure if I’m being clear, if it’s conceptually possible and not too complicated to implement (perhaps a solution already exists elsewhere). And if it’s not possible, what are the blockages and why? What about security?
If someone experienced can shed light on the subject that I don't really master, I would be very grateful.
With brotherly love,
lnj
I have questions about all your answers. (Woody Allen)
Knowledge and ideas belong to everyone (noosphere)!
3 answers
-
Hello,
The question does not arise with an ISO and a CD reader (provided one has one), which shows that the issue is more about booting the USB stick than the operating system itself.
The question largely depends on how the USB stick is created; it is impossible with Rufus, and some sources, which I haven't verified, say that Ventoy would bypass the partition table of the USB stick, otherwise it relates to a special preparation of the installation medium that needs to be partitioned, see for example for Windows 10 and Ubuntu.
https://answers.microsoft.com/fr-fr/windows/forum/all/tutoriel-sur-la-cr%C3%A9ation-dun-support/d5b8312e-e7f6-435d-aee7-548d099b6fe2https://askubuntu.com/questions/1015709/mbr-or-gpt-partition-when-making-ubuntu-bootable-live-usb
Generally speaking, there is a "subtlety" between an installation USB stick and a Live USB.
The latter does not initially install the OS on the disk, so one can assume that a number of Linux family Live USBs will work regardless of the partition table of the disk and then allow, if a real installation is done (Ubuntu, Linux Mint...), to choose the appropriate partition table.-
Hello Brucine, and thank you for your reply :D,
The procedure for Windows 10 that you are suggesting tends to confirm my intuition about the possibility of creating "universal" media (it's funny that the author of the procedure uses the same term) that won't be dependent on BIOS/UEFI settings.
I will try to test/simulate it in virtualization because I am on Linux and don't have Windows available.
The goal I am aiming for is to have a single large "tools" USB key instead of having around 15 like I currently do.
In particular, I am looking to create a universal bootable Clonezilla USB media to be able to back up/restore and repair systems, independent of the 32/64-bit hardware architecture and independent of the BIOS/UEFI boot system.
For the Clonezilla media, I just tested and confirmed that the MBR is identical whether for a 32 or 64-bit architecture (under Linux, hexdump shows identical sequences except for the disk signature, since each creation gives a different identifier). Now I will try to integrate them into a single installation.
If I can create such media, I will need to manage to create a system analogous to that of the universal Windows 10 installation, and for that, I don't know how to do it.Hello,
As I illustrated, the procedure seems more or less OS-dependent (different for Windows 10 and Ubuntu).
On the USB stick, it seems to be more related to its partitioning than to its partition table, even if it means multiplying the existing partitions.
A long time ago, more for fun than anything else, I created something like this on a 2 Go USB stick (on one hand, we didn't have much choice, and on the other hand, a larger size would have prevented Ms Dos from booting) that multibooted Ms Dos 7, Network DOS, Puppy Linux, and Bart PE, but it required all sorts of tricks.
Essentially Hitachi for the USB stick to be recognized as a hard drive, partitioning utility like Gparted, utility to write the boot sectors (mkbt), cascading Grub and Syslinux menu including making the last one bootable, strict order to follow so that the various ones don’t overwrite each other...
It's no longer very relevant since there's no way to create Bart PE in 64 bits anymore; it just illustrates the relative difficulties, and I can put the tutorial online just for the example.
Nowadays, a Ventoy USB stick will surely be more flexible if it allows several heterogeneous images outside the partition table.
In short, unless you have a lot of time to waste and for glory, you’d surely be better off making a set of different USB sticks.Other sources report that in this regard, Easy2boot would be even more tolerant than Ventoy, which it actually includes; I have never tried it.
https://easy2boot.xyz/Seen from the other side of the lens, most Linux distros don’t care whether it’s UEFI or MBR, and the installer makes an "intelligent choice"; to simplify, the problem then is only that of the architecture if the target is an old 32-bit machine.
So this is a typically Windows problem, and not even: here too, recent machines and Windows versions don’t really leave a choice, it’s almost always UEFI in 64 bits; theoretically, the problem should only exist here as well depending on the architecture for Windows 10, which is rarely in 32 bits but why not, and not at all before since, unless I’m mistaken, Windows 7 and earlier don’t want to hear about UEFI.
-
-
Hello
MBR or GPT is "disk partitioning", it's physical.
Each disk can only be one type at a time.
The table used will correspond only to one of the two types.
_______
The "subtlety" of a live-only session is that the operating system is not on any physical media; more precisely, it runs mainly in RAM which can disappear during a power cut, using the various available media anyway but without being defined as necessarily physically attached to one of them on a single partition permanently. It can record, or not at all, what happens during a live session. There is indeed a read source for the system files, but if there is a backup it can be planned beforehand (sometimes on the CD disk, a recording following the previous ones, or not yet and left to the user's creativity during a new installation with new media).
__________
Windows is not as universal as that. It becomes indispensable by preventing others from acting; that's more what happens.
It manages disks privately, for itself, potentially makes space available for another system alongside it, but it monitors that, and is not always as flexible or capable of performing certain actions as, for example, Linux. It puts on brakes, that's for sure, and often annoying.
-
Hello,
The question is not about whether it is physical, which is actually not true; it's only about how to set up a disk that, depending on the case, will be booted by MBR or by an EFI partition.
The question is whether a USB drive can contain multiple types of installers depending on whether the disk partition table is MBR or GPT, or if the drive is empty, offer one or the other (as is the case with certain Linux distros) and whether the architecture is 32 or 64 bits.
In the case of a disk that is not empty (or is empty but where the BIOS has such an imperative), we should theoretically be able to run a script from the USB key that will detect it and choose the appropriate installer accordingly or, less difficultly, a bit like in the example of the multiboot key I mentioned, do it from Ventoy or easy2boot and from a manual menu where the user will execute among all the ISO files on this drive the one that corresponds to the situation.
-
-
-Request for a "tool" that would not depend on the partition table, and independently of the BIOS/UEFI boot system.
> For me, the answer was "live systems"; Linux or Win PE do this or have done this, there are only 32 or 64 bits that are imposed by the processor, previously in 32 bits, now in 64 bits. It is hardware in the processor, very recent or very old.
"Generally speaking, there is a "subtlety" between an installation key and a Live USB.
The latter does not initially install the OS on the disk, so we can assume that a number of Live USB from the Linux family will work independently of the disk partition table, that's true." Brucine's demonstration."Most Linux distros do not care whether it's UEFI or MBR, and the installer makes an "intelligent choice"; to simplify, the problem then only concerns the architecture if the target is an old 32-bit machine." Brucine's demonstration.
"With plenty of ISOs on a "tool," we adapt to the situation. (Ventoy or easy2boot)." Brucine's demonstration.
"The question does not arise with an ISO and a CD drive (provided you have one), which shows that the question is more about the booting of the key than the operating system itself." Brucine's demonstration.
> It's Windows that has "removed" the ability to validate a system like PE on a simple CD, for example; Linux does not block all distributions "on a computer". Windows nearly did the same for several months with GO, but retracted, then nearly proposed Linux alongside Windows 11, perhaps in early 2025, the tutorials barely released did not work anymore, a different direction in the evolution of Windows 11 made this solution disappear?
Imposed condition for the tool:
"to create a bootable medium, such as a USB key, that would boot independently of the BIOS/UEFI boot system."
It seems that "the booting question" is only imposed if we are looking for "a support disk accessible as a key or USB disk," we did not have the problem with the CD/DVD drive, for example, we do not have the issue with "live" distributions in RAM, we solve the problem on servers everywhere where we rent the equivalent computing power billed in "CPU," "graphics card," "RAM," and "storage volume in GB or TB," with named operating systems installed on servers, even Windows 11 with each license paid belonging to the company that "rents computing in the cloud."
If it weren't for the issues of "inconvenience," "having numerous ISOs that correspond to the situation," "not the same for an old 32-bit or a recent 64-bit," we already have the solution, we lift each time the difficulty by a workaround, already with the keys and now with external hard drives multi-ISOs under Ventoy or easy2boot, there are many participants already working with these tools it seems with of course precautions, remote work in "private networks" with their clients, etc., and often a complete PC in addition to the "key" or "USB disk" alone, which further reduces the interest in these "portable OS without PC around."
But as Brucine said, if we do it a bit for glory and take the necessary time, we should already be able to fill a nice collection of "portable" tools since the word exists for programs specially adapted to this itinerant functionality.
We might also be losing the ability to boot from USB keys or USB disks, for security reasons on many devices. We no longer boot as easily any operating systems present on any key that we plug in.
Here too, the cause does not come from the support that would not be "universal."
