Crear Usb Booteable Windows 10 Uefi Y Legacy
Aquilino Neadstine
I'm trying to understand once and for all the process by which Arch can be booted from a system with UEFI firmware and an MBR partition table. Some of the information on the wiki seems conflictual / non-nonsensical at times. Apologies in advance if this has been answered time and time again, but I did search around and all I found was fixes to get Arch to boot rather than comprehensive explanations of the boot process.
Now, the way I would imagine it works is that it's just completely identical to the way it would work with a BIOS firmware. The UEFI firmware detects an MBR partitioning scheme (or is configured to know it's an MBR partitioning scheme), activates some "legacy" mode and executes the MBR boot code, just like a BIOS firmware would.
The wiki however, says different. From the Macbook article: "Do not install GRUB onto /dev/sda !!! Doing so is likely to lead to an unstable post-environment."?
So what is there in the MBR boot sector? Nothing?
How does the firmware know what to boot if there's no 0xEF BIOS boot partition and no Grub stage 1 in the MBR boot sector?
Also, how does installing Grub stage 1 to a partition work? Does it have to be at the beginning of the partition? Wouldn't that overwrite some existing data?
I'm especially puzzled since many guides to installing Vista on a macbook recommend simply formatting as MBR, and installing as normal, which I suppose entails having the Windows installation process write its boot code to the MBR, ie the equivalent of installing grub stage 1 to /dev/sda rather than to the /boot partition, as the Macbook article suggests.
P.S. I realize it's probably simpler, if I just want to dual boot Windows and Arch, to install Windows 7 in UEFI-GPT mode, let it create the EFI System Partition, and then install GRUB 2 to that partition, but I'm still curious about the UEFI-MBR boot process.
Just to clarify: are you trying specifically to install on a Mac? Because as I understand it, the Mac firmware is *not* quite the same as UEFI v. 2 but is instead an Apple-customised version of EFI and the installation process is complicated/non-standard as a result.
If there any differences regarding MBR booting between the Mac EFI and UEFI v2, I'd be glad to hear them.
I'm trying to install on a Thinkpad x121e. Welll, I already have installed. I'm just curious as to how it would have gone had I opted for MBR and not GPT.
The section of the wiki I quoted does apply to dual booting with OS X, but I still don't understand how it works. Does the UEFI firmware simply chainload the GRUB stage 1 that's on the boot partition?
I don't actually know much about the Mac situation. I've never used regular (legacy) grub - unless you count the 24 hours or so I had it installed before I decided to switch to GPT. I just know that it is rather different e.g. that trying to setup grub2 in the ordinary way (using efibootmgr) can brick the machine and that you need to just bless instead. I don't even know what the stages refer to. Are they similar to the stages yaboot uses to boot? (I don't know if they are called "stages" in the case of yaboot but there is an initial menu - Linux, Open Firmware, CD, OS X etc. - and then, for Linux, a further menu with whatever kernels etc. are available.)
My guess would be that there's a reason you install OS X first rather than Linux. This seems to always apply to Macs - even the pre-intel ones. For the pre-intel ones, you need to do this even if you don't want OS X installed - and it looks like that applies to the intel ones, as well. But for pre-intel, you have to partition with OS X's utility - you can't use Linux tools. If you look at the resulting disk in Linux, you can see partitions which I believe OS X sets up but which don't usually show up in listings. It would be interesting to know what this looks like for an intel Mac.
If you had used MBR, why would you have used UEFI to boot? I'm just curious - I only used UEFI because I couldn't get it to boot with GPT in any other way - and, even then, I had to (fail to) install Ubuntu on it in order to figure out how to get it to work.
Syslinux requires the /boot partition to be marked as "Legacy BIOS Bootable" GPT attribute (legacy_boot flag in GNU Parted) to identify the partition containing the syslinux boot files by its MBR boot code gptmbr.bin . See Syslinux#GUID_Partition_Table_aka_GPT for more info.
GRUB-Legacy present in official repos as grub and in AUR as grub-gfx, does not support GPT disks. Fedora's heavily patched GRUB-Legacy fork grub-legacy-fedora-git contains GPT patches from Intel (tested in Fedora, not tested in Archlinux).
I have made a personal commitment not to reply in topics that start with a lowercase letter. Proper grammar and punctuation is a sign of respect, and if you do not show any, you will NOT receive any help (at least not from me).
No, it really didn't, but only because I initially had no idea I had a UEFI bios and Windows always uses BIOS-MBR if you boot from USB, unless you follow these instructions.
It also didn't help that Arch didn't seem to have any support for PXE UEFI booting, so it was unable to add the GRUB 2 entry to the firmware until I finally figured out why and switched to USB.
Then getting Windows to boot again was surprisingly easy, just had to copy its EFI boot files to the EFI system partition and run bcdboot from the install CD.
I wouldn't, I would have done a BIOS-MBR boot. I only mention UEFI because I assume it interacts with the bootloader differently (ie contrary to a BIOS firmware, it doesn't just run whatever's in the MBR).
No! This is about the difference between UEFI boot and BIOS boot. It's not about the difference between BIOS booting on a machine with UEFI firmware and BIOS booting on a machine with legacy firmware.
I was inquiring about a completely legacy boot: BIOS-MBR, not about BIOS-GPT. The only hitch being that I don't know how the UEFI firmware interacts with the usual BIOS-MBR booting (does it just run the code in the MBR? apparently it has the capacity to chainload a grub1 sitting in a partition VBR, since that's what the Arch wiki recommends for macbooks? etc).
So did you format the EFI partition fat 32? If so, which model of x121e do you have, if you don't mind my asking? And have you updated the firmware? Since I wiped Windows without ever booting it, I didn't have to tangle with that aspect of things.
I only ask because it turned out everything went swimmingly once I formatted it fat 16 but that was a far from obvious solution. (I let Ubuntu's installer lose on it to find what it did differently.) But there's been a BIOS update since then.
Now, the way I would imagine it works is that it's just completely identical to the way it would work with a BIOS firmware. The UEFI firmware detects an MBR partitioning scheme (or is configured to know it's an MBR partitioning scheme), activates some "legacy" mode and executes the MBR boot code, just like a BIOS firmware would.
Yes, most of the current uefi firmwares provide legacy bios compatibility. UEFI firmwares call such support as "Compatibility Support Module" or CSM for short. CSM in UEFI firmwares do the exact same job as normal BIOS firmware. The only difference you might notice is the scenarios in which the firmwares do UEFI boot and the scenarios in which they activate the CSM (for BIOS boot).
Do not confuse Mac EFI with normal UEFI firmware. Both are different. Macbook wiki page is valid for Mac EFI only. The reason taht warning is given is because grub-legacy modifies more than just the MBR boot code region. It can overwrite some parts of GPT header and table by trying to embed stage 1.5 and/or stage 2 in those places thus bricking the partition table of the macs. Grub-legacy (the ones in repos) does not support GPT. Thats the reason why Macbook article mentions installing grub-legacy to the partition rather than MBR of /dev/sda. But this is not the case with syslinux/grub2 as they work natively with GPT.
So what is there in the MBR boot sector? Nothing?
How does the firmware know what to boot if there's no 0xEF BIOS boot partition and no Grub stage 1 in the MBR boot sector?
Also, how does installing Grub stage 1 to a partition work? Does it have to be at the beginning of the partition? Wouldn't that overwrite some existing data?
In UEFI boot, the firmware does not access the MBR boot code region. It reads the partition table of the disk, finds the FAT32 formatted UEFISYS partition, launches the *.efi application from that partition.
In BIOS boot (normal case in non-UEFI firmwares or CSM in UEFI firmwares) does not read the partitition table (atleast it is supposed to be dumb in this regard), it simply launches whatever boot code exists in the 1st 440-byte of the MBR region.
Yes UEFI Spec. mentions MBR aka msdos partitioning can be used for UEFI boot. But the reality is different. Some firmwares determine whether to UEFI or BIOS boot based on the partition table of the disk. That is, they only allow UEFI-GPT, or BIOS-MBR boot. Some of the firmwares may allow BIOS-GPT boot. But no one has tested UEFI-MBR boot, as this is not recommended (even if it is possible). It is useless to use MBR when the firmware supports a better standard - GPT.
Macs also contain CSM named by Apple as bootcamp. Although CSM in UEFI firmware may help in BIOS boot, windows also requires MBR partitioning to be able to boot via BIOS. Part of the reason why some firmwares support only UEFI-GPT or BIOS-MBR config is because those are the only configs Windows supports (it does not support BIOS-GPT used by many users via grub2/syslinux). So even with bootcamp/CSM, the disk also needs to be MBR partitioned. So Macs use something called "Hybrid GPT/MBR" ( ) where the MBR table is synced to match the first 3 partitions in the GPT table.
d3342ee215