Boot Arch in BIOS or EFI interchangeably

duke11235 · 2013-11-23 04:08:06

I'm looking to setup a USB stick system that will be used on a myriad of computers. Is it possible to have a setup where whatever computer can choose between EFI and BIOS depending on support? I know the Live CDs do this somehow, but I don't know how. Anyone ever tried this setup or have any documentation on it?

Gulver · 2013-11-23 04:25:15

Not a proper answer but a BIOS setup will be usable in new machines with Legacy Mode. Grub as far as I know does not support what you ask, maybe rEFInd or others but I may be wrong.

Last edited by Gulver (2013-11-23 04:25:43)

WonderWoofy · 2013-11-23 04:48:14

Bios and UEFI and live on the same disk/installation. So you can set it up so it has both. Plug it into a UEFI machine and it will default to \EFI\boot\bootx64.efi in the EFI System Partition. Plug it into a non-UEFI machine and it will use the MBR bootloader.

duke11235 · 2013-11-23 05:24:44

That's pretty awesome. What about 32 v 64 bit EFI? Should I still install a bootloader to the USB Stick, or will the BIOS be enough to chainload the EFI/MBR implementation?

WonderWoofy · 2013-11-23 05:42:09

Having 32-bit UEFI and 64-bit would require two separate installations. The old bios systems would actualy go from 16-bit "real mode" to 32-bit "protected mode" to 64-bit "I can't remember" mode. This allowed for a 32-bit bios bootloader to boot a 64-bit machine and vice versa. But in UEFI, it starts in 64-bit mode (if an x86_64 obviously) and stays that way, so it cannot jump back and forth between the two.

But, you could use a 64-bit Linux kernel to boot a 32-bit installation, though I have read that this can sometimes cause some issues that are hard, if not impossible to deal with. So you could feasibly make a 32-bit setup, and then install both the x86_64 kernel as well as the i686 kernel. Then have the 64-bit UEFI bootloader launch the 64-bit kernel into the i686 userland, and the 32-bit UEFI bootloader launch the i686 kernel and matching userland. Though this would not be recommended.

But on a 32-bit UEFI system, instead of defaulting to \EFI\boot\bootx64.efi, it instead defaults to \EFI\boot\bootx32.efi (I think its called bootx32.efi, I have never really used this on a 32-bit UEFI system). So those, too, could also peacefully coexist on the same drive/ESP.

Last edited by WonderWoofy (2013-11-23 05:42:33)

duke11235 · 2013-11-23 05:54:47

I'm guessing BIOS boot would still need some form of GRUB to chainload it though. Is that correct?
I guess what's got me confused is the procedure:

UEFI:
BIOS->EFI System Partition -> Operating System

MBR
BIOS->440 byte MBR partition(Grub or Lilo) -> Operating System

UEFI should boot if the BIOS sees the files in the EFI partition. I'm assuming the BIOS can handle that, and all that's needed is to setup /boot/efi correctly. EFISTUB appears to allow direct boot if the required files are copied and kept updated to the EFI system file

MBR needs Grub or LILO installed in the 440 byte region to chainload an OS. When I pass GRUB --target=i386-pc I believe it tells it to install in that region.

With this setup I believe I can setup EFISTUB to handle UEFI booting, and install grub in BIOS mode to occupy the beginning of the disk. Do you see any flaws in this reasoning/install method?

Last edited by duke11235 (2013-11-23 07:02:40)

WonderWoofy · 2013-11-23 06:46:05

Linux is compatible with any combination of MBR/GPT and UEFI/BIOS. But this does not mean that you will always meet friendly firmware. Sometimes they refuse to boot from anything but certain combinations. As far as the BIOS side of things goes though, it shouldn't matter, as it is not the partitions that the firmware is looking for, it is the first 512 bytes (the MBR). So it loads whatever is in the first 446 bytes of that 512 block, which is the bootloader. That bootloader then initializes the HW enough to get to a point where it can locate and read the kernel and initramfs.

duke11235 · 2013-11-23 07:20:19

Is it considered better supported to do
MBR + GRUB + Live CD EFI
or

GPT + Live CD EFI+ (GRUB+Bios Boot Partition in MBR mode)

I seem to have found some things that say that the MBR region is left unoccupied even in GPT setups, but the sectors afterwards are allocated. That's why one needs a grub_bios partition. If that's true, than it would make sense that BIOS computers could boot the GPT disk scheme.

