[SOLVED] UEFI system booting from MBR partition table and GRUB legacy

padavoine · 2012-06-03 13:42:59

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.

Any input is appreciated.

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.

Last edited by padavoine (2012-06-06 09:35:10)

cfr · 2012-06-04 01:16:30

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.

So is the question about installing on a machine with Apple's version of EFI? Or about installing on a machine with UEFI?

Doesn't the section of the wiki you pointed to only apply if you wish to dual boot with OS X?

padavoine · 2012-06-04 01:47:43

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?

EDIT: my understanding is that when Grub stage 1 is installed to a partition, it sits in the VBR of said partition. In that case, does it skip 1.5 entirely, or is 1.5 still in the post-MBR gap?

Last edited by padavoine (2012-06-04 01:58:21)

cfr · 2012-06-04 02:57:36

Interesting that you installed on an x121e. Did your install go smoothly? I had enormous trouble getting UEFI to work on my laptop.

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.

Frankly, I don't understand how my own machine boots and, since the whole reason I was fiddling was because I wanted to use GPT, I never looked into how to boot UEFI with an MBR table.

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.

Last edited by cfr (2012-06-04 03:16:04)

DSpider · 2012-06-04 08:51:26

The difference between booting an OS using BIOS and UEFI can be found here:
https://wiki.archlinux.org/index.php/UEFI

Also:
https://wiki.archlinux.org/index.php/GU … er_Support
https://wiki.archlinux.org/index.php/UEFI_Bootloaders

GPT is mandatory for UEFI boot, but GPT partitions can also be marked with the "Legacy BIOS Bootable" GPT attribute (legacy_boot flag in gparted).

At the very least you can install Syslinux because it supports GPT. GRUB Legacy doesn't.

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).

Read the above wiki entries. If you really, really, (really?) wanna use GRUB Legacy, you can use GRUB-Legacy-Fedora.

padavoine · 2012-06-04 10:45:10

cfr wrote:

Interesting that you installed on an x121e. Did your install go smoothly? I had enormous trouble getting UEFI to work on my laptop.

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.

trying to setup grub2 in the ordinary way (using efibootmgr) can brick the machine and that you need to just bless instead.

Ah, I guess that's the key difference then, although it should only apply to a UEFI setup, not to a BIOS setup.

I don't even know what the stages refer to.

Stage 1 is what usually sits in the MBR.
Stage 1.5 sits in the post-MBR gap.
Both 1 and 1.5 sit outside a file system.
Stage 2 is what you have in your /boot partition

If you had used MBR, why would you have used UEFI to boot?

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).

I couldn't get it to boot with GPT in any other way

Did you try this?

The difference between booting an OS using BIOS and UEFI can be found here:
https://wiki.archlinux.org/index.php/UEFI

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.

GPT is mandatory for UEFI boot

That's not true. UEFI firmwares can detect the 0xEF-type MBR partition just as well as they can detect the EFI Boot partition, and after that everything works the same way.

At the very least you can install Syslinux because it supports GPT.

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).

Last edited by padavoine (2012-06-04 10:46:24)

cfr · 2012-06-05 03:29:26

padavoine wrote:

cfr wrote:
Interesting that you installed on an x121e. Did your install go smoothly? I had enormous trouble getting UEFI to work on my laptop.
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.

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.

I couldn't get it to boot with GPT in any other way
Did you try this?

Yes.

There is an extremely long thread which lists everything (well a lot of) what I tried somewhere on the forums...

Last edited by cfr (2012-06-05 03:30:05)

padavoine · 2012-06-05 12:14:14

x121e-3045.
I did format to FAT 32, and did not update the firmware.

the.ridikulus.rat · 2012-06-06 05:52:41

padavoine wrote:

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).

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."?

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.

0xEF is the MBR type code for UEFISYS partition. grub stage 1 (used in grub-legacy, not in grub2) is the 440-byte boot code stored in MBR for use in BIOS boot.

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.

To understand how the formware know what to boot in case of UEFI boot, read about "efibootmgr" .

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.

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" ( http://rodsbooks.com/gdisk/hybrid.html ) where the MBR table is synced to match the first 3 partitions in the GPT table.

