Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1708377 - Unable to boot after upgrade to FC30
Summary: Unable to boot after upgrade to FC30
Keywords:
Status: CLOSED DUPLICATE of bug 1652806
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 30
Hardware: i686
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-09 17:58 UTC by Claude Frantz
Modified: 2019-05-10 09:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-10 09:31:15 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
The file generated with grub2-mkconfig, which has the same contents as /boot/grub2/grub.cfg (5.92 KB, text/plain)
2019-05-09 17:58 UTC, Claude Frantz 		no flags Details
View All

Description Claude Frantz 2019-05-09 17:58:20 UTC 
Created attachment 1566319 [details]
The file generated with grub2-mkconfig, which has the same contents as /boot/grub2/grub.cfg

Description of problem:

I have upgraded from 32 bit Fedora 28 to 30 using dnf system-upgrade, exactly as found in the Fedora documents. All was OK, up to dnf system-upgrade reboot. The started system has upgraded the packages, with cleanup and verify. After numerous hours, the system has restarted but grub cannot boot and it enters the grub command mode.

Using CD rescue disk, I have verified the hard disk and every partition on it using fdisk an fsck. Not problem encountered. I have verified in /boot/ and I have found vmlinuz and initramfs having the expected endings and a size which looks OK.

But /boot/grub2/grub.cfg is strange and very different from the usual structure.

I have booted from the grub command line using configfile /grub2/grub.cfg.rpmsave and I was able to boot as under Fedora 28. I have tried to generate a tentative grub.cfg using grub2-mkconfig and I have put it in /tmp/ in order to compare it with /boot/grub2/grub.cfg. The result: It is exactly the same.

What can I do in order to make the system running well as Fedora 30 as expected ?

Is it a good idea to run dnf update while running this old kernel 28 ?


Version-Release number of selected component (if applicable):

30

How reproducible:

Always.

Steps to Reproduce:
1. booting
2.
3.

Actual results:

command expected by grub shell

Expected results:

A well running system

Additional info:
Comment 1 Claude Frantz 2019-05-10 09:16:39 UTC 
While booting the system using /boot/grub2/grub.cfg.rpmsave and using the lastest fc28 kernel, I was able to fix the situation. I have entered grub2-install /dev/sda, then rebooted. Now the expected grub2 menu appears.

My suggestion: Please insert an appropriate test in dnf's system-upgrade plugin, which has to test if the current system needs this grub2-install command. Then it should display an appropriate warning so that the user gets the ability to run this command.
Comment 2 Javier Martinez Canillas 2019-05-10 09:31:15 UTC 

*** This bug has been marked as a duplicate of bug 1652806 ***
Comment 3 Javier Martinez Canillas 2019-05-10 09:34:15 UTC 
(In reply to Claude Frantz from comment #1)
> While booting the system using /boot/grub2/grub.cfg.rpmsave and using the
> lastest fc28 kernel, I was able to fix the situation. I have entered
> grub2-install /dev/sda, then rebooted. Now the expected grub2 menu appears.
> 

Yes, this is documented in https://fedoraproject.org/wiki/Common_F30_bugs#GRUB_boot_menu_is_not_populated_after_an_upgrade.

> My suggestion: Please insert an appropriate test in dnf's system-upgrade
> plugin, which has to test if the current system needs this grub2-install
> command. Then it should display an appropriate warning so that the user gets
> the ability to run this command.

There's no way to know how old is the GRUB core that's installed in the gap between the MBR and the start of the first partition. This bug is a consequence of never updating the GRUB core.img. We are considering now updating it at least on each system wide upgrade, even if this may cause issues to people having custom setups or doing dual boot and using the GRUB from other distro.
Note You need to log in before you can comment on or make changes to this bug.