On Apr 8, 2014, at 9:19 AM, Fred New <fred.new2...@gmail.com> wrote:
>
>
>
> On Tue, Apr 8, 2014 at 7:30 AM, Adam Williamson <awill...@redhat.com> wrote:
>
>> In what way? I wrote it, just a month or two ago. I'm not aware of
>> anything in it which is outdated.
>>
> Sorry, my mistake. I thought this one also referred to Fedora 18.
It does. And for UEFI it's the same since Fedora 18.
a. Anything after grub2-install is ignored because the target must be mounted,
typically that's at /boot/efi.
b. If you actually use grub2-install and overwrite the existing grubx64.efi on
the EFI System partition, it breaks UEFI Secure Boot computers ability to boot
Fedora because the resulting bootloader will not be signed.
c. Even if you don't use Secure Boot, the custom created grubx64.efi (core.img)
is sufficiently different in behavior from the prebaked grubx64.efi that you
may want to pull your hair out anyway.
So everyone just needs to stop recommending reinstalling grub this way. Chances
are the only reason grub would need to be reinstalled is if the EFI System
partition file system is actually fakaked. There isn't a reason for it to
become deleted. So the repair scenario is quite a bit more difficult than
before: unmount the ESP, reformat the ESP, remount it, reinstall shim and
grub2-efi packages, run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg.
And then grep -i efibootmgr /var/log/anaconda/anaconda.program.log.
Use the resulting commands, and the last one with path to shim.efi should use
double \\. That ought to delete the old Fedora entry and put in a new one.
> The main problem
> I had was the UEFI boot order problem mentioned below. This page doesn't tell
> me how to use efibootmgr to fix that.
>
>
> > If you have UEFI and you have run grub2-install, you need to un-do that by
> > re-installing
> > grub2-efi:
> >
>> > yum reinstall grub2-efi
>
>> That won't 'undo' anything. The grub2-efi package doesn't actually have
>> any scripts, so reinstalling it doesn't really do anything much.
Ahh well, if someone has run grub2-install, reinstalling grub2-efi ought to
cause the signed grubx64.efi to be reinstalled which is at least going to get
them more consistency with Fedora proper as clean installed.
>
>
> Well in my case, reinstalling grub2-efi caused GRUB2 to stop reading the
> configuration file from /boot/grub2/grub.cfg and to start reading from
> /boot/efi/EFI/fedora/grub.cfg again.
grub2-install core.img/grubx64.efi looks to /boot/grub2/ for grub.cfg, the
prebaked one in grub2-efi looks for it on the ESP in /EFI/fedora/
> I didn't have to re-run grub2-mkconfig
> because the configuration file was already built during the last kernel
> update. I haven't tried booting Windows from my GRUB menu since this
> fix, but I suspect it will work again, too. With the grub2-install GRUB, it
> couldn't find Windows because it wasn't looking in the EFI partition.
>
>
> > And since Windows on my system places itself first in the EFI boot list
> > every time it
> > is booted,
>
> That's likely an issue in your system's firmware or Windows install
> (somehow). It shouldn't be doing that.
>
> Yes, it seems that any time I touch my firmware configuration ("BIOS
> settings") or interrupt the boot sequence to boot Windows (after I've
> managed to put Fedora first), the boot order resets to Windows first.
> It may not be Windows doing it. I cannot move Fedora to the top of
> the list using the "BIOS settings", I need to use efibootmgr for that.
Ick. Well, every firmware's boot manager is different. The idea is that we
should have a UI to choose which bootloader to use and therefore which OS to
boot. But if your firmware doesn't offer a boot manager UI to choose an OS
loader, well you're kinda stuck having to hack on grub to get it to find and
chainload (I think it's multiboot on UEFI actually) the Windows bootloader.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