In hybrid gpt/mbr, Mac OS and linux exclusively use GPT, while windows exclusively uses MBR table. To boot Windows, a Mac activates bootcamp and it reads the MBR boot code to launch the windows bootloader (equivalent to stage 1 of grub-legacy). The bootloader then reads the MBR table of the hybrid MBR aznd launches the windows normally, thinking it has booted via MBR and not GPT.

the.ridikulus.rat · 2012-06-06 06:02:03

padavoine wrote:

cfr wrote:
Interesting that you installed on an x121e. Did your install go smoothly? I had enormous trouble getting UEFI to work on my laptop.
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.

Thats not true. I actually find it is much easier to install Windows UEFI-GPT using USB rather than a DVD. Follow https://gitorious.org/tianocore_uefi_du … I_boot_USB . In short, format the USB as FAT32 and extract the iso to it. That it.

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.

Don't know anything specific about PXE, but Archboot definitely supports UEFI boot. But as I sadi its easier to do UEFI boot via USB.

trying to setup grub2 in the ordinary way (using efibootmgr) can brick the machine and that you need to just bless instead.
Ah, I guess that's the key difference then, although it should only apply to a UEFI setup, not to a BIOS setup.

Thats is specific to Mac EFI. In normal UEFI systems efibootmgr should work and should not cause any issues, unless the firmware itself is screwed up.

I don't even know what the stages refer to.
Stage 1 is what usually sits in the MBR.
Stage 1.5 sits in the post-MBR gap.
Both 1 and 1.5 sit outside a file system.
Stage 2 is what you have in your /boot partition

Those are used only in BIOS booting using grub-legacy. They are not valid even for BIOS booting using grub2, and totally irrelevant in case of UEFI boot.

The difference between booting an OS using BIOS and UEFI can be found here:
https://wiki.archlinux.org/index.php/UEFI
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.

As mentioned earlier read about CSM in UEFI firmwares. There is no difference between in BIOS booting in UEFI firmwares and BIOS booting with legacy firmware. In both cases IT IS BIOS BOOT.

Next time please mention whether you are discussing Mac EFI or normal UEFI boot. Don't mix up both.

padavoine · 2012-06-06 08:26:03

CSM in UEFI firmwares do the exact same job as normal BIOS firmware.

So it's something specific to the Mac that it's able to boot from a partition's VBR while ignoring the MBR?

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.

Not true, the instruction is given in the context of an MBR format, not in the context of a GPT format, so there's nothing to overwrite and Stage 1.5 should be safely embeddable in the post-MBR gap.

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.

So again, you're saying it's specific to the Mac UEFI that it lets you choose a partition whose VBR to load, regardless of what's in the MBR?

0xEF is the MBR type code for UEFISYS partition. grub stage 1 (used in grub-legacy, not in grub2) is the 440-byte boot code stored in MBR for use in BIOS boot.

That's precisely my point: with neither proper executable code in the MBR (since grub was installed to a partition, not to the MBR) nor a UEFI system partition, what does the firmware default to, and how does it know what partition to boot from?

