Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1706447

Summary:	grub2-tools contains a buggy /etc/grub.d/10_linux file
Product:	[Fedora] Fedora	Reporter:	Federico Vaga <federico.vaga>
Component:	grub2	Assignee:	Peter Jones <pjones>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	30	CC:	fedora, fmartine, lkundrak, mihai, pjones, stefanrin
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-10-15 07:38:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Federico Vaga 2019-05-04 22:15:12 UTC

Description of problem:
The tool `grub2-mkconfig` does not generate any 'menuentry' for linux kernels

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

grub2-tools-1:2.02-78.fc30.x86_64

How reproducible:

Just run `grub2-mkconfig`

Actual results:

`grub2-mkconfig` output does not have any 'menuentry'

Expected results:

A 'menuentry' for each kernel installed

Additional info:

After some investigation (I added -x to grub.d/10_linux) I found out that actually all kernels are found, but the script does not output any 'menuentry' because of an `exit 0` command in the middle of the code (line 186). If I remove it, I can generate a valid 'grub.cfg' file

I do not know where that `exit 0` comes from because it is not there in the grub source code. I re-installed the package and that `exit 0` is still there.

Comment 1 Stefan Ring 2019-05-06 11:19:03 UTC

Having the same problem. Removing "exit 0" works. I left my workstation for an hour letting it upgrade FC28 -> FC30 and was greeted with a Windows boot error when I came back, because all Fedora entries have been wiped from the grub config.

Comment 2 Stefan Ring 2019-05-06 19:01:25 UTC

Apparently this has to do with https://src.fedoraproject.org/rpms/grub2/blob/e95ccc7ba603301637dc95fcc29d916624d9fcf0/f/0112-Add-BLS-support-to-grub-mkconfig.patch

Maybe something has set this variable (GRUB_ENABLE_BLSCFG) in /etc/default/grub. I'm not at the affected system right now, so I cannot poke around. Or more likely, maybe a default has changed?

Comment 3 Stefan Ring 2019-05-06 20:36:10 UTC

Exactly, https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault

Having read https://systemd.io/BOOT_LOADER_SPECIFICATION, it seems that the boot loader does not find these entries, probably because of looking for them in the wrong place.

Comment 4 Federico Vaga 2019-05-06 21:30:00 UTC

I confirm that the default has changed, I got GRUB_ENABLE_BLSCFG="true" on my system automatically. If I change it to "false" then `grub2-mkconfig` works again as expected.

Comment 5 Federico Vaga 2019-05-06 21:49:05 UTC

I think that re-installing the bootloader fixes the problem and then those entries described in the BOOT_LOADER_SPECIFICATION  (`grub2-install`) magically appear during boot.
Unfortunately, yesterday I did it (`grub2-install`) without knowing about this change, so I cannot guarantee that this is the fix: but now it works.

/etc/default/grub: GRUB_ENABLE_BLSCFG="true"

`grub2-mkconfig` does not generate kernel entries

grub2 at boot can see my kernels even if they are not described in grub.cfg

Comment 6 Mihai Lazarescu 2019-08-07 01:45:35 UTC

(In reply to Stefan Ring from comment #1)
> Having the same problem. Removing "exit 0" works.

Exactly. This is the patch:

--- 10_linux.original	2019-08-07 03:40:59.316365809 +0200
+++ 10_linux.modified	2019-08-07 03:41:39.253946047 +0200
@@ -180,7 +180,7 @@
 	fi
     fi
 
-    exit 0
+    #exit 0
   fi
 
   if [ x$type != xsimple ] ; then

Comment 7 Stefan Ring 2019-08-07 19:22:43 UTC

The basic problem seems to be that grub does not get updated during system upgrades. My machine was installed in 2015 or 2016 and upgraded through quite some Fedora releases ever since. I assume that this old grub just does not know the first thing about BLS loader entries.

Comment 8 Javier Martinez Canillas 2019-10-15 07:38:23 UTC


*** This bug has been marked as a duplicate of bug 1652806 ***

Comment 9 Christian Stadelmann 2019-10-15 17:51:47 UTC

(In reply to Javier Martinez Canillas from comment #8)
> 
> *** This bug has been marked as a duplicate of bug 1652806 ***

@fmartine: Are you sure that it is a duplicate? It may also be just one potential reason for bug #1652806 among other issues.

Comment 10 Javier Martinez Canillas 2019-10-16 08:46:30 UTC

Yes, I'm pretty sure. The bug says that the early exit in the 10_linux script is a bug but it's not. That just prevents the non-BLS menuentry commands to be added into the grub.cfg so that's why removing the exit makes them work.

The real issue is the installed GRUB core.img is not compatible with the blscfg module (Bug #1652806) and this is because GRUB never gets updated in a package upgrade.

And as mentioned in Comment 5, the reported said that running grub2-install fixed the issue (because GRUB gets updated in that case).