Hi Steve, sorry for the late reply. * Steve McIntyre <st...@einval.com> [01. Feb. 2017]: > On Sat, Jan 28, 2017 at 08:26:57PM +0100, Gregor Zattler wrote: >>* Steve McIntyre <st...@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