Instaled FC17 in UEFI/EFI ? mode - how to chainload grub on another partition.

[interzoneuk]

Hi.

I have installed FC17 on my new brand new motherboard (i5 CPU) this has UEFI...

It installed fine (after I used the entire disk) however I normally access other linux distros by installing grub to a partition i.e /dev/sda5 then using

root (hd0,4)
chainloader +1

However when I tried this using UEFI I get an error regarding too many partitions ....

How can I boot grub off a separate partition when using UEFI?

So far UEFI seems a nightmare...

any ideas?

[srs5694]

First, be sure that you're booting in EFI mode. In Linux, check for the presence of the /sys/firmware/efi directory. If it's present, you've booted in EFI mode. If it's absent, you've probably booted in BIOS mode.

Assuming you're booting in EFI mode, you should understand the EFI boot methods, which are really much more sensible than the BIOS methods -- but they're different enough that they'll take some learning. Rather than boot using boot code stuffed into the MBR and partition boot sectors, as in BIOS, EFI boots by reading files from a partition on the disk. This partition is known as the EFI System Partition (ESP), and it's usually the first partition on the disk. Boot loaders normally reside in subdirectories of the /EFI directory on this partition, as in /EFI/redhat or /EFI/ubuntu.

To select which OS to boot, your firmware might provide its own built-in boot manager. (Note: A boot manager presents options to the user; a boot loader loads a kernel. This distinction is important under EFI.) Unfortunately, many EFI implementations provide boot managers that are so limited as to be useless. When this is the case, you need to set up a separate boot manager to do the job, and configure it to boot by default. You can use GRUB 2 for this purpose (it's both a boot manager and a boot loader), but the details for selecting a boot loader are different than under BIOS. Specifically, a chainloader definition would look something like this:

menuentry "Windows 7" {
        set root='(hd0,gpt1)'
        chainloader /EFI/microsoft/BOOT/bootmgfw.efi
}

This tells it to boot the /EFI/microsoft/BOOT/bootmgfw.efi file from (hd0,gpt1) (the ESP).

If you're using GRUB Legacy, it would be similar, but the syntax of the stanza definitions is a bit different.

Another option is to use something other than GRUB as the initial boot manager. My rEFInd (a fork of the earlier rEFIt) can do this. It presents a graphical menu of all the boot loaders found on the ESP. In fact, with a 3.3.0 or later kernel, it's possible to bypass GRUB entirely, since 3.3.0 and later kernels include their own boot loader, known as the [i]EFI stub loader,[/url] which can replace GRUB on an EFI system. In my experience, this works much better than GRUB 2, which works very poorly under EFI, at least for me.

[C64]

I'm also trying to get my head around UEFI and how to get it to work the way I want it to (stubborn old git as I am). It seems as if the original poster is used to a similar setup as myself:

First boot is to a dedicated grub partition that contains a text editable config file where you specify chainloading to the boot partitions of all installed systems.

From the previous post it looks as if something similar is possible with UEFI, but I'd like to make sure the main principle can be applied. Is it possible to install a system without it making any changes to the ESP during install and instead modify the ESP from another known working installation (by preparing the ESP configuration beforehand)?

If you install a lot of different systems on the same computer (for production and testing) this is a very attractive solution. When I try out a new system the installation process has to be sandboxed in case something goes wrong. The important thing is to not allow the installation to mess with anything on the disk except its own dedicated partitions, especially not places that other systems rely on (like the MBR or ESP). With the "chainloading super grub partition" method this is very easy to do.

Hope I didn't hijack.

[srs5694]

Originally Posted by C64

First boot is to a dedicated grub partition that contains a text editable config file where you specify chainloading to the boot partitions of all installed systems.

From the previous post it looks as if something similar is possible with UEFI, but I'd like to make sure the main principle can be applied.

That's more-or-less the way EFI is designed to work. The main difference is that the initial boot manager is provided by the EFI itself, not by GRUB.

Digression: Understand the difference between a boot manager and a boot loader. In the Linux community, we often conflate these concepts because GRUB and LILO handle both tasks. A boot manager gives you some way to choose which OS to boot. A boot loader loads an OS kernel (and any necessary additional files) into memory and hands control of the computer to the kernel.

In the EFI scheme, the firmware provides a boot manager that enables you to select which boot loader to load from the EFI System Partition (ESP). Unfortunately, the EFI spec says next to nothing about user interfaces, so some EFIs provide tolerable boot managers, but others provide boot managers that are so rudimentary that they're useless. Thus, there are third-party boot managers such as rEFIt, rEFInd, and the boot management features of GRUB.

Is it possible to install a system without it making any changes to the ESP during install and instead modify the ESP from another known working installation (by preparing the ESP configuration beforehand)?

Yes, but that's a feature that will be provided (or not provided) by each OS installer, depending on its developers' whim. In this respect it's the same as on a BIOS-based computer. It's likely to be a little bit easier to add your boot loader after installing, since doing so is a matter of adding files to the ESP and then configuring a master boot manager (in the EFI itself or in another program) to add the new boot loader to the list of options.

If you install a lot of different systems on the same computer (for production and testing) this is a very attractive solution. When I try out a new system the installation process has to be sandboxed in case something goes wrong. The important thing is to not allow the installation to mess with anything on the disk except its own dedicated partitions, especially not places that other systems rely on (like the MBR or ESP). With the "chainloading super grub partition" method this is very easy to do.

The risk to the ESP when installing an EFI-based OS is smaller than the risk to the MBR when installing a BIOS-based OS. Unlike the MBR, which is a single 512-byte sector, the ESP is a whole partition with a FAT filesystem and a directory tree. OSes are supposed to install their boot loaders in their own directories, so a Fedora installation (say) should not damage an existing Ubuntu or Windows installation.

That said, there are bugs and glitches. For instance, until 12.04, Ubuntu created a new filesystem on the ESP when installing itself, thus wiping out any pre-existing boot managers and boot loaders. Typically, each OS registers its own boot loader as the first one to be tried by the firmware, which is probably not the behavior you'd want in your scenario.

[C64]

Originally Posted by srs5694

That's more-or-less the way EFI is designed to work. The main difference is that the initial boot manager is provided by the EFI itself, not by GRUB.

Yes, I see, but what I need (and I suppose others that use chainloading as a "sandboxer" mechanism) is a way to go from EFI->GRUB->kernel instead of GRUB->GRUB->kernel which is the current setup. It is important here to see that the double grub setup is not a flaw, it is a design choice so that the initial loader can be insulated from all details about the different systems that reside completely within their own partitions. Most people would no doubt prefer the efficient direct route that EFI with kernel stubs offer, but I hope there is a way of making a system-independent link from EFI to a secondary stage residing somewhere in the OS partitions where the selection for different kernels and kernel parameters can be made. The secondary stage needn't be GRUB, it can be anything that offers similar functionality/flexibility.

Originally Posted by srs5694

Yes, but that's a feature that will be provided (or not provided) by each OS installer, depending on its developers' whim. In this respect it's the same as on a BIOS-based computer.

I suppose, but every installation I've tried has always given the option to install the bootloader and bootmanager to either MBR or the system partition's boot sector (or omit it completely). This doesn't seem to translate well to EFI where (if I've understood it correctly) the preferred setup is to have one common EFI partition/file system with all boot information. To be clear, this is precisely the kind of centralized scenario I'd like to avoid and have successfully done so since I learned about the double GRUB setup.