Cool link of the concept:
https://wiki.archlinux.org/index.php/GU … OS_systems

So to use GPT + EFISTUB + Grub BIOS I just need to create a BIOS boot partition, and then follow the command for BIOS systems:

grub-install --target=i386-pc --recheck --debug /dev/sda

I'll have to try it tomorrow

I see the .EFI files that are in the live cd files. How are those files read/edited/kept up to date. Do they change depending on the kernel? I can't even read them with a normal text edtitor

Last edited by duke11235 (2013-11-23 08:10:18)

teateawhy · 2013-11-23 13:00:44

wiki wrote:

It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot

That means to achieve the best compatibility with different computers, it is better to use the second option you suggested.

srs5694 · 2013-11-23 18:20:25

WonderWoofy wrote:

But in UEFI, it starts in 64-bit mode (if an x86_64 obviously) and stays that way, so it cannot jump back and forth between the two.

The EFI can't, but the boot loader can. I don't recall the details, but at least one of GRUB 2, GRUB Legacy, ELILO, and SYSLINUX can boot a 32-bit kernel from a 64-bit EFI boot loader or vice-versa. This is the sort of thing that I don't need to do myself, so I'm foggy on the details. Also, a 32-bit kernel won't be able to access EFI system variables, so a tool like efibootmgr won't work when booted in this way.

As you say, it's also possible to use a 64-bit kernel with a 32-bit userspace. I've never set up such a system myself, so I can't provide any real tips about doing it. One caveat is that I don't know if a 32-bit version of efibootmgr would work on a 64-bit kernel.

duke11235 wrote:

I'm guessing BIOS boot would still need some form of GRUB to chainload it though. Is that correct?

Any boot requires a boot loader. This boot loader can be:

BIOS -- LOADLIN, LILO, SYSLINUX, GRUB Legacy, or GRUB 2
EFI -- ELILO, Fedora's patched GRUB Legacy, GRUB 2, SYSLINUX, or the EFI stub loader

duke11235 wrote:

I guess what's got me confused is the procedure:
UEFI:
BIOS->EFI System Partition -> Operating System
MBR
BIOS->440 byte MBR partition(Grub or Lilo) -> Operating System

First, for clarity, I recommend avoiding the term "BIOS" to refer to an EFI, except in reference to the Compatibility Support Module (CSM).

Second, your description seems to make UEFI and MBR equivalents, but they aren't; UEFI (or EFI) is a type of firmware, but MBR is the first sector of the hard disk. The labels should be "UEFI" (or "EFI") and "BIOS." These are both types of firmware.

Third, your "EFI System Partition" entry is imprecise -- it's a boot loader file read from that partition that's important, not the partition per se.

Fourth, what you refer to as the "440 byte MBR partition" is not a partition -- it's the first 440 bytes of the first sector of the hard disk.

Fifth, in both paths, there can be additional elements -- support files, extra code read from elsewhere, etc. The details vary from one boot loader to another.

Combined, these changes become:

UEFI:
UEFI firmware -> Boot loader on EFI System Partition -> Operating System

BIOS:
BIOS firmware- > Boot loader in first 440 bytes of MBR -> Operating System

In both cases, the path can be more convoluted -- for instance, one boot program can chainload to another one. This is particularly important in the EFI path, since you might have something like gummiboot or rEFInd (both of which are boot managers) as the initial boot program. These then launch the EFI stub loader in the Linux kernel.

duke11235 wrote:

UEFI should boot if the BIOS sees the files in the EFI partition. I'm assuming the BIOS can handle that, and all that's needed is to setup /boot/efi correctly. EFISTUB appears to allow direct boot if the required files are copied and kept updated to the EFI system file

