Bug 1353026 - Updating Grub2 w/multiple Linux OS's F24 is the only correct boot menu entry, others will not boot.
Updating Grub2 w/multiple Linux OS's F24 is the only correct boot menu entry,...
Status: NEW
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: CommonBugs
Depends On:
  Show dependency treegraph
Reported: 2016-07-05 16:17 EDT by Ron Field
Modified: 2017-07-26 17:35 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
30_os_prober test results for Chris Murphy (11.64 KB, text/plain)
2016-07-06 19:38 EDT, Ron Field
no flags Details
Results of running 30_os_prober (72.42 KB, text/plain)
2016-07-06 20:31 EDT, Ron Field
no flags Details
fix the machine type test in 30_os-prober.in (696 bytes, patch)
2016-07-11 13:38 EDT, Peter Jones
no flags Details | Diff

  None (edit)
Description Ron Field 2016-07-05 16:17:28 EDT
CentOS 7, Ubuntu 16.04 and Fedora 24 on different gpt partitions.  When updating Grub F24 correctly uses the linuxefi and initrdefi command to boot.  All other OS entries are 'linux' and 'initrd'.  Boot attempts for other OS entries results in error: linux 'command not found'
error: initrd 'command not found'

Version-Release number of selected component (if applicable):

How reproducible: Fresh install F24 on HDD, gpt partitions with another gpt having any other linux distro, i.e., CentOS

Steps to Reproduce:
1.After installation boot to any other OS.

Actual results:

Expected results:

Additional info:
Comment 1 Ron Field 2016-07-05 17:49:43 EDT
After reviewing grub.cfg, the command "linux" and "initrd" should be "linuxefi" and "initrdefi".
Comment 2 Chris Murphy 2016-07-06 17:33:39 EDT
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')"
   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.
Comment 3 Ron Field 2016-07-06 19:38 EDT
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.
Comment 4 Ron Field 2016-07-06 20:31 EDT
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.
Comment 5 Chris Murphy 2016-07-06 23:06:15 EDT
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.
Comment 6 Glenn Johnson 2016-07-07 18:28:24 EDT
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 ...
Comment 7 Peter Jones 2016-07-11 13:38 EDT
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.
Comment 8 Ron Field 2016-07-11 20:18:13 EDT
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.
Comment 9 Endre Bjørsvik 2016-08-19 16:30:42 EDT
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.
Comment 10 cl-netbox 2016-09-14 05:57:03 EDT
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.
Comment 11 Brenton Horne 2016-12-07 19:05:36 EST
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.
Comment 12 Fedora End Of Life 2017-07-25 17:36:39 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.