Originally Posted by srs5694

The risk to the ESP when installing an EFI-based OS is smaller than the risk to the MBR when installing a BIOS-based OS

It is from having been forced to fix broken boot processes one too many times that I've started using the two-stage chainloading GRUB procedure which eliminates this risk completely. When something goes wrong you're only "bootlocked" out of the system that you just installed or updated, the other environments you have are still bootable. Also, I'm not keen on the idea of having to update the EFI every time a new kernel rolls out. So for EFI to be immediately useful for people like me there would have to be a way of linking to the boot sector on the actual system partition (ie. like chainloading)

[srs5694]

Originally Posted by C64

Yes, I see, but what I need (and I suppose others that use chainloading as a "sandboxer" mechanism) is a way to go from EFI->GRUB->kernel instead of GRUB->GRUB->kernel which is the current setup. It is important here to see that the double grub setup is not a flaw, it is a design choice so that the initial loader can be insulated from all details about the different systems that reside completely within their own partitions. Most people would no doubt prefer the efficient direct route that EFI with kernel stubs offer, but I hope there is a way of making a system-independent link from EFI to a secondary stage residing somewhere in the OS partitions where the selection for different kernels and kernel parameters can be made. The secondary stage needn't be GRUB, it can be anything that offers similar functionality/flexibility.

