Bug 1353026

After reviewing grub.cfg, the command "linux" and "initrd" should be "linuxefi" and "initrdefi".

This is probably a grub2 bug, specifically in /etc/grub.d/30_os-prober


   141	  # os-prober returns text string followed by optional counter
   142	  CLASS="--class $(echo "${LABEL}" | LC_ALL=C sed 's,[[:digit:]]*$,,' | cut -d' ' -f1 | tr 'A-Z' 'a-z' | LC_ALL=C sed 's,[^[:alnum:]_],_,g')"
   143	
   144	  sixteenbit=""
   145	  linuxefi="linux"
   146	  initrdefi="initrd"
   147	  case "$machine" in
   148	    i?86|x86_64)
   149	      sixteenbit="16"
   150	      linuxefi="linuxefi"
   151	      initrdefi="initrdefi"
   152	      ;;
   153	    aarch64)
   154	      linuxefi="linux"
   155	      initrdefi="initrd"
   156	  esac
   157	  linux="linux${sixteenbit}"
   158	  initrd="initrd${sixteenbit}"
   159	  # there's no way to tell that the /other/ os is booting through UEFI,
   160	  # but if we are it's an okay bet...
   161	  if [ -d /sys/firmware/efi ]; then
   162	    linux=$linuxefi
   163	    initrd=$initrdefi
   164	  fi


But I'm not following why this fails to include "efi" if /sys/firmware/efi is present at installation time?

Can you edit 30_os-prober, add 'set -x' under the existing 'set -e' line? Then run 'bash -x grub2-mkconfig' and copy that whole output into a text file and attach it to this bug? Maybe we can figure out why the wrong command is used.

Created attachment 1177078 [details]
30_os_prober test results for Chris Murphy

Still can't see anything wrong with the results except it still doesn't select efi commands.

Created attachment 1177104 [details]
Results of running 30_os_prober

First file is my actual 30_os_prober script, this second file is the results from running the file.

I'm at my limit of bashfoo debugging already. But I'm suspicious of the first file, lines 405 - 410 which are:

+ case "$machine" in
+ linux=linux
+ initrd=initrd
+ '[' -d /sys/firmware/efi ']'
+ linux=linux
+ initrd=initrd

They should be linux=linuxefi and initrd=initrdefi.

When I set -x in 10_linux prober, for basically the same code I get:

+ case "$machine" in
+ sixteenbit=16
+ linuxefi=linuxefi
+ initrdefi=initrdefi

My best guess is that something is unsetting $machine variable. If there were a way to edit 30_os-prober to just "print" the variable $machine at line 147, that might be useful. 10_linux sets this variable using uname -m but I don't see that in 30_os-prober, I have no idea how it would get unset.

Just to join in on the fun and to show that the OP isn't the only one. I'm having the same issues on my desktop. Several installed Linux OS's and the same errors. Other bootloaders work just fine, like Ubuntu Mate, Linux Mint, Debian 8, Arch ...

Created attachment 1178504 [details]
fix the machine type test in 30_os-prober.in

Can you test the attached patch?  I think it should work to fix this issue.

Tested the patch with the changed line, machine='uname -m'.  No change in the results.

"grub.cfg" is still generated using the "linux" and "initrd" instead of "linuxefi" and "initrdefi" commands.

By editing the selections at the grub menu, and appending efi to both commands all other OS's will boot as expected.  The logic must be flawed after line 147, somehow switching to use the incorrect commands.

I am experiencing the same problem when generating grub.cfg on F24.
In my case, adding:
machine=`uname -m`
to line 147 solved the problem. I have echo'ed $machine earlier in the 30_os-prober, but it's always empty. So I guess the problem is that $machine is never set in the script. The variable is at least not mentioned in 30_os-prober, but is explicitly set in both 10_linux and 20_linux_xen where it's also used.

I can confirm this bug and I continuously checked whether the issue was solved every time after having installed a new kernel. As of today (upgrade to kernel 4.7.3-200.fc24), I still have to edit the grub menu entry of all other systems manually by adding "efi" to "linux" and "initrd" to boot them.

I get this error to on Fedora 25, I even reported it in a question at Ask Fedora (https://ask.fedoraproject.org/en/question/98034/cannot-boot-other-linux-distributions-via-the-grub-bootloader-setup-by-fedora-25-initrd-and-linux-not-found/). I know that both Arch Linux and Ubuntu 16.04 do not have this GRUB2 issue, so it seems to be a bug localized to Fedora. Surprised it hasn't been solved yet.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. 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 '24'.

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 24 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.

I want to add that nothing changed in fedora 26 - so it is still not solved.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.