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 grub2-common-2.02-39.fc28.noarch grub2-efi-x64-2.02-39.fc28.x86_64 grub2-pc-2.02-39.fc28.x86_64 grub2-pc-modules-2.02-39.fc28.noarch grub2-starfield-theme-2.02-0.40.fc26.x86_64 grub2-tools-2.02-39.fc28.x86_64 grub2-tools-efi-2.02-39.fc28.x86_64 grub2-tools-extra-2.02-39.fc28.x86_64 grub2-tools-minimal-2.02-39.fc28.x86_64 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:
Created attachment 1457599 [details] backuped correct grub.cfg from
Created attachment 1457600 [details] invalid grub config created by grub2-mkconfig
(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?
grubby is installed
Created attachment 1457849 [details] File from /etc/default/grub
(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.
Okay, that did the trick. But why is this BLS thing not working on my system?
Maybe because $sudo ls /boot/loader/entries/ has no results
(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.
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
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.
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.
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.
*** Bug 1649571 has been marked as a duplicate of this bug. ***
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.
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.