Bug#811311: grub2-common: after grub-install grub reads wrong grub.cfg

[Gregor Zattler]

Hi Steve, sorry for the late reply.
* Steve McIntyre <steve at einval.com> [01. Feb. 2017]:
> On Sat, Jan 28, 2017 at 08:26:57PM +0100, Gregor Zattler wrote:
>>* Steve McIntyre <steve at einval.com> [28. Jan. 2017]:
>>> On Sun, Jan 17, 2016 at 09:47:20PM +0100, grfz wrote:
>>>>
>>>>While running 'main' with sda4 mounted on /boot and sda1 mounted on
>>>>/boot/efi I did
>>>>
>>>>$ sudo grub-install
>>>>grub-install: error: /usr/lib/grub/i386-pc/modinfo.sh doesn't
>>>>exist. Please specify --target or --directory.
>>>>
>>>>which astonished me, but
>>>>
>>>>$ sudo grub-install  --target=x86_64-efi  /dev/sda
>>>>Installing for x86_64-efi platform.
>>>>efibootmgr: EFI variables are not supported on this system.
>>>>efibootmgr: EFI variables are not supported on this system.
>>>>Installation finished. No error reported.
>>> 
>>> OK so you have a system installed expecting to use UEFI, but then
>>> booted in BIOS mode. grub-install checks if you have UEFI support and
>>> will install in that mode if it's available, otherwise it will fall
>>> back to BIOS mode (hence the i386-pc error).
>>
>>Ah, I did'n't know this was possible.  I checked the BIOS and it
>>said enable UEFI but try legacy boot first.
> 
> Right - that's a common setup on many PCs originally supplied with
> Windows 7. It's a really bad default. :-(
> 
>>I changed this to "try UEFI frist".  This chages nothing with
>>respect to this bug report.
> 
> Right.
> 
>>>>I expected grub to use 'main's grub.cfg instead of 'rescue's.
>>> 
>>> How exactly are you booting each of the systems?
>>
>>I simply copy the grub.cfg from the main system to the rescues
>>one.  Computer starts, finds grub, grub loads this grub.cfg.  The
>>main system is the default boot entry.  The boot entry for the
>>rescue system is configured via /etc/grub.d/40_custom.
>>
>>Copying the grub.cfg is OK as a workaround, but sometimes I
>>forget to do this.  This is especially annoying when uprading the
>>rescue system results in a update-grub of the rescue system
>>overwriting the grub.cfg which was produced by the main system.
>>I then am not able to boot the main system without the grub
>>commandline.  But this is doable too.

Reordering your questions:
> One thing I'm surprised about - is os-prober not running on
> each installation, finding the other and adding a reference to
> it in the grub menu? Or have you disabled that?

I don't think I disabled os-prober support, since ATM I do not
know how to do this.  I thought it looks into boot directories
and I even mounted the main systems boot directory when testing.
But os-prober when executed when working with the rescue system
has no output.  But perhaps it searches for root file systems and
the main system is encrypted.  os-prober works as expected when
used from the main system (finds rescue).

At least I now realized that rescues grub was grub-pc.  I purged
it, installed grub-efi-amd64, reinstalled grub from the rescue
system, reinstalled grub from the main system: Same problem, grub
loads the wrong (rescues) grub.cfg.

> To be honest, your problem is that you're using this stuff in a way that
> it's just not designed for. Grub and the Debian automation around it
> is designed to make *a* system bootable, not multiple different OS
> versions on the same system with different configurations. That's why
> grub-install is run automatically, etc,
> 
> You *could* maybe just stop the rescue system from installing at all,
> but then it might not work when you need it.

My bug report is not so ambitious as to manage both systems with
one boot manager.  And the os-prober thing would provide for
that.  What I do not understand is, why grub keeps loading the
grub.cfg from rescues /boot/grub directory/file system even after
installing grub from the main system with all options (--target
[won't work without], --boot-directory, --efi-directory) set.

To me this is still a bug.  Obviously I'm the only one affected
or nagging about this so I'm OK with my workaround especially
since I will reinstall debian on this computer in 2-3 months.
Till then I would be happy to answer questions to my setup but I
understand that this may be of no priority to debian.

Thanks anyway for your attention.

Regards, gregor