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
Bug 1599445 - grub2-mkconfig creates invalid grub.cfg
Summary: grub2-mkconfig creates invalid grub.cfg
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 28
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
: 1649571 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2018-07-09 20:43 UTC by Heiko Adams
Modified: 2019-03-05 11:45 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-01-29 10:08:23 UTC
Type: Bug

Attachments (Terms of Use)
invalid grub.cfg created by grub2-mkconfig (deleted)
2018-07-09 20:43 UTC, Heiko Adams
no flags Details
backuped correct grub.cfg from (5.77 KB, text/plain)
2018-07-09 20:45 UTC, Heiko Adams
no flags Details
invalid grub config created by grub2-mkconfig (3.19 KB, text/plain)
2018-07-09 20:45 UTC, Heiko Adams
no flags Details
File from /etc/default/grub (335 bytes, text/plain)
2018-07-10 15:10 UTC, Heiko Adams
no flags Details

Description Heiko Adams 2018-07-09 20:43:59 UTC
Description of problem:
Since yesterday my system starts allways with grub in minimal bash like mode. Even after rebuilding the grub.cfg. After some investigation I found out that the grub.cfg seems to bei invalid.

Version-Release number of selected component (if applicable):
$  rpm -qa grub2\* | sort

How reproducible:

Steps to Reproduce:
1. Install the latest grub2 update
2. Backup your working grub.cfg
3. Run grub2-mkconfig -o /boot/grub2/grub.cfg as sudo
4. Reboot your system

Actual results:
Grub start in minimal bash like mode

Expected results:
Grub should start normaly

Additional info:

Comment 1 Heiko Adams 2018-07-09 20:45:07 UTC
Created attachment 1457599 [details]
backuped correct grub.cfg from

Comment 2 Heiko Adams 2018-07-09 20:45:37 UTC
Created attachment 1457600 [details]
invalid grub config created by grub2-mkconfig

Comment 3 Javier Martinez Canillas 2018-07-09 22:09:12 UTC
(In reply to Heiko Adams from comment #2)
> Created attachment 1457600 [details]
> invalid grub config created by grub2-mkconfig

By looking at the grub config file created, this is using the blscfg command which means that attempts to populate the menu entries from BLS fragments.

This is done by the 10_linux script if either GRUB_ENABLE_BLSCFG=true in /etc/default/grub or grubby isn't installed. I guess in your case is the latter?

Comment 4 Heiko Adams 2018-07-10 15:10:17 UTC
grubby is installed

Comment 5 Heiko Adams 2018-07-10 15:10:50 UTC
Created attachment 1457849 [details]
File from /etc/default/grub

Comment 6 Javier Martinez Canillas 2018-07-10 15:13:04 UTC
(In reply to Heiko Adams from comment #5)
> Created attachment 1457849 [details]
> File from /etc/default/grub

You have GRUB_ENABLE_BLSCFG=true there, so should remove that line if you don't want a grub.cfg that looks for BLS fragments to populate the menu entries.

Comment 7 Heiko Adams 2018-07-10 15:55:12 UTC
Okay, that did the trick. But why is this BLS thing not working on my system?

Comment 8 Heiko Adams 2018-07-10 15:57:33 UTC
Maybe because 
$sudo ls /boot/loader/entries/
has no results

Comment 9 Javier Martinez Canillas 2018-07-10 16:05:54 UTC
(In reply to Heiko Adams from comment #8)
> Maybe because 
> $sudo ls /boot/loader/entries/
> has no results

Ah Ok, it was not clear to me from the report that you wanted to use BLS, since the backed grub.cfg had grub menu entries on it.

So to use BLS you should run the grub2-switch-to-blscfg script to populate the BLS fragments in /boot/loader/entries.

Comment 10 Heiko Adams 2018-07-10 16:22:47 UTC
My Problem was that something switched GRUB_ENABLE_BLSCFG in /etc/default/grub to true and generated a new grub.cfg which caused in a non bootable system.

Or in other words: The (automatic?) migration to BLSCFG stopped at half of the way

Comment 11 Javier Martinez Canillas 2018-07-11 16:36:30 UTC
The only action that switches to a grub2 BLS configuration is removing grubby. But you said that grubby was installed in your system in Comment 4.

We changed in 2.02-39.fc28 the path to the BLS directory due feedback on fedora-devel mainling list. It was in /boot/efi/EFI/fedora/loader/entries before and now is in /boot/loader/entries to be consistent with non-EFI systems.

Comment 12 Heiko Adams 2018-07-11 16:52:43 UTC
That's strange because I did *not* change that setting to activate BLS so must be activated (by accident?) by one of the last grub2 updates.

Comment 13 Javier Martinez Canillas 2018-07-11 16:57:12 UTC
That's very strange indeed, I don't see of a change that could have set that variable in /etc/default/grub.

Thanks for the report, I'll double check again if there's something that could have changed the setting.

Comment 14 Zdenek Kabelac 2018-11-14 10:21:41 UTC
*** Bug 1649571 has been marked as a duplicate of this bug. ***

Comment 15 2018-12-05 00:24:33 UTC
hello, in case it helps, i found that the command in the config file should be bls_import instead of blscfg...

made it work on my machine.

Comment 16 Javier Martinez Canillas 2019-01-29 10:08:23 UTC
This bug was due grub2-switch-to-blscfg not copying the latest blscfg module (that contains the blscfg command) and grub2 using the old blscfg that only supported the bls_import command.

This has been fixed in Rawhide / Fedora 30.

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