I have a system that has an option in the BIOS to choose boot type as "BIOS" or "UEFI". When I choose "BIOS" I can boot to DOS without problems. When I choose "UEFI" I can boot to an EFI startup.nsh script without problems. I can't however boot to DOS from the "UEFI" boot selection.

My question is: Is there any way to boot to DOS while having the option in the BIOS set to "UEFI"?

I have played around with grub for a while but I have found that it does not have full BIOS emulation. Apparently, "fakebios" and "loadbios" options are simple emulations to work around video card issues. They do not work in this case.

  • 4
    DOS? Which version? I am not aware of a UEFI-aware version of MS-DOS, but I cannot speak for the other clones out there.
    – user3463
    Jul 18, 2012 at 22:49
  • @Randolph - Just MS-DOS. I guess I don't know enough about UEFI, I was hoping that there would be some way to fool UEFI into booting MS-DOS. It sounds like that is not a possibility due to how EFI and DOS are structured.
    – Greg G.
    Jul 19, 2012 at 14:04
  • Out of curiosity, what do you want to use DOS for?
    – nitro2k01
    Oct 27, 2013 at 6:31

5 Answers 5


No, it is not possible to boot to DOS while the option is set to "UEFI". Only UEFI compliant operating systems can be booted with this option.


This is sort of an oxymoron. There are two standards for disk partition tables, MS-DOS and U/EFI. The older one is MS-DOS, the newer one is UEFI.

The old partition table type came with several serious shortcomings, the most famous of which is the inability to use disks larger than 2TiB. This comes from the fact that it uses 32-bit addresses to identify 512-byte sectors. The product of the two is 2TiB, the largest disk that you can use with this kind of partition table.

There are of course other limitations: Only 3 primary partitions, only 59 logical partitions, only one copy of the partition table (at the beginning of the disk, in the MBR), structured as a linked list which is obviously quite prone to corruption, the use of old-fashioned CHS (cylinder-Head-Ssector).

In order to overcome these problems, the GPT partition table has been introduced, as part of Intel's UEFI. The GPT overcomes all of these problems (for instance, there are two copies of the table, at the beginning and at the end of the disk, it allows the partitioning of much much larger disks, up to 9.4 ZiB, uses Logical Block Addressing LBA instead of CHS, has only primary partitions, up to 128).

The information of the partition table is store in a structure at the beginning of the disk, preceded by the Primary partition header (this is also replicated for redundancy at the end of the disk). This structure is new: it did not exist in the old MS-DOS partition table.

However, for safety reasons, this structure is preceded by a legacy MBR, i.e., the structure defining the partition table in the old MS-DOS scheme. This is done to protect the GPT from programs unaware of the new partition table (like fdisk, which you just used without compromising the disk).

Now you see why you can boot a pc from a disk with a GPT partiton table when you set the BIOS on BIOS mode: the disk does have a MBR, so you can boot off it. However, the converse is false: if the disk has a MS-DOS partition table (not the legacy/protective one I mentioned above, just the old-fashioned one not followed by a proper GPT structure), then, setting the BIOS to UEFI mode means that the booter will search for the GPT structure, which is instead missing.

This is why your question is a bit of an oxymoron.

  • This answer partially conflates the firmware type (BIOS vs. UEFI) and the partition table type (MBR vs. GPT). Windows ties BIOS-mode booting to MBR disks and EFI-mode booting to GPT disks, but most EFIs (with CSMs) and some OSes (such as Linux) permit booting in BIOS mode from GPT disks or in EFI mode from GPT disks. Such configurations are rare, but possible; I've done all of them.
    – Rod Smith
    Jul 22, 2023 at 18:11

Not without accessing the firmware settings (a key at startup, which either flashes onscreen right at the beginning of the boot or must be found in the manual or online). There should be an option to switch between UEFI and CSM (compatibility support module, which provides the older BIOS functions; may also be labelles as BIOS or Legacy). Unfortunately, I cannot provide specific instructions of which key to hit or what specific menu this setting is located in, without knowing what specific box you have. Yes, that's right, it varies.


There's a lot of subtlety around this subject, and system-to-system variability, and it's not clear from the question why it's desirable to boot DOS from a computer set to UEFI-mode booting. This makes a practical answer difficult, but I can elaborate on some of the theory, and answer based on speculation about the true purpose of the question....

Most modern computers (most of those sold in the last 12 years or so) have Extensible Firmware Interface (EFI) or Unified EFI (UEFI) firmware. (I'll use "EFI" for simplicity.) Most, but not all, EFI implementations for x86/x86-64 CPUs have a component called the Compatibility Support Module (CSM), which enables them to boot older BIOS-mode OSes. CSM-enabled EFIs typically have a setup option to enable or disable the CSM (sometimes referred to by another term, such as "BIOS support" or "legacy mode"); however, precisely how that option works varies significantly from one computer to another. Usually, disabling the CSM in the firmware does just that -- it completely disables the CSM, so that you can't launch BIOS-mode OSes. On some implementations, though, "disabling" the CSM just drops its boot priority down below that of EFI-mode boot options. On such computers, "disabling" the CSM is more of a suggestion than a prohibition -- if the computer can't find any valid EFI-mode boot options, it'll try the BIOS-mode boot options, too. Some computers phrase their CSM option as if the computer will boot only BIOS-mode OSes if the CSM is enabled and only EFI-mode OSes if the CSM is disabled; but this is rarely true. In most cases, the ability to boot EFI-mode OSes is always active. Thus, the most accurate answer to the question, as stated is, "it depends" -- it might be possible to boot a BIOS-mode OS even with the CSM disabled, depending on the computer in use and whether there are valid EFI boot options in the boot list.

Also, be aware that EFI-based computers have a built-in boot manager to prioritize boot options. You might have installed two OSes, each of which creates its own boot entry; and the firmware may create additional boot options to enable booting removable media, boot from the network, etc. The CSM's BIOS-mode boot options are likely to be among these boot options (although they're a bit of a special case). Enabling or disabling the CSM can therefore change the set of boot options. This might not matter in some cases; if a valid EFI-mode boot option is first in the list, then it'll boot by default whether or not the CSM is enabled.

