Bug 1730771

Summary: Move to BLS breaks grub even on recently installed system
Product: [Fedora] Fedora Reporter: Christopher Engelhard <ce>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: fmartine, lkundrak, pjones
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: 2020-03-20 17:14:09 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:
Attachments:
Description Flags
grub.cfg after f30 upgrade & grub-install/grub-mkconfig
none
original (working) grub.cfg
none
grubenv after f30 upgrade, grub-install/grub-mkconfig
none
list of modules in /boot/grub/i386-pc
none
gurb-related package versions pre- and post f30 upgrade none

Description Christopher Engelhard 2019-07-17 15:02:28 UTC 
Created attachment 1591438 [details]
grub.cfg after f30 upgrade & grub-install/grub-mkconfig

(Likely related to bug 1652806, opening a separate bug so as not to add to the noise over there)

After upgrading to f30, I'm experiencing problems similar to those described in the Common Bugs [1]:

 - BIOS-based machine
 - upgrade concluded without issues
 - on reboot, machine gets stuck in grub
 - using /boot/grub2/grub.cfg.rpmsave allows booting without issues

However,

 1) the problem persists even after reinstalling grub to the bios_grub partition
 2) this machine was originally installed with f28

so I think this is not quite the same bug.

Further info:
- BIOS-based x86_64 bare-metal server
- GPT-partitioned BTRFS-Raid, each disk has bios_grub partition & grub installed to same
- originally installed with f28
- the installed grub pre-upgrade was most likely from f28. I might updated after the f29 upgrade, but it's unlikely. If so, it would have happened within approx. 1 month of the f29 release
- increment.mod and blscfg.mod are both present on the boot partition now, I don't know if that was the case before I tried fixing the issue with grub-install

[1] https://fedoraproject.org/wiki/Common_F30_bugs#GRUB_boot_menu_is_not_populated_after_an_upgrade
Comment 1 Christopher Engelhard 2019-07-17 15:03:40 UTC 
Created attachment 1591439 [details]
original (working) grub.cfg
Comment 2 Christopher Engelhard 2019-07-17 15:04:28 UTC 
Created attachment 1591440 [details]
grubenv after f30 upgrade, grub-install/grub-mkconfig
Comment 3 Christopher Engelhard 2019-07-17 15:05:30 UTC 
Created attachment 1591441 [details]
list of modules in /boot/grub/i386-pc
Comment 4 Christopher Engelhard 2019-07-17 15:06:14 UTC 
Created attachment 1591442 [details]
gurb-related package versions pre- and post f30 upgrade
Comment 5 Christopher Engelhard 2019-07-17 15:10:31 UTC 
In the various bugs related to BLS, the potential issue of the install order of various grub-related packages came up, so here is it for my machine:

root@rescue / # rpm -qa --last | grep grub
grubby-8.40-31.fc30.x86_64                    Wed 17 Jul 2019 09:46:58 AM CEST
grub2-tools-efi-2.02-81.fc30.x86_64           Wed 17 Jul 2019 01:07:39 AM CEST
grub2-pc-2.02-81.fc30.x86_64                  Wed 17 Jul 2019 01:06:24 AM CEST
grub2-tools-extra-2.02-81.fc30.x86_64         Wed 17 Jul 2019 01:03:56 AM CEST
grub2-tools-2.02-81.fc30.x86_64               Wed 17 Jul 2019 12:58:17 AM CEST
grub2-tools-minimal-2.02-81.fc30.x86_64       Wed 17 Jul 2019 12:57:54 AM CEST
grub2-pc-modules-2.02-81.fc30.noarch          Wed 17 Jul 2019 12:55:25 AM CEST
grub2-common-2.02-81.fc30.noarch              Wed 17 Jul 2019 12:54:01 AM CEST

Ignore grubby, that was updated again this morning, so that time is the wrong one.
Comment 6 Javier Martinez Canillas 2020-03-20 11:09:49 UTC 
Is this issue still present?
Comment 7 Christopher Engelhard 2020-03-20 17:14:09 UTC 
I tested it right now (I had just used the old .cfg since reporting this bug) and the issue seems to be resolved.

Generating the new grub.cfg failed initially because of an invalid environment. I had a look at /boot/grub2/grubenv and it was EMPTY, so now I wonder whether that was the issue all along ... unfortunately I don't remember if I checked that at the time.

So now after 'grub2-editenv create' and 'grub2-mkconfig -o /boot/grub2/grub.cfg' everything seems to be fine.