Bug 1649571 - 10_linux script with exit 0 in the middle produces unusable grub.cfg
Summary: 10_linux script with exit 0 in the middle produces unusable grub.cfg
Keywords:
Status: CLOSED DUPLICATE of bug 1599445
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-13 21:56 UTC by Zdenek Kabelac
Modified: 2019-01-09 09:57 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-14 10:21:41 UTC


Attachments (Terms of Use)

Description Zdenek Kabelac 2018-11-13 21:56:56 UTC
Description of problem:

Unsure what is the point of 'exit 0' on the line 155  at

/etc/grub.d/10_linux 

in the recent grub package - but it's pretty clear on my system this
is producing unusable grub.cfg for booting.

Somewhat pretty scary...

Commenting the line away fixes the issue for me...

Version-Release number of selected component (if applicable):
grub2-tools-2.02-62.fc30.x86_64.rpm


How reproducible:


Steps to Reproduce:
1. grub2-mkconfig
2.
3.

Actual results:
empty list of kernels from my /boot directory

Expected results:
Usable generated output again

Additional info:

Comment 1 Javier Martinez Canillas 2018-11-14 09:16:21 UTC
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.

Comment 2 Zdenek Kabelac 2018-11-14 10:16:29 UTC
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)

Comment 3 Zdenek Kabelac 2018-11-14 10:21:41 UTC

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

Comment 4 Javier Martinez Canillas 2018-11-14 10:24:47 UTC
(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.

Comment 5 Zdenek Kabelac 2018-11-14 11:05:50 UTC
(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 ??

Comment 6 Zdenek Kabelac 2018-11-14 11:27:49 UTC
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....

Comment 7 Javier Martinez Canillas 2018-11-14 11:39:44 UTC
(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.

Comment 8 Javier Martinez Canillas 2018-11-14 11:40:31 UTC
(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?

Comment 9 Zdenek Kabelac 2018-12-10 16:29:11 UTC
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).

Comment 10 Zdenek Kabelac 2019-01-09 09:57:54 UTC
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....


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