You can do it that way. Simply place an OS-independent boot manager on the ESP and configure it as the default boot program. The boot manager must be able to redirect the boot process to programs that don't reside on the ESP. GRUB Legacy, GRUB 2, rEFIt, and rEFInd can all do this. So can some EFI implementations' built-in boot managers.

re: Boot loader installation options during OS installation:

I suppose, but every installation I've tried has always given the option to install the bootloader and bootmanager to either MBR or the system partition's boot sector (or omit it completely). This doesn't seem to translate well to EFI where (if I've understood it correctly) the preferred setup is to have one common EFI partition/file system with all boot information. To be clear, this is precisely the kind of centralized scenario I'd like to avoid and have successfully done so since I learned about the double GRUB setup.

I've used so many different distributions that it's hard for me to keep straight what each one provides in the way of boot loader installation options, especially since they change over time even for any given distributions. Some give pretty good options, but others are more limited. Many provide options that have names that are accurate for BIOS but misleading for EFI. With GRUB 2, many distributions have eliminated the option to install it to a partition's boot sector on BIOS-based systems, presumably because the GRUB developers discourage this placement.

Also, I'm not keen on the idea of having to update the EFI every time a new kernel rolls out.

This would only be necessary if you wanted to boot the EFI stub loader directly from the EFI's boot manager. This approach is possible, but is really only practical on a computer that boots a single kernel, and then only if the kernel is updated infrequently. For most users, the EFI stub loader is most practical when it's paired with a separate boot manager, such as rEFInd.

In fact, given your goals, I think you might want to check out using rEFInd with ext2fs and/or ReiserFS EFI drivers and the kernel's EFI stub loader. From what I understand of your desires, this will do what you want, and IMHO do it much more cleanly than will a system that involves GRUB -- much less multiple GRUB installations. See the following pages in the rEFInd documentation for details:

http://www.rodsbooks.com/refind/linux.html
http://www.rodsbooks.com/refind/drivers.html

So for EFI to be immediately useful for people like me there would have to be a way of linking to the boot sector on the actual system partition (ie. like chainloading)

Under EFI, there's no such thing as a "boot sector." Boot programs (both boot managers and boot loaders) exist as ordinary files in ordinary filesystems. They can be copied, deleted, moved, and updated using normal file management tools. The computer knows which one to use based on a default name (/EFI/boot/bootx64.efi on the ESP, at least for x86-64 systems) or by entries pointing to boot loaders and specifying their order stored in NVRAM.

If you're used to BIOS booting, the EFI system can seem strange and confusing at first. It's a significant paradigm shift with both coarse and subtle implications. It's likely to take you some time to really understand all those implications. Once you do, you'll see that the need for many features we've been demanding of BIOS boot programs for years is greatly reduced, if not completely eliminated, because those needs are either obviated by the new design or they're provided by the EFI or by separate programs and utilities. That said, it's changing rapidly. Both the 3.3.0 kernel and rEFInd were released just over two months ago, and they've changed the EFI booting game significantly, at least for Linux. Future developments could change it further. Additional EFI drivers for Linux filesystems, and ideally for Linux RAID and LVM, will make it possible to boot Linux kernels via the EFI stub loader from partitions that wouldn't work as boot partitions today, at least not with the EFI stub loader.

[interzoneuk]

The actual error I get is 'Selected cylinder exceeds maximum supported by BIOS' - this is on any partition higher than 3...

/sys/firmware/efi does exist in Fedora.

theres a few odd things going on....

