Description of problem: grub.cfg has "linux" and "initrd" instead of "linuxefi" and "initrdefi" commands to load other linux os, and this doesn't work if booting in uefi mode. Version-Release number of selected component (if applicable): How reproducible:always Steps to Reproduce: 1.install a linux os un a uefi bios 2.install fedora (without removing the previous one) 3.try to boot the "first" system Actual results: "you need to load the kernel first" message Expected results: booting the system Workaround: edit the grub.cfg file or the grub menu entry; modify "linux" and "initrd" to "linuxefi" and "initrdefi"
I have this problem with an up-to-date Fedora 20 as well. In this case, I have CentOS 7 and Fedora 20, with Fedora 20 "owning" the boot process. The "grub2-mkconfig --output=/boot/grub2/grub.cfg" command generates linux and initrd commands for CentOS where linuxefi and initrdefi are needed. This seems to be related to bz 1108344 which is supposed to be fixed in Fedora 21. There seem to be a lot of possibly related os-prober bugzillas.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This occurs with a brand-new Fed23 install too. To reproduce: * create 3 disk partitions: EFI, os1, os2 * install Fed23 on partition os1 * install Fed23 on partition os2 The grub menu option for booting into the install on os1 is now broken ("linux/initrd" rather than "linuxefi/initrdefi").
(In reply to Simon K from comment #3) > This occurs with a brand-new Fed23 install too. > > To reproduce: > > * create 3 disk partitions: EFI, os1, os2 > * install Fed23 on partition os1 > * install Fed23 on partition os2 > > The grub menu option for booting into the install on os1 is now broken > ("linux/initrd" rather than "linuxefi/initrdefi"). You cannot multiboot Fedora on UEFI without manual intervention. At the least the boot entry 'Fedora' will be overwritten each time. The entries should all be linuxefi, so that's A problem, but even with that fixed you won't be able to boot the first installed Fedora without setting up a boot entry with a different name. Please attach /var/log/grubby to this bug.
Created attachment 1092638 [details] grub.cfg file generated by second install
Created attachment 1092639 [details] /var/log/grubby from second install
Created attachment 1092640 [details] files in boot dirs on sda3/sda4
Thanks Brian. Simply changing linux->linuxefi and initrd->initrdefi in the "30_os-prober" section of the auto-generated grub.cfg file _works for me_. I'm using that first Fedora install now. Of course I'm aware that the change overwritten when grub.cfg is next regenerated. Or at least that is what grub-mkconfig would do; I'm not sure about grubby. Hmm - that points out to me why you expect multiboot to be configured at the EFI level - the separate installs will fight over this common grub.cfg file. I previously used multiboot on non-efi systems with a separate grub.cfg file per install, and an MBR that (reasonably) stably pointed to just one "primary" grub install. As you point out, under EFI I'll need to create different EFI-level boot entries to get a similar (sane) behaviour - unless grubby is multiboot aware but it appears that this is not a design goal for it. Nevertheless, it would be nice if the "os-prober" stuff created correct "linuxefi" entries for a new install. * Install on sda4 was done on 4 Nov. Updates were applied, ie kernel upgraded to 4.2.5-300 * Install on sda3 was done on 10 Nov. There is a separate EFI partition (of course), but no separate boot-partition, ie there are separate /boot dirs on sda4 and sda3. The grubby logfile is from the second install. Note that for the second install, I did _not_ select the "format EFI partition" option. The contents of EFI/fedora were therefore "left over" from the previous install. AIUI this explains the many error-messages in the logfile - grubby apparently expects the linuxefi= entries to be findable on the current /boot (ie does not look at the earlier "set root=" entry). In case it helps, the disk partition uuids are: * sda4 (os1) = 583ea730-4d83-4960-9ddf-2a0c53cd1613 * sda3 (os2) = 27fe06da-609c-4f7a-8c2d-a371b9779dfe * sda1 (efi) = 86E7-6BD6 By the way, how can grub.cfg be regenerated under Fedora? Under Debian, I used "update-grub".
Existing bugreports that may be related: https://bugzilla.redhat.com/show_bug.cgi?id=1161749 https://bugzilla.redhat.com/show_bug.cgi?id=1108344 https://bugzilla.redhat.com/show_bug.cgi?id=1274288 (dup of this issue?) https://bugzilla.redhat.com/show_bug.cgi?id=1275101 (dup of this issue?)
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.