So even with bootcamp/CSM, the disk also needs to be MBR partitioned. So Macs use something called "Hybrid GPT/MBR" ( http://rodsbooks.com/gdisk/hybrid.html ) where the MBR table is synced to match the first 3 partitions in the GPT table.

I know what Bootcamp does, and that's not what I was referring to. I was referring to standalone Vista installs. I wasn't puzzled at the fact that they were using MBR, I was puzzled at the fact that contrary to the recommendations for the standalone Arch install on the wiki (with MBR partitioning, not GPT), they didn't do anything to try and prevent Windows from writing to the MBR.

Thats not true. I actually find it is much easier to install Windows UEFI-GPT using USB rather than a DVD.

I haven't done it since the only UEFI system I own has no DVD drive, but I was under the impression that it was simply a matter of choosing DVD UEFI boot in the firmware's boot menu.

format the USB as FAT32 and extract the iso to it. That it.

No, thats not it, precisely, it doesn't work out of the box with a standard Windows install USB, you need to fiddle around:

2.3 Extract bootmgfw.efi from [WINDOWS_x86_64_ISO]/sources/install.wim => [INSTALL.WIM]/1/Windows/Boot/EFI/bootmgfw.efi (using 7-zip aka p7zip for both the files), or copy it from C:\Windows\Boot\EFI\bootmgfw.efi from a working Windows x86_64 installation.
2.4 Copy the extracted bootmgfw.efi file to [MOUNTPOINT]/efi/microsoft/boot/bootmgfw.efi .

Those are used only in BIOS booting using grub-legacy. They are not valid even for BIOS booting using grub2, and totally irrelevant in case of UEFI boot.

I'm aware of this, I was only mentioning it since he asked.

read about CSM in UEFI firmwares.

Definitely helped my googling to know what "legacy mode" is actually called, but all I could find was the official Intel documentation, which is a mouthful to say the least.

There is no difference between in BIOS booting in UEFI firmwares and BIOS booting with legacy firmware.

There has to be a difference, at least in the Mac firmware (sorry, I keep switching), since legacy firmware, AFAIK, cannot chainload a bootloader in a partition's VBR without there being some sort of "stage1" code in the MBR.

the.ridikulus.rat · 2012-06-06 09:18:15

padavoine wrote:

CSM in UEFI firmwares do the exact same job as normal BIOS firmware.
So it's something specific to the Mac that it's able to boot from a partition's VBR while ignoring the MBR?
The reason that warning is given is because grub-legacy modifies more than just the MBR boot code region. It can overwrite some parts of GPT header.
Not true, the instruction is given in the context of an MBR format, not in the context of a GPT format, so there's nothing to overwrite and Stage 1.5 should be safely embeddable in the post-MBR gap.
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.
So again, you're saying it's specific to the Mac UEFI that it lets you choose a partition whose VBR to load, regardless of what's in the MBR?

I haven't used Macs so I can't comment on Mac firmware behaviour. But normal BIOS firmwares (legacy and CSM) launch only the MBR boot code and not the partition boot code. We need some chainload capable boot manager in the MBR to launch the partition VBR.

grub-legacy does not know anything about GPT. So when you install grub-legacy to /dev/sda, it install the MBR boot code (stage1) and stage 1.5 code to the (supposed) post MBR gap. Since there is no actual post MBR gap in GPT (which has been taken over by the header and partition table), grub-legacy does not check for GPT and it assumes the post MBR gap actually exists which is invalid in case of GPT. grub-legacy embeds the stage 1.5 code in GPT header and table region (which grub assumes to be unused post MBR gap) and thus corrupts it.

0xEF is the MBR type code for UEFISYS partition. grub stage 1 (used in grub-legacy, not in grub2) is the 440-byte boot code stored in MBR for use in BIOS boot.
That's precisely my point: with neither proper executable code in the MBR (since grub was installed to a partition, not to the MBR) nor a UEFI system partition, what does the firmware default to, and how does it know what partition to boot from?

In that case it might fallback to UEFI Shell (if it exists) or give an error similar to the case where BIOS does not find any bootable code in 440-byte MBR region.

So even with bootcamp/CSM, the disk also needs to be MBR partitioned. So Macs use something called "Hybrid GPT/MBR" ( http://rodsbooks.com/gdisk/hybrid.html ) where the MBR table is synced to match the first 3 partitions in the GPT table.
I know what Bootcamp does, and that's not what I was referring to. I was referring to standalone Vista installs. I wasn't puzzled at the fact that they were using MBR, I was puzzled at the fact that contrary to the recommendations for the standalone Arch install on the wiki (with MBR partitioning, not GPT), they didn't do anything to try and prevent Windows from writing to the MBR.

You can't prevent Windows from overwriting the MBR region. You have to re-install the bootloader (grub2/syslinux etc.) after installing Windows. That is the reason why it is recommended to install Windows first and linux later.

Thats not true. I actually find it is much easier to install Windows UEFI-GPT using USB rather than a DVD.
I haven't done it since the only UEFI system I own has no DVD drive, but I was under the impression that it was simply a matter of choosing DVD UEFI boot in the firmware's boot menu.
format the USB as FAT32 and extract the iso to it. That it.
No, thats not it, precisely, it doesn't work out of the box with a standard Windows install USB, you need to fiddle around:
2.3 Extract bootmgfw.efi from [WINDOWS_x86_64_ISO]/sources/install.wim => [INSTALL.WIM]/1/Windows/Boot/EFI/bootmgfw.efi (using 7-zip aka p7zip for both the files), or copy it from C:\Windows\Boot\EFI\bootmgfw.efi from a working Windows x86_64 installation.
2.4 Copy the extracted bootmgfw.efi file to [MOUNTPOINT]/efi/microsoft/boot/bootmgfw.efi .

Most of the Windows isos already have /EFI/BOOT/BOOTX64.EFI file, so no need to extract the bootmgfw.efi file.

There is no difference between in BIOS booting in UEFI firmwares and BIOS booting with legacy firmware.
There has to be a difference, at least in the Mac firmware (sorry, I keep switching), since legacy firmware, AFAIK, cannot chainload a bootloader in a partition's VBR without there being some sort of "stage1" code in the MBR.

No idea about Mac EFI. Apple made a spagetti out of UEFI Spec. To actually understand how Mac firmwares work, read the blog posts by Matthew Garrett of Redhat, about his efforts in getting Fedora to boot in Macs.

padavoine · 2012-06-06 09:34:52

I haven't used Macs so I can't comment on Mac firmware behaviour. But normal BIOS firmwares (legacy and CSM) launch only the MBR boot code and not the partition boot code. We need some chainload capable boot manager in the MBR to launch the partition VBR.

K, I guess that answers my question about the wiki article: just a Mac peculiarity.

In that case it might fallback to UEFI Shell (if it exists) or give an error similar to the case where BIOS does not find any bootable code in 440-byte MBR region.

That's precisely what puzzles me: it doesn't. An acquaintance of mine has an Arch install running that way. But again, I guess it's just a Mac thing.

Most of the Windows isos already have /EFI/BOOT/BOOTX64.EFI file, so no need to extract the bootmgfw.efi file.

Hmm, I guess they fixed it in the SP1 isos then. None of the originals do.

Ty for the answers.

Cromulent · 2012-06-06 16:14:23

This is the thing that gets me. I recently built a new computer with UEFI firmware and installed Windows 7 x64 on a brand new hard drive using the partitioning tools in the Windows installer and assumed that Windows 7 would use the GPT partitioning scheme automatically but alas it didn't and my Windows drives make use of the MBR partitioning style (this is according to the Disk Management console in Windows 7 x64). Now when it comes to installing Arch Linux on another brand new hard drive (I have three drives for Windows and one for Arch Linux) it seems I am in limbo as I can't do UEFI and MBR booting without it erroring out nor can I do BIOS and MBR nor can I do UEFI and GPT.

I'm most likely being stupid and not understanding something here about it but a little help would be appreciated.

padavoine · 2012-06-06 16:23:48

Cromulent, I don't see what the problem is.
Both Grub2 and grub legacy are perfectly capable of booting Linux and chainloading Windows in BIOS-MBR mode.
MBR partition the new hard drive, install GRUB legacy stage 1 to the MBR, set it as your boot hard drive in your BIOS, and add an entry for the Windows partition in its menu.cfg. Should work easily.

You could also convert your windows install to GPT-UEFI (instructions, bcdboot pretty much fixes everything), then use grub2 in UEFI mode to chainload windows, but that's sort of tedious.

DSpider · 2012-06-06 16:42:52

Cromulent, you should probably start a new thread, with more details and specific error messages, instead of hijacking this one (in which the OP apparently got his answer). Because most users will likely ignore it since it was marked as solved.

Cromulent · 2012-06-06 16:54:28

DSpider wrote:

Cromulent, you should probably start a new thread, with more details and specific error messages, instead of hijacking this one (in which the OP apparently got his answer). Because most users will likely ignore it since it was marked as solved.

Ah. OK, sorry didn't mean to hijack this.

cfr · 2012-06-07 02:40:51

Not that it really matters at this point, but I would *dearly* love to know how fat 32 EFI works for other people with precisely the same model of laptop as me and (presumably) the same firmware. (And I was not alone in having trouble getting this to work - I found reports elsewhere on the web, including advise that letting Ubuntu auto-format *did* work. And Ubuntu's installer turned out to use fat 16.)

As I say, it really doesn't matter at this point as fat 16 is working fine. I'm just very, very curious indeed.

It can't be because I'm not dual booting Windows, can it? I mean - that shouldn't make a difference to whether it finds the EFI partition, right?

the.ridikulus.rat · 2012-06-07 08:47:53

cfr wrote:

Not that it really matters at this point, but I would *dearly* love to know how fat 32 EFI works for other people with precisely the same model of laptop as me and (presumably) the same firmware. (And I was not alone in having trouble getting this to work - I found reports elsewhere on the web, including advise that letting Ubuntu auto-format *did* work. And Ubuntu's installer turned out to use fat 16.)
As I say, it really doesn't matter at this point as fat 16 is working fine. I'm just very, very curious indeed.
It can't be because I'm not dual booting Windows, can it? I mean - that shouldn't make a difference to whether it finds the EFI partition, right?

Maybe the partition size. My UEFISYS is 512 MiB and works fine with FAT32 (not Thinkpad). So maybe Thinkpad firmware does not accept FAT32 for small patition sizes (100-200 MiB). Just a guess.

EDIT: Seems like according to Microsoft, partitions of size 511 MB or less should not use FAT32, they should be using FAT16. See http://technet.microsoft.com/en-us/library/cc940351 for more info.

Last edited by the.ridikulus.rat (2012-06-07 08:58:28)

cfr · 2012-06-07 22:56:37

the.ridikulus.rat wrote:

Maybe the partition size. My UEFISYS is 512 MiB and works fine with FAT32 (not Thinkpad). So maybe Thinkpad firmware does not accept FAT32 for small patition sizes (100-200 MiB). Just a guess.
EDIT: Seems like according to Microsoft, partitions of size 511 MB or less should not use FAT32, they should be using FAT16. See http://technet.microsoft.com/en-us/library/cc940351 for more info.

Very interesting df -h shows mine is 476 MB so if I'd just made it a little bigger, I could have avoided all those hassles?!!

I thought the UEFI spec required FAT 32? Or is it just that it is meant to work with FAT 32 as a minimum?

So should the wiki advise people using partitions smaller than 511M to try FAT 16 (or to try this if FAT 32 doesn't work)? Or to use partitions of at least 512M?

I'm slightly dubious about some of the claims on this page. It claims that "some unix" systems can access FAT 16 volumes but that "FAT32 volumes are not accessible from any other operating systems other than Windows 95 OSR2 and Windows 98". Really? I'm pretty sure Macs can access them and Linux doesn't seem to have much trouble, either...

DSpider · 2012-06-08 08:58:38

I'm slightly dubious about some of the claims on this page. It claims that "some unix" systems can access FAT 16 volumes but that "FAT32 volumes are not accessible from any other operating systems other than Windows 95 OSR2 and Windows 98". Really? I'm pretty sure Macs can access them and Linux doesn't seem to have much trouble, either...

It's an older article, probably around the time they were working on Windows 2000. You don't see Windows XP (or above) in there, do you? And XP came out in 2001! But it's funny that they didn't mention Windows Me. They were probably too embarrassed by it to even include it.

Anyway, because FAT32 is patented by Microsoft (which they even sued TomTom and Motorola for), developers had to implement ways that would go around these patents. And so the vfat module was born. In 1999 this either didn't exist or it may have been in its infancy, at least as a concept. Hence the claim on that page that "FAT32 volumes are not accessible from any other operating systems other than Windows 95 OSR2 and Windows 98."

Really? I'm pretty sure Macs can access them and Linux doesn't seem to have much trouble, either...

Apple probably just paid the $0.25 royalty per every device sold to have it in their OS instead of developing their own. Yup. It's why Macs are overpriced. Because they have FAT32 support.

Arch Linux

#1 2012-06-03 13:42:59

[SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#2 2012-06-04 01:16:30

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#3 2012-06-04 01:47:43

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#4 2012-06-04 02:57:36

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#5 2012-06-04 08:51:26

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#6 2012-06-04 10:45:10

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#7 2012-06-05 03:29:26

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#8 2012-06-05 12:14:14

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#9 2012-06-06 05:52:41

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#10 2012-06-06 06:02:03

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#11 2012-06-06 08:26:03

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#12 2012-06-06 09:18:15

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#13 2012-06-06 09:34:52

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#14 2012-06-06 16:14:23

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#15 2012-06-06 16:23:48

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#16 2012-06-06 16:42:52

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#17 2012-06-06 16:54:28

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#18 2012-06-07 02:40:51

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#19 2012-06-07 08:47:53

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#20 2012-06-07 22:56:37

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

#21 2012-06-08 08:58:38

Re: [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

Board footer