Bug 1045790

Summary: grub.cfg isn't updated after stage1 download prior to reboot and install
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: fedupAssignee: Will Woods <wwoods>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: seppo.yli-olli, tflink, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-13 17:39:47 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
fedupdebug.log
none
grub.cfg
none
bash -x grub2-mkconfig none

Description Chris Murphy 2013-12-22 00:50:27 UTC 
Description of problem:
When updating a Fedora 19 install to Fedora 20, fedup executes and completes the download stage without errors, but does not reboot into the fedup upgrade environment. Inspection of the grub.cfg reveals a boot entry for System Update (fedup) is missing despite the fedupdebug.log indicating a boot entry has been added.

Version-Release number of selected component (if applicable):
fedup-0.8.9-3.fc19.

How reproducible:
Always

Steps to Reproduce:
1. UEFI Fedora 19 install using installation to Btrfs with boot, root, home as subvolumes (all Btrfs installation), using netinst.iso
2. yum install fedup
3. fedup --network 20 --debuglog fedupdebug.log

Actual results:
fedup reports: Finished. Reboot to start upgrade. I reboot, and there is no fedup boot option in the GRUB menu (attached grub.cfg).

Expected results:
There should be a fedup option in the GRUB menu.

Additional info:
Does fedup leverage grubby to alter the grub.cfg?

-v -d indicates nothing additional from fedupdebug.log

fedup.sysprep INFO: adding new boot entry

Clearly this is bogus, it's not actually doing this successfully.
Comment 1 Chris Murphy 2013-12-22 00:51:10 UTC 
Created attachment 840238 [details]
fedupdebug.log
Comment 2 Chris Murphy 2013-12-22 00:51:23 UTC 
Created attachment 840239 [details]
grub.cfg
Comment 3 Chris Murphy 2013-12-22 00:54:01 UTC 
Work around:
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

This finds /boot/vmlinuz-fedup and /boot/initramfs-fedup.img, creates an entry and the system is updatable.
Comment 4 Chris Murphy 2013-12-22 00:54:38 UTC 
Created attachment 840240 [details]
bash -x grub2-mkconfig
Comment 5 Seppo Yli-Olli 2014-01-12 22:37:08 UTC 
FWIW afaik /boot on Btrfs subvolume isn't a supported configuration. Please see https://bugzilla.redhat.com/show_bug.cgi?id=864198. This kind of installations are now impossible with Anaconda
Comment 6 Seppo Yli-Olli 2014-01-12 22:40:39 UTC 
Uh, correction to earlier: this kind of installations are impossible with F20 version of Anaconda. Potentially the F19 version might be lacking the fix that makes this impossible. Doesn't make it any more supported though.
Comment 7 Chris Murphy 2014-01-12 23:10:44 UTC 
If fedup uses grubby to alter grub.cfg, then the likely problem is bug 864198. If so this bug will be fixed with that bug is fixed.
Comment 8 Will Woods 2014-01-13 17:39:47 UTC 
Yes, fedup uses grubby (via new-kernel-pkg), so this is the same problem as bug 864198.

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