# GRUB2, Windows 10 and UEFI [SOLVED]

## mounty1

Looking at how to do it I don't understand how it can work.  If you mount the ESP at /boot/efi as the page suggests, the files in /boot are in the root partition, so how does GRUB2 find the kernel, to load it ?  Obviously my question reveals a misunderstanding.  Please explain.

----------

## eccerr0r

It doesn't matter where you mount it, if you install grub2 on your ESP, whatever that partition is will be its own root during EFI/preboot, just remember all paths are relative to that root (and I think most installer scripts will try to take that into account).  After the kernel is booted, your kernel can mount it anywhere - it doesn't need to be /boot/efi, it can be /usr/lib/my_boot/somewhere_weird.  However it could confuse canned installer scripts such as grub_mkconfig (which is NOT necessary to use!).

I'd normally mount the ESP as /boot much like how MBR dedicated boot partitions would also be mounted at /boot.

Note this also can make your ESP a mess if you're OCD...  I kept most of my kernels in the root of the ESP which would mix in with all the windows stuff...

----------

## mounty1

The "standard layout" at the end of this page appears to contradict the layout given here.

----------

## eccerr0r

Much like anything else in the computer world, it doesn't matter as long as your bootloader can find things.

I've always worked with systems whose ESP has a directory "EFI" so you will nevertheless see /boot/EFI if you mount your ESP at /boot.  I think the grub2 documentation is assuming you have "two" "boot" partitions: the ESP and the grub root partition - which is extraneous unless you want to have grub2 installed on a non-fat partition or your ESP does not have enough space to hold grub and your kernel images.  Grub2 installs on FAT just fine and thus it installs on the ESP just fine.

----------

## charles17

 *mounty1 wrote:*   

> ... appears to contradict the layout given here.

 

Have a look at bottom of the EFI/UEFI is a Nightmare, including GRUB2! section of the Discussion page and feel free to help reorganizing the grub2 article..

----------

## mounty1

 *eccerr0r wrote:*   

> Much like anything else in the computer world, it doesn't matter as long as your bootloader can find things.

 

I get that, as I generally set up systems with 'legacy' grub and must set up a /boot/grub/menu.lst so that grub knows where to find kernels and filesystems.

 *eccerr0r wrote:*   

> I've always worked with systems whose ESP has a directory "EFI" so you will nevertheless see /boot/EFI if you mount your ESP at /boot.  I think the grub2 documentation is assuming you have "two" "boot" partitions: the ESP and the grub root partition - which is extraneous unless you want to have grub2 installed on a non-fat partition or your ESP does not have enough space to hold grub and your kernel images.  Grub2 installs on FAT just fine and thus it installs on the ESP just fine.

 

Well that makes the page very unclear, but I see what you mean.  So my ESP was created by Windoze 10 and contains just EFI/ at its root, so if I mount that partition at /boot then /boot/EFI exists;  but mounting at /boot/EFI would mean that /boot/EFI/EFI exists --- very confusing.

Since Windoze has already set-up an ESP, all I did was create a Gentoo partition on the remaining disk space, then copy my kernel to /boot/EFI/Gentoo/vmlinuz-4.12.0-gentoo.efi.  So there is stuff under each of /boot/EFI/{Boot,Gentoo,Microsoft}.  As I understand it, that ought to be enough to make EFI present a boot choice on start-up.  But it just goes straight to Windoze, no choice.  What else must I do to get a boot menu?

----------

## eccerr0r

At the time I set up my laptop which has win7 on it, I wasn't sure if the machine had EFI or not.  However now it seems to have EFI.

The problem being, Windows absolutely did not like not being the primary bootloader for whatever reason (suspend/resume stopped working).  Now I'm not sure if it was because I had grub installed in legacy mode and thus windows had to boot legacy mode, but I ended up making windows chainloading grub that's installed on my Gentoo root filesystem that's an MBR partition.  I copied the boot sector (that has grub installed) of this partition to a file and told Windows bootmgr to chainload the bootsector - which appears to work and no longer interferes with suspend/resume.

Now this I am not sure about as I don't really want to provoke the angry bees of M$ much further: as the Windoze bootloader necessarily also needs to be an EFI app on EFI, you should be able to get grub2 to load that EFI image - but that's if grub loads first.  As I've not tried this, the following is clearly purely speculation. 

What you need is to use the efibootmgr tool to specify grub as the primary EFI boot image.  By default I believe there's a ESP:\efi\boot\bootx64.efi or something that it loads as the boot image by default (and it depends on what architecture you're using).  Warning that Windows may change it, so you'll need to find the image that windows uses - and efibootmgr should be able to tell what it is.  Anyway, you can put the grub image where it's currently trying to read it so you don't have to fsck with efibootmgr.  Now that original efi app that was there theoretically boots windows, so you want grub to run that to boot windows.

Again this latter piece is speculation based on my experimentation of trying to get Gentoo running on another EFI tablet that I was trying to boot Linux on, but as I had no way to reinstall Windows I didn't experiment much further than installing efi grub2 on a usb stick.

----------

## charles17

 * https://wiki.gentoo.org/wiki/EFI_System_Partition#Standard_layout wrote:*   

> Here the Microsoft subtree - and also the Boot subtree[1] - was created by an earlier installation of Windows 10 Creators Update. 

 

 * https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path wrote:*   

> ... Microsoft have worked around this (and arguably also made the problem worse) - the Windows installer also installs to the removable media path in the ESP (e.g. \EFI\boot\bootx64.efi for amd64/X64 systems). ...

 

So why not delete the /boot/EFI/boot/bootx64.efi ?

----------

## mounty1

Here is what the UEFI guides don't tell you because it's so obvious that you already know.  The UEFI firmware (1) does not load a boot block from disk 1 sector 1 like the BIOS.  It stores bootup strings (disk and kernel file references) in NVRAM;  and (2) those bootup strings reference EFI-compatible executables.  You can if you like just make your linux kernel UEFI compatible, by setting the right options in configuration.  If you do that, you can have the UEFI firmware launch it directly and that is what I do.  See command efibootmgr.  If you prefer, you can install GRUB, in which case the GRUB executable is the UEFI-launched executable and your kernel is launched by GRUB.

----------

## eccerr0r

That is indeed correct, I thought this was explained elsewhere, but repeated:  EFI no longer uses specific sectors, it uses complete files using the equivalent of FAT in the ESP (EFI System Partition).  The UEFI firmware is actually a preboot mini-OS that knows how to deal with files and specifically file allocation tables that deal with the ESP.

You no longer need to do "voodoo" with the disk like in MBR disks to get it to boot where you need to write outside of the filesystem (boot sector is outside of what you can write in the filesystem).  A simple "cp" to the filesystem will "install" your boot images now.

MBR boot sectors need to do voodoo because it needs to know where to find locations of the sectors of the bootloader and thus needs "blocklists" (which I'm sure people have run across) and "embedding" into a filesystem.  If people remember using lilo, this is the magic that it needs to do, lilo is so small because it hardcodes what would need to be a mini-OS.  Grub is so large in comparison because it needs to be the mini-OS that EFI now handles in firmware and deal with files.

The only "voodoo" you need to do is mucking with the EFI variables which holds the EFI boot menu.  efibootmgr handles this "voodoo" for you.

People claim grub is now optional.  Yes it is, EFI can find the boot image blocks for you now as well as provide a boot menu.  But Grub, at least on EFI firmwares without EFIShell, provides a command line interface to the preboot process which is invaluable for debug.  And it also knows how to read files on non-FAT partitions so you can put kernels there too.

----------

## charles17

 *eccerr0r wrote:*   

> ... But Grub, at least on EFI firmwares without EFIShell, provides a command line interface to the preboot process which is invaluable for debug.  And it also knows how to read files on non-FAT partitions so you can put kernels there too.

 

eccerr0r, you should have a look at rEFInd.  Much smaller than grub2 and needs no grub-mkconfig after kernel upgrades.

----------

## eccerr0r

And you don't need grub-mkconfig after kernel upgrades for grub2 either...  No problem editing it by hand or even completely doing away with grub-mkconfig.  It's merely there for convenience.

Does rEFInd has a preboot command line interface as well?

----------

## charles17

 *eccerr0r wrote:*   

> Does rEFInd has a preboot command line interface as well?

 

I haven't tried. But this and this looks like it does.

----------