Different EFIs have different rules to determine when to boot in EFI mode vs. in BIOS/CSM/legacy mode. This makes it impossible to predict when a medium will boot in one mode vs. the other, except by creating BIOS-only or EFI-only boot media. If you don't need to force an EFI-mode boot when that's possible (say, to give users access to the efibootmgr utility), that's not really a problem. What can be a problem is that some computers will flake out when presented with certain types of boot media. For instance, a disk that uses GPT may be bootable in BIOS/CSM/legacy mode only if the MBR's type-0xEE partition is marked as bootable/active. The trouble is that setting this flag may cause other EFIs to misbehave and not boot at all, or to boot only in BIOS/CSM/legacy mode. This type of inconsistency makes it next to impossible to create a single boot medium that works on 100% of computers, especially if you want users to be able to select their boot mode. Depending on your needs, it may still be worthwhile to try to set this up; but if you're unlucky in your hardware, you may run into system-specific quirks that will require workarounds or system-specific boot media. If so, creating separate EFI-mode and BIOS-mode boot media may be worthwhile. Also, all of this ignores the issue of CD-R boot media -- they rely on El Torito, which imposes a whole new set of weirdness on it all. To preserve your sanity, stick to a straight USB flash drive image and forget about CD-Rs.

Using the EFI stub loader directly is possible, but awkward, on a USB flash drive image such as you want to create. The trouble is that the kernel needs a few parameters (most notably the identity of the root partition and of the initial RAM disk image file). An EFI-mode USB flash drive boot just launches EFI/BOOT/bootx64.efi without parameters, so the only way to pass those parameters is to build them into the kernel binary. This is possible if you build your own kernel, but of course this means you won't be using the stock Arch kernel, so this approach increases the effort required of you.

Instead, most EFI-bootable Linux installers and emergency disks rely on another boot manager or boot loader. Arch uses gummiboot and ALT uses rEFInd, but most major distributions use GRUB 2. GRUB 2, gummiboot, and rEFInd can all be launched without options and they read those options from configuration files, so there's no need to build anything special into the kernel, and you can use a stock kernel.

duke11235 wrote:

I seem to have found some things that say that the MBR region is left unoccupied even in GPT setups, but the sectors afterwards are allocated. That's why one needs a grub_bios partition. If that's true, than it would make sense that BIOS computers could boot the GPT disk scheme.

The MBR contains (or can contain) one or both of two things: BIOS-mode boot code and the MBR partition table. The boot code occupies the first 440-446 bytes of the sector and the partition table occupies the rest.

Under GPT, the MBR partition table must be present. This is known as the protective MBR, whose purpose is to keep GPT-unaware tools from partitioning the disk. The protective MBR just holds a single partition, of type 0xEE, that spans the entire disk (or at least up to the 2TiB mark, on disks larger than this). The first part of the protective MBR, though, may contain boot code, and boot loaders like GRUB 2, that support booting in BIOS mode from a GPT disk, use that space for their first stage. The BIOS Boot Partition (identified as type EF02 in gdisk or by the "bios_grub" flag in parted) holds additional GRUB boot code. The BIOS Boot Partition does not need to be the first partition on the disk or to immediately follow the MBR. As WonderWoofy says, there are BIOSes and EFIs with bugs and quirks in how they handle BIOS-mode booting from GPT disks.

There are tools that distribution maintainers use to create their boot media that may be useful to you. They help set things up for booting on multiple platforms; however, IMHO these tools push things a bit too far, particularly with respect to creating images that can be written to either USB flash drives or CD-Rs to be bootable in both ways. I also don't happen to have URLs handy for these tools, so I can't point you to them. Instead, you might want to try using either MBR or GPT partitioning and setting up GRUB 2 for BIOS-mode booting and something else (gummiboot, rEFInd, or ELILO) for EFI-mode booting. I recommend using two different boot loaders rather than GRUB 2 for both modes because that will reduce the odds of a conflict based on the boot mode (say, if you include some option in grub.cfg that works in EFI mode but not in BIOS mode or vice-versa). You can test these and you'll probably find something that will work on a wide array of computers, but you'll never be 100% certain that it will work if you stick it into an unknown computer.

One more complication is Secure Boot. If an EFI computer has Secure Boot active, it will boot your medium only if you include one of the two Linux Secure Boot solutions (PreLoader and shim). Even then, you'll probably have to enroll a hash or register a key at boot time to get your specific system to boot. For more on Secure Boot, see my Web page on the topic.

cfr · 2013-11-24 04:11:39

Given that it is not terribly uncommon for the EFISTUB loader not to work with recent Linux kernels, if you want it to work on as many machines as possible, you might consider using e.g. grub2 for EFI and syslinux for BIOS. Or some other combination that doesn't rely on EFISTUB.

duke11235 · 2013-11-24 05:39:00

