Merge ~ubuntu-core-dev/grub/+git/ubuntu:sil2100/auto-nvram into ~ubuntu-core-dev/grub/+git/ubuntu:ubuntu

The 'alternative' approach can be found here:

https://code.launchpad.net/~sil2100/grub2/+git/ubuntu/+ref/sil2100/auto-nvram-alternative

But as I said, I am more in favor of the one that's being proposed for merging here.

What is the use of this new feature? How does it differ from --no-nvram?

I'm curious because it seems like this is simply "warning" and skipping setting variables, yet you usually do want to update variables in nearly all cases -- when you can't, this probably should be a critical bug and a proper failure.

I'm also unsure about the implementation, this looks like the behavior of "auto-nvram" and "no-nvram" probably could be merged to some degree.

This won't exactly help dual EFI/non-EFI devices much -- in the case where you're installing from a BIOS-installed system, you won't find the variables anyway to try to update them, and if you're booted in EFI mode, you're detecting whether the variables are there (and they should, as above, if they're not, this is potentially a critical issue; these special cases might well be best served with just --no-nvram). Maybe I've missed some important piece, but I see no logic handling the "I booted in BIOS mode, but I really want both things updated". I also have no idea how to handle such a case anyway.

It differs from --no-nvram as it does attempt updating the EFI variables if present. So my understanding here, and I'm not an expert of the dual EFI/non-EFI installation, is that we would want grub-install for Ubuntu to use --auto-nvram by default for both BIOS and EFI (in all cases).

If we want to have both grub-pc and shim-efi installed, normally a grub-install --target=x86_64-efi from shim-efi would just fail on a BIOS booted system. We can't append --no-nvram to it unconditionally as then in cases when we're booted in EFI, we won't get the variables updated while we should. Instead of detecting from inside shim-efi if we're running in BIOS mode or not, Steve's proposition was to just add the --auto-nvram option which tells grub-install: "if your target is x86_64-efi but there is no access to the NVRAM, don't fail the install as it just means we're in BIOS mode and this is not a critical error as we're probably handling a dual EFI/non-EFI situation".
This would mean we'd just be doing grub-install --target=x86_64-efi --auto-nvram for shim-efi instead. This way, if I understand it correctly of course, we could have both packages co-installed and not erroring out. It's really just migrating the detection from the packaging side (like doing things in postinst) to grub-install getting slightly smarter.

That's my understanding of what I was working on - I might be terribly wrong of course! Steve can give a more detailed explanation probably as he's the author of the proposal.

Created a git-dpm clean branch for merging:

https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/343642