That's all theoretical, though. Presumably, @Greg G. has some unstated practical problem to solve. I don't know what that is, but I'm guessing that the need is to dual-boot DOS with some other EFI-mode OS. Most EFIs with CSMs make this possible, but it's a bit awkward. After installing both OSes, the boot manager can be accessed by pressing a certain key (usually a function key) as the computer powers on, and either the EFI-mode OS (usually identified by name) or the BIOS-mode OS (usually identified by a disk device) can be selected. To work in this way, the CSM will probably have to be enabled, though; disabling the CSM usually hides the BIOS-mode boot option(s) in the boot manager.

This can be made a little bit easier with my rEFInd boot manager. rEFInd scans for boot options and presents a menu on boot, so you won't need to hit the special key on every boot. By default, though, rEFInd does not scan for BIOS-mode boot options except on Macs; you need to edit the refind.conf file, uncomment the scanfor option, and add hdbios to the list to make rEFInd present BIOS-bootable disk options. As with using the computer's built-in boot manager, the CSM must be active for this to work.

Note also that DOS, AFAIK, requires a disk that uses the Master Boot Record (MBR) partition table. Most EFI-mode OSes create a GUID Partition Table (GPT) by default, which DOS can't read. Thus, dual-booting a BIOS-mode and an EFI-mode OS is likely to require separate MBR and GPT disks; however, there are workarounds. An OS like Linux can boot in EFI mode from an MBR disk or in BIOS mode from a GPT disk. There's also an ugly and dangerous hack known as a hybrid MBR. This was most commonly employed on Intel-based Macs to enable them to dual-boot the EFI-mode macOS with older BIOS-mode versions of Windows. In theory, it could be used to dual-boot DOS with Linux or FreeBSD on a non-Apple PC, but it wouldn't be useful for a dual-boot of BIOS-mode DOS with EFI-mode Windows, since Windows treats a hybrid MBR disk as an MBR disk, and Windows won't install in EFI mode on an MBR disk. Also, as I've said, hybrid MBRs are dangerous, so I strongly recommend against their use in most cases. I'm mentioning them only for completeness and their theoretical interest. If you want to dual-boot DOS and Windows on a modern PC, going with a straight BIOS-mode install is probably simplest, although that will limit the size of the installation disk. (You can still use a big GPT disk to hold Windows data.)

In most cases, rather than dual-booting DOS and a newer OS, it's likely to be better to run DOS in a virtual environment, such as VMware or VirtualBox, inside the more modern OS. DOS was designed with much less powerful computers in mind, so it'll run just fine in a very modest virtual machine. Because a virtual machine includes its own virtual firmware, you can run a BIOS-mode DOS in a VM that runs in an EFI-mode OS. This approach bypasses a lot of dual-boot problems and makes switching between the OSes trivially easy -- just click the right window, rather than reboot the computer.



ventoy can manage iso boots..

Old image of DBAN linux to nuke systems.. Not uefi compat.. boot ventoy, can then chain load DBAN and roast hard-drives away.. Tho.. (Iso from Acronis disk/dr toys n paying for likely faster..ie winpe/linux opts etc.. multiple threads 15 mins and uefi.. )

DBAN is still free and will still fry everything albeit slow/hours DoD wipe.. and can sell old laptops on ebay.. etc.

Or otherwise legacy non uefi tools.. chainload.. ie DRDOS/FreeDos ISO Ventoy can be your friend...

Ventoy can add security boot or uefi boot if security is disabled..

Some freeware iso tools ... dos floppy to boot.cat > ye olden boot dos.. The TLDR old article is linked below.. Fake floppy disks in virtualbox vmware etc.. not mentioned/tldr/Google em.

Usb and uefi.. etc.. extras ie security can add boot hash tools.. mokutil.efi and pals.. can make ventoy play nice with security boot.. etc.. sign enrol certs Yada yada... if added in /efi/tools directory etc.. / some linux iso, windows11.iso , dos-bios-flashme.iso (you made) drdos.iso Refind-uefi-boot-mgr.iso , etc..

Ventoy's windows installation exe or linux scripts x86 amd64 arm64 iso's made bootable.. Build stick , add iso files in rootfs on xfat or fat32 primary.. and that easy. As some newer boards ie orangepi or newer rpi 16 gb ram clones can be directly booted over efi iso/usb.. ie debian arm64 or interwebs pxe boot..

Related superuser 1230464

  • Sorry but I’ll have to downvote here. Ventoy doesn’t do magic. If it is started using UEFI, it can only boot UEFI-compatible operating systems. If it is started using legacy BIOS (CSM or actual old system), it can only boot operating systems compatible with that.
    – Daniel B
    Jul 22, 2023 at 20:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .