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.
Created attachment 840238 [details] fedupdebug.log
Created attachment 840239 [details] grub.cfg
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.
Created attachment 840240 [details] bash -x grub2-mkconfig
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
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.
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.
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 ***