You might be right cfr. I just finished setting up the encrypted system on the flash drive. I don't have access to an EFI machine right now(getting repaired), but I got grub setup in bios mode and booting the system. My understanding of syslinux is a bit shakier than Grub though.

My primary question is the use of efibootmgr. Is this necessary for EFI boot. The grub, syslinux, and efistub pages mention the use of efibootmgr. I understand that it adds entries to the EFI boot menu(NVRAM) on the motherboard. Is efibootmgr necessary? On a new(to the system) EFI machine, would I have to boot through legacy BIOS or a livecd to add and enable EFI boot for that machine?

All three also mention the need to mount the efivar. Do these change for every machine and necessitate a reinstall on different machines. I can install rEFInd, grub 2 efi, or gummiboot to the EFI system partition, but if I have to reinstall for efivars or efibootmgr that kinda creates a problem.

Thanks for all the help, I'm definitely learning a lot about computer firmware.

WonderWoofy · 2013-11-24 06:25:22

For interchangeability, you will not be using efibootmgr. You will be using the default spot of the ESP so that it can be taken from machine to machine. The efibootmgr command makes a menu entry that is stored in the firmware of the machine, not the disk on which you are creating this.

Also, as a side note, to move it form machine to machine, you will have to either remove the autodetect hook from the intiramfs or simply use the fallback.

duke11235 · 2013-11-24 06:48:57

I can't test it, but I was under the impression that when you install grub in efi mode or some other loader doesn't create

\EFI\boot\bootx64.efi

I could be wrong though.

Is there any documentation on generating that file or is it autogenerated by whichever bootloader on install?

I did not realize the autodetect hook did that. I'll remove that from mkinitcpio.conf and regenerate the initramfs

Last edited by duke11235 (2013-11-24 08:03:34)

WonderWoofy · 2013-11-24 07:28:02

Until recently, the ESP had to be set up more or less by hand with the exception of grub2. But even then, the default spot is not created. The only one that I know of that does this automatically is the gummiboot command. Though I really do like gummiboot, and it is my preferred boot manager, I do not like the fact that it automatically takes that spot. I think that there should not be a fight for the "default spot" and this should be configured by the user if necessary. But in my case, that is what I would put there anyway, so it bothers me less than it might otherwise.

srs5694 · 2013-11-24 17:06:12

EFI boot loaders are simply EFI programs. EFI programs are identified by a filename extension of ".efi". The "EFI/BOOT/bootx64.efi" filename is simply the name of the fallback boot loader. It's not something that a user normally generates -- you simply copy it, much as you might copy any other program file, from one location to another. In other words, if your EFI boot loader sets itself up as, say, "EFI/foo/bar.efi", you'd copy that file to "EFI/BOOT/bootx64.efi" to make it the fallback boot loader.

Arch Linux

#1 2013-11-23 04:08:06

Boot Arch in BIOS or EFI interchangeably

#2 2013-11-23 04:25:15

Re: Boot Arch in BIOS or EFI interchangeably

#3 2013-11-23 04:48:14

Re: Boot Arch in BIOS or EFI interchangeably

#4 2013-11-23 05:24:44

Re: Boot Arch in BIOS or EFI interchangeably

#5 2013-11-23 05:42:09

Re: Boot Arch in BIOS or EFI interchangeably

#6 2013-11-23 05:54:47

Re: Boot Arch in BIOS or EFI interchangeably

#7 2013-11-23 06:46:05

Re: Boot Arch in BIOS or EFI interchangeably

#8 2013-11-23 07:20:19

Re: Boot Arch in BIOS or EFI interchangeably

#9 2013-11-23 13:00:44

Re: Boot Arch in BIOS or EFI interchangeably

#10 2013-11-23 18:20:25

Re: Boot Arch in BIOS or EFI interchangeably

#11 2013-11-24 04:11:39

Re: Boot Arch in BIOS or EFI interchangeably

#12 2013-11-24 05:39:00

Re: Boot Arch in BIOS or EFI interchangeably

#13 2013-11-24 06:25:22

Re: Boot Arch in BIOS or EFI interchangeably

#14 2013-11-24 06:48:57

Re: Boot Arch in BIOS or EFI interchangeably

#15 2013-11-24 07:28:02

Re: Boot Arch in BIOS or EFI interchangeably

#16 2013-11-24 17:06:12

Re: Boot Arch in BIOS or EFI interchangeably

Board footer