Bug 1730771 - Move to BLS breaks grub even on recently installed system
Summary: Move to BLS breaks grub even on recently installed system
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 30
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-17 15:02 UTC by Christopher Engelhard
Modified: 2019-07-17 15:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
grub.cfg after f30 upgrade & grub-install/grub-mkconfig (5.66 KB, text/plain)
2019-07-17 15:02 UTC, Christopher Engelhard
no flags Details
original (working) grub.cfg (7.13 KB, text/plain)
2019-07-17 15:03 UTC, Christopher Engelhard
no flags Details
grubenv after f30 upgrade, grub-install/grub-mkconfig (1.00 KB, text/plain)
2019-07-17 15:04 UTC, Christopher Engelhard
no flags Details
list of modules in /boot/grub/i386-pc (15.35 KB, text/plain)
2019-07-17 15:05 UTC, Christopher Engelhard
no flags Details
gurb-related package versions pre- and post f30 upgrade (646 bytes, text/plain)
2019-07-17 15:06 UTC, Christopher Engelhard
no flags Details

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.


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