Bug 879089 - grubby call at end of fedup process fails on very fresh install
grubby call at end of fedup process fails on very fresh install
Status: CLOSED DUPLICATE of bug 872088
Product: Fedora
Classification: Fedora
Component: fedup (Show other bugs)
18
All All
unspecified Severity medium
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F18Beta/F18BetaBlocker
  Show dependency treegraph
 
Reported: 2012-11-21 22:02 EST by Adam Williamson
Modified: 2012-11-21 22:47 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-21 22:47:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2012-11-21 22:02:02 EST
Attempting to test fedup for the first time, I did a fresh install of F17 with the updates repo enabled, so I got the latest kernel right off the bat after install. I then ran fedup immediately. At this point, grub2.cfg has never been touched by grubby: it's in pure grub2-mkconfig format.

After downloading all packages, fedup - called according to the instructions at https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop , btw - fails when trying to run grubby, with this traceback:

setting up system for upgrade
Traceback (most recent call last):
  File "/usr/bin/fedup-cli", line 267, in <module>
    main(args)
  File "/usr/bin/fedup-cli", line 244, in main
    prep_boot(kernel, initrd, bootloader=args.bootloader)
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 330, in prep_boot
    modify_bootloader(kernel, initrd)
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 300, in modify_bootloader
    default = bootloader.default_entry()
  File "/usr/lib/python2.7/site-packages/fedup/grubby.py", line 74, in default_entry
    return self.get_entry(self.default_index())
  File "/usr/lib/python2.7/site-packages/fedup/grubby.py", line 50, in get_entry
    out = self._grubby("--info", index)
  File "/usr/lib/python2.7/site-packages/fedup/grubby.py", line 45, in _grubby
    return check_output(cmd + [str(a) for a in args], stderr=PIPE)
  File "/usr/lib64/python2.7/subprocess.py", line 544, in check_output
    raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['grubby', '--info', '-3']' returned non-zero exit status 1

I'm guessing that this is to do with the very clean state of grub2.cfg at this point. Either grubby can't properly handle such a file, or fedup is invoking it wrongly in this case.

Running grubby --info -3 manually returns "grubby: kernel not found". Same for -0, -1, -2 and -4. Cargo culting from another bug - https://bugzilla.redhat.com/show_bug.cgi?id=782555 - apparently pm-utils uses this invocation:

grubby --info /boot/vmlinuz-$(uname -r)

which does work, in this VM. maybe that's a more reliable method?

If this does affect only a very clean fresh install config this probably isn't a blocker, as in practice, people running upgrades are likely to have systems whose grub2.cfg files have been touched by kernel updates.
Comment 1 Adam Williamson 2012-11-21 22:04:54 EST
proposing as Beta blocker just to be safe, but I will test further.
Comment 2 Tim Flink 2012-11-21 22:47:10 EST
This is same backtrace as 872088 which should have been fixed with fedup-0.7.1-1 - marking as a duplicate and transferring proposed blocker status

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

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