1) Fedora 17 in UEFI mode has installed gruib 1 (rather than the default grub2..) is that right?
2) After a while running (randomly) I get drive error messages - but first efi messages (I haven't captured them yet - I shall do..) Howver its a brand new drive and any error checking from a live cd, etc shows 0 errors so I don't believe its the disk at fault.

I do get the message on boot

----------------------
May 31 22:14:31 fc17 kernel: [ 0.000000] Kernel-defined memdesc doesn't match the one from EFI!
----------------------

I will update the ticket with the error - then probably reinstall without UEFI - I am happy with 15 partitions anyway...

[srs5694]

Originally Posted by interzoneuk

The actual error I get is 'Selected cylinder exceeds maximum supported by BIOS' - this is on any partition higher than 3...

Technically, EFI is not BIOS. Furthermore, EFI doesn't use cylinder numbers. Thus, this sounds to me like a BIOS-mode boot error, not an EFI-mode boot error. OTOH, many vendors use the term "BIOS" as synonymous with "firmware," and it's conceivable this error message is in some code that's used in both modes and the message just hasn't been properly worded or updated for EFI.

When does this message occur? Is it before GRUB launches (that is, a firmware error message), after GRUB launches, or after the kernel launches? Note that it might not even be an error message; it could be informational and about something that's harmless.

It might also be helpful if you could post information on your partition table, as in the output of the following, typed as root:

parted /dev/sda unit s print

Please post it as an attachment or between code tags, to keep the output legible.

/sys/firmware/efi does exist in Fedora.

So you're definitely booting in EFI mode, whatever the source of the confusing message you've posted.

theres a few odd things going on....

1) Fedora 17 in UEFI mode has installed gruib 1 (rather than the default grub2..) is that right?

I haven't yet gotten around to doing a Fedora 17 installation, but Fedora 16 used GRUB Legacy on EFI systems because the Fedora developers deemed (correctly, IMHO) GRUB 2 to be too flaky on EFI.

2) After a while running (randomly) I get drive error messages - but first efi messages (I haven't captured them yet - I shall do..) Howver its a brand new drive and any error checking from a live cd, etc shows 0 errors so I don't believe its the disk at fault.

To the best of my knowledge, the Linux kernel doesn't go through the firmware to access the hard disk, at least not once it's fully booted. Thus, this sounds like a driver bug or a hardware problem, and probably the latter. If a SMART test is showing no errors, you might try replacing your cables; flaky cables can cause drive errors even when the drive itself is fine.

I do get the message on boot

----------------------
May 31 22:14:31 fc17 kernel: [ 0.000000] Kernel-defined memdesc doesn't match the one from EFI!
----------------------

I've seen that same message on every EFI implementation I've used. I've not bothered to track down its meaning, but it seems to be harmless.

[interzoneuk]

Thanks for the input.

Weirdly the issues I were having seemed to be related to a sata 600 cable...

I have changed the cable and the odd disk issues have gone away (even more weird is that they only occurred when using EFI - with the 'bad' cable in non EFI mode I could format the entire disk then fsck -fcv /dev/sada1 and it found no errors/bad blocks...)

I have reinstalled after changing the cable - I can now see other partitions (+3) from grub1 (and as mentioned the HDD errors had completely gone)

One thing I still don't get is how to load grub from another partition....

Can anyone help with the syntax, Fedora 17 uses grub1 still for EFI.

My (working) Fedora grub conf lines are

title Fedora (3.4.0-1.fc17.x86_64)
	root (hd0,1)
	kernel /vmlinuz-3.4.0-1.fc17.x86_64 rd.md=0 rd.lvm=0 rd.dm=0 root=UUID=ae8a55c7-9ddf-4de2-b3e5-f291a5c02db8 SYSFONT=True  KEYTABLE=uk rd.luks=0 ro LANG=en_US.UTF-8 rhgb quiet
	initrd /initramfs-3.4.0-1.fc17.x86_64.img

How would for example I load grub from an ubuntu partition say on /dev/sda6?

Previous I would have used root(hd0,5) chainloader +1

In the example given earlier

chainloader /EFI/microsoft/BOOT/bootmgfw.efi

What we be the equivalent to load ubuntu ? - I haven't installed that in EFI mode (as far as i'm aware it doesn't support it)

I just want to load grub from the partition - I can load the os by adding kernel and initrd lines to grub (however I just want to know how to chainload grub...)

cc

[srs5694]

AFAIK, you can't chainload a BIOS boot loader (as stored in the boot sector of a Linux partition) from an EFI version of GRUB. You can chainload another EFI boot loader using the "chainloader" option to identify the EFI file, as in the bootmgfw.efi example; you'd just change the filename of the EFI boot loader in question to the name of that distribution's GRUB (or ELILO or whatever it's using) binary file.

Another option, as stated in my first reply to this thread, is to use rEFIt or rEFInd as the first-stage boot manager, to select which distribution's GRUB (or whatever) boot loader to use, and using those boot loaders just to boot one distribution each (no chainloading).

[interzoneuk]

srs5694 thanks for clearing that up.