On Fedora 30 / Rawhide we changed the bootloader configuration to use BootLoaderSpec snippets by default, see https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault.

That exit 0 line is only in the code path when GRUB_ENABLE_BLSCFG=true in /etc/default/grub.

What do you mean by unusable? Did /boot/loader/entries files not got populated in your machine?

If you don't want to use BLS, you can remove GRUB_ENABLE_BLSCFG from /etc/default/grub and install the grubby-deprecated package. That will have the old behaviour with the boot entries being added to the grub.cfg file.

Hmm I'm not really an expert here -  and I really have this in my /etc:

  GRUB_ENABLE_BLSCFG=true in /etc/default/grub.

I'm not sure about the reasoning why I've it there - it was likely adviced me in past to fix some other strange logic of grub menu creation.

I can also confirm when I drop  "GRUB_ENABLE_BLSCFG=true" - the 'exit 0' can stay in 10_linux script file and menu entries are emitted.

But I'm unclear why this change was needed,  but maybe  the tool should report to user/prompt that he might expect troubles or that there is behavior change ahead if the variable is kept in the config file  (like unbootable menu system with just  'memtest' booting option left in)

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

(In reply to Zdenek Kabelac from comment #2)
> Hmm I'm not really an expert here -  and I really have this in my /etc:
> 
>   GRUB_ENABLE_BLSCFG=true in /etc/default/grub.
> 
> I'm not sure about the reasoning why I've it there - it was likely adviced
> me in past to fix some other strange logic of grub menu creation.
> 
> I can also confirm when I drop  "GRUB_ENABLE_BLSCFG=true" - the 'exit 0' can
> stay in 10_linux script file and menu entries are emitted.
> 
> But I'm unclear why this change was needed,  but maybe  the tool should
> report to user/prompt that he might expect troubles or that there is
> behavior change ahead if the variable is kept in the config file  (like
> unbootable menu system with just  'memtest' booting option left in)

Well, the system should never be unbootable. Either GRUB_ENABLE_BLSCFG is set and grub.cfg contains a blscfg command that populates the boot menu entries from BLS files in /boot/loader/entries or GRUB_ENABLE_BLSCFG isn't set and the boot entries are defined in the grub.cfg file itself.

Any other behaviour is a bug. I wonder if the problem is that you already had GRUB_ENABLE_BLSCFG defined in /etc/default/grub and so the script that switching to a BLS configuration (grub2-switch-to-blscfg) skipped creating the BLS entries.

(In reply to Javier Martinez Canillas from comment #4)
> Well, the system should never be unbootable. Either GRUB_ENABLE_BLSCFG is
> set and grub.cfg contains a blscfg command that populates the boot menu
> entries from BLS files in /boot/loader/entries or GRUB_ENABLE_BLSCFG isn't
> set and the boot entries are defined in the grub.cfg file itself.

I can see files in  /boot/loader/entries - but in the 'grub' menu the only listed line was  'memtest'

> 
> Any other behaviour is a bug. I wonder if the problem is that you already
> had GRUB_ENABLE_BLSCFG defined in /etc/default/grub and so the script that
> switching to a BLS configuration (grub2-switch-to-blscfg) skipped creating
> the BLS entries.

Should there be something else in grub menu to allow me to boot from those loader entries - or it's something totally different ?

Note - my Rawhide was installed many many years back and being just continuously upgraded - so maybe I miss something installed on my system ??

A side comment - looking over some of our buildbot kvm machines - they also do seem to contain this keyword - so likely is has got there during some installation or grub2-tools upgrade  (Since I'm almost 100% sure none touched these settings there)

So it could be eventually way more common trouble....

(In reply to Zdenek Kabelac from comment #5)
> (In reply to Javier Martinez Canillas from comment #4)
> > Well, the system should never be unbootable. Either GRUB_ENABLE_BLSCFG is
> > set and grub.cfg contains a blscfg command that populates the boot menu
> > entries from BLS files in /boot/loader/entries or GRUB_ENABLE_BLSCFG isn't
> > set and the boot entries are defined in the grub.cfg file itself.
> 
> I can see files in  /boot/loader/entries - but in the 'grub' menu the only
> listed line was  'memtest'
>
> > 
> > Any other behaviour is a bug. I wonder if the problem is that you already
> > had GRUB_ENABLE_BLSCFG defined in /etc/default/grub and so the script that
> > switching to a BLS configuration (grub2-switch-to-blscfg) skipped creating
> > the BLS entries.
> 
> Should there be something else in grub menu to allow me to boot from those
> loader entries - or it's something totally different ?
>

yes, the grub.cfg file should contain a call to the blscfg command. Can you please share your complete grub.cfg?
 
> Note - my Rawhide was installed many many years back and being just
> continuously upgraded - so maybe I miss something installed on my system ??

could be, on the latest grubby upgrade the system should had switched to a BLS configuration but maybe something went wrong.

(In reply to Zdenek Kabelac from comment #5)
> (In reply to Javier Martinez Canillas from comment #4)
> > Well, the system should never be unbootable. Either GRUB_ENABLE_BLSCFG is
> > set and grub.cfg contains a blscfg command that populates the boot menu
> > entries from BLS files in /boot/loader/entries or GRUB_ENABLE_BLSCFG isn't
> > set and the boot entries are defined in the grub.cfg file itself.
> 
> I can see files in  /boot/loader/entries - but in the 'grub' menu the only
> listed line was  'memtest'
> 
> > 
> > Any other behaviour is a bug. I wonder if the problem is that you already
> > had GRUB_ENABLE_BLSCFG defined in /etc/default/grub and so the script that
> > switching to a BLS configuration (grub2-switch-to-blscfg) skipped creating
> > the BLS entries.
> 
> Should there be something else in grub menu to allow me to boot from those
> loader entries - or it's something totally different ?
> 
> Note - my Rawhide was installed many many years back and being just
> continuously upgraded - so maybe I miss something installed on my system ??

Do these systems still contain a grub.cfg with the menu entries there or also became unbootable?

Ok I'll still add some comment here.


Over the last couple weeks - many 'rawhide' upgrades  ended with similar unbootable system state.

Something keeps adding  'GRUB_ENABLE_BLSCFG=true' into /etc/default/grub.

For now I've used brute-force  fix   'chattr +i /etc/default/grub'

Once just must not forget to do this when another 'rawhide' box gets in my hands....
(grub2 require quite a few commands to be entered properly to boot again - including knowing which partition has root filesystem).

So since I've seen someone with rawhide and  BLSCFG true to have bootable machine with entries - it has made me curious why this doesn't work for me.

And it looks the final solution is to reinstall grub on boot partition.

So after running  'grub2-install --force /dev/sda1'  - it has made the whole thing running.

And just for curiosity - my previous 'grub' screen reported  'Grub 2.00'  and core.img  had size 30414 md5: 8fa7441bafe1c9493c469aec7e4ec7c7

So IMHO  before  'grub2-mkconfig' starts to *USE*  BLS it should check the installed grub is actually capable of using it.


Maybe this info will help other users as well - since I was definitely not the only one hitting this issue....