A chroot expert in the mood to advise?

[Qqmike]

Here's mine, from my how-to:

]]]]]]]]]]]]]]]]]]]]]
Quick version:
Assume the broken partition is /dev/sdxy.
Assume the ESP is sda1 (usually mounted at /boot/efi).
For BIOS systems: Omit the ESP: mount /dev/sda1 /boot/efi; umount /dev/sda1 /boot/efi

 kubuntu@kubuntu:~$ sudo mkdir /mnt/sdxy
 kubuntu@kubuntu:~$ sudo mount /dev/sdxy /mnt/sdxy
 kubuntu@kubuntu:~$ sudo mount --rbind /dev  /mnt/sdxy/dev
 kubuntu@kubuntu:~$ sudo mount --rbind /sys  /mnt/sdxy/sys
 kubuntu@kubuntu:~$ sudo mount --rbind /run  /mnt/sdxy/run   
 kubuntu@kubuntu:~$ sudo mount --rbind /proc  /mnt/sdxy/proc
 kubuntu@kubuntu:~$ sudo chroot /mnt/sdxy
 root@kubuntu:/# mount /dev/sda1 /boot/efi
 root@kubuntu:/# [B]grub-install[/B]
 Installing for x86_64-efi platform...Installation finished. No error reported.
 root@kubuntu:/# [B]update-grub[/B]
 Generating grub configuration file ...etc ...done
 root@kubuntu:/# umount /dev/sda1 /boot/efi
 root@kubuntu:/# exit
 exit
 kubuntu@kubuntu:~$ sudo umount /proc /mnt/sdxy/proc
 kubuntu@kubuntu:~$ sudo umount /dev /mnt/sdxy/dev
 kubuntu@kubuntu:~$ sudo umount /sys /mnt/sdxy/sys
 kubuntu@kubuntu:~$ sudo umount /dev /mnt/sdxy/dev
 kubuntu@kubuntu:~$ sudo umount /dev/sdxy /mnt/sdxy
 kubuntu@kubuntu:~$ exit

]]]]]]]]]]]]]]]]]]]]]

From live Kubuntu DVD/USB, and by chrooting, it is short and sweet.

[SteveRiley]

I wonder if grub-install is smart enough that it can locate an existing EFI partition without explicitly being told where to find it.

[Qqmike]

If you chroot into a system that already has a valid GRUB-EFI setup (but broken), ANY live CD would work. You are not using any special grub files or facilities from the live CD--you are using only the chrooted environment (jail).

[Qqmike]

I wonder if grub-install is smart enough that it can locate an existing EFI partition without explicitly being told where to find it.

If you issue that command inside the OS you are installing GRUB-EFI to, grub-install will assume your ESP is mounted at /boot/efi and it will find it. But if you have some other ESP you are using, or two (or more) ESPs, then you can use the option
--efi-directory=DIR
where DIR is the mount point of the ESP you wish to use.

[SteveRiley]

So the author of that Debian wiki page is making certain assumptions, then.

[Qqmike]

I guess. Or Debian's GRUB is different and accepts that statement OK: grub-install /dev/sda1. In (K)Ubuntu, that statement is a GRUB legacy install command, not GRUB-EFI. AFAIK, based on my experimenting to date, and the successes, and all the error messages I've generated.

[Qqmike]

I'm wrong.

I just tested this on my Desktop PC Kubuntu 14.04, the one I'm using now:

mike@mike-desktop:~$ sudo grub-install /dev/sda1
Installing for x86_64-efi platform.
Installation finished. No error reported.

And I checked this to see that it did write to the sda1-ESP on my system; it did use the standard directory /boot/efi/EFI/ubuntu, also. (I put a test/dummy # comment in that little grub.cfg file there to see that grub-install over-wrote that grub.cfg file.)

Holy cow. So (for K(Ubuntu)),
sudo grub-install /dev/sda1
is the same as
sudo grub-install --efi-directory=/boot/efi
which is the same as the default (assuming you are in your systeom or chrooted into your system):
sudo grub-install

Hmm. There you go! I'm still a little skeptical, though. I am under the impression that for EFI, grub-install will NOT accept that device option /dev/sda1 written that way. I'll re-boot and make sure it boots OK now.

[Qqmike]

My PC re-booted fine. In fact, before the test in Post #22, rEFInd was first in BootOrder. After the test, ubuntu (= /boot/efi/EFI/ubuntu) is first and rEFInd is second--as it should be since I just installed a (new) GRUB to my Kubuntu, so it takes precedent ("the last installed...").

I need to think on this tomorrow. It doesn't change any results I've had, but I may need to change a couple statements I made about that syntax not working for EFI. (I could swear I tried it before, and it failed, but maybe I'm wrong about this.)

That would only add another option to this game (to grub-install syntax), nothing wrong with that.

[Qqmike]

I think--but will check later--that the Arch wiki said this statement would not work for GRUB-EFI:
sudo grub-install /dev/sda1
Maybe it won't work for Arch but it will for Debian/Ubuntu? Seems so.
Of course, GRUB 2 for BIOS (grub-pc) will NOT accept a statement like this:
sudo grub-install --efi-directory=DIR
I did run into that and got error messages from GRUB 2 (BIOS).
But our Kubuntu GRUB-EFI seems more flexible than I thought it was (as per Post #22).

Thanks for your interest in this.

[Qqmike]

I apologize for posting back again like this. But it just occurred to me why this statement may work for K(U)buntu GRUB-EFI:
sudo grub-install /dev/sda1

It may work because the /dev/sda1 is ignored by GRUB-EFI! It ignores that device reference (as it is a GRUB 2 BIOS syntax), and therefore it only sees this
sudo grub-install
which, by default is equivalent to
sudo grub-install --efi-directory=/boot/efi
(where, of course, /boot/efi = the mounted sda1-ESP).

I want to say I feel certain of this now!

But enough for tonight, I promise.

[SteveRiley]

grub-efi depends on grub-efi-amd64, which depends on grub2-common, which contains /usr/sbin/grub-install. So it looks like this command is used for both BIOS and UEFI.

[Qqmike]

From Arch.
So here's the grub-install command for UEFI:

# grub-install --target=x86_64-efi --efi-directory=[B]$esp[/B] --bootloader-id=[B]grub[/B]

And here's what Arch says about this:

The --bootloader-id is what appears in the boot options to identity the GRUB EFI boot option; make sure this is something you will recognize later. The install will create a directory of the same name under $esp/EFI/ where the EFI binary bootloader will be placed.
After the above install finished the main GRUB directory is located at /boot/grub/.
...
Note:

• While some distributions require a /boot/efi or /boot/EFI directory, Arch does not.
• --efi-directory and --bootloader-id are specific to GRUB UEFI. --efi-directory specifies the mountpoint of the ESP. It replaces --root-directory, which is deprecated.
• You might note the absence of a <device_path> option (e.g.: /dev/sda) in the grub-install command. In fact any <device_path> provided will be ignored by the GRUB install script, as UEFI bootloaders do not use a MBR or partition boot sector at all.

https://wiki.archlinux.org/index.php...Installation_2

=> So that's where I've read this, and maybe elsewhere somewhere as well.

grub-efi depends on grub-efi-amd64, which depends on grub2-common, which contains /usr/sbin/grub-install. So it looks like this command is used for both BIOS and UEFI.

Possibly. It would be nice to test this in Kubuntu, but I'm lazy to fire up an older BIOS PC I have here; nor do I care to try a CSM/BIOS_boot_partition experiment on my UEFI PC I'm using now ;-) . (Not that I feel I couldn't handle it, of course ...)

It's sometimes difficult to trace these things down in your system. For example, I have both grub-common and grub2-common packages automatically installed on my 14.04 here. And, for example, sometimes it is not clear why/when /usr/lib/grub comes into play. I thought that was the place where any GRUB places its main system files--that's where you'd look (it's where I look) to see whether you had Legacy i386 grub-pc or UEFI grub-efi x86_64-efi.

If grub-efi commands worked for both BIOS and UEFI, that wouldn't present a problem for the user.
Problems arise when you try to use a grub-efi command (like those from Arch above) for UEFI, but then find you don't have native EFI GRUB-support files installed even in a live UEFI DVD/USB, and then you get 'command not found,' 'unrecognized option xyz,' and failure.


Ok, so where are we here? --> Here's where I'm at with this:

(1) The general GRUB EFI command seems to work in my Kubuntu 14.04 and 15.04, based on many experiments. It is this:

grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp --no-nvram

Arch: "Usually, GRUB keeps all files, including configuration files, in /boot, regardless of where the EFI System Partition is mounted. If you want to keep these files inside the EFI System Partition itself, add --boot-directory=$esp to the grub-install command..."

I did not, however, test the --boot-directory=$esp option; but I would expect it to work OK in Kubuntu.
I did not test the --no-nvram option, but, again, I would expect it to work. Why would you use it! Must be for some technical/programming reason. If you create a NVRAM variable, it is easy with efibootmgr to delete it later. But it is much more difficult (syntax-wise) to use efibootmgr to create a NVRAM variable.


(2) Can you use your live Kubuntu DVD/USB to re-install GRUB-EFI in your Kubuntu?

Two answers:

(a) Yes, if you chroot into your broken Kubuntu to do the the grub-install work.
Advantages: you can also run update-grub to generate a new GRUB boot configuration file /boot/grub/grub.cfg. Also, you have all your GRUB machinery (files, libraries, binaries) available in the chroot environment to use.
Disdavantage: You have to be comfortable with chroot, hope all goes well, hope you can mount and unmount everything OK (like your virtual filesystems).

(b) No -- so it seems -- if you do not chroot and instead simply mount your broken system.

It appears to me that in this environment, you do not have GRUB-EFI capability at hand; it appears you have only GRUB Legacy/BIOS commands available from the live DVD/USB.

Advantage of doing it this way ((b) -- no chroot): Easy, quick, not technically "risky" as with chroot.
Disadvantage: You can not run update-grub this way. You must re-boot into your Kubuntu and then run sudo update-grub.
Fact is, I think it's a good idea with whatever method you use to re-install GRUB to re-boot into your Kubuntu afterwards and do it over again using simply:
sudo grub-install (possibly with options if you have some custom system)
sudo update-grub


I'm now curious about case (2)(b).


And, once again, based on my messing around, my opinion so far is

-- GRUB is complex! Its files, its setup, its many versions. E.g., it splits its files between the ESP and the root OS filesystem.

-- The average user dual-booting really should have two things on hand:
rEFInd installed.;
and
a working CD of Boot Repair ready to go.

[SteveRiley]

-- GRUB is complex! Its files, its setup, its many versions. E.g., it splits its files between the ESP and the root OS filesystem.

-- The average user dual-booting really should have two things on hand:
rEFInd installed.;
and
a working CD of Boot Repair ready to go.

This.

GRUB is just an unnecessary pile of complexity for UEFI machines. The firmware itself, along with a simple boot manager like rEFInd or Gummiboot, are all that we need.

[Qqmike]

GRUB is just an unnecessary pile of complexity for UEFI machines. The firmware itself, along with a simple boot manager like rEFInd or Gummiboot, are all that we need.

Yeah, I can't disagree. My story is different: I just like to play with it, learn about it at a high, basic user level. And enough to point posters at something should they have a problem with their GRUB installation. Unless, though, you are a programmer and really understand inner workings, there's a limit to how much you are going to understand. rEFInd is great because as long as you have a kernel--any kernel--laying around somewhere, it can probably find it and make it bootable to you so you can, at least, boot into something, from which you can collect yourself and formulate a repair or data-rescue strategy.