Bug 966586 - System doesn't boot after upgrade on UEFI
Summary: System doesn't boot after upgrade on UEFI
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker https://fedoraproject...
Depends On:
TreeView+ depends on / blocked
Reported: 2013-05-23 14:09 UTC by Petr Schindler
Modified: 2013-05-29 00:12 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-05-29 00:12:12 UTC
Type: Bug

Attachments (Terms of Use)
fedup.log (762 bytes, text/x-log)
2013-05-23 14:12 UTC, Petr Schindler
no flags Details
upgrade.log (427.71 KB, text/plain)
2013-05-23 14:13 UTC, Petr Schindler
no flags Details
/EFI/grub.cfg (7.72 KB, text/plain)
2013-05-23 14:14 UTC, Petr Schindler
no flags Details
output from journalctl -a (414.08 KB, text/plain)
2013-05-23 14:15 UTC, Petr Schindler
no flags Details
picture of grub fail message (55.94 KB, image/jpeg)
2013-05-23 14:23 UTC, Petr Schindler
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 949761 0 unspecified CLOSED EFI installed system fails to boot (Fedora-19-Alpha-TC5) 2021-02-22 00:41:40 UTC

Internal Links: 949761

Description Petr Schindler 2013-05-23 14:09:33 UTC
Description of problem:
I installed fully updated F18. Then I run upgrade be fedup (f18 was installed with netinst, so there was no kernel update before upgrade). After finishing upgrade the newly installed system doesn't start (not even the grub).

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

How reproducible:

Steps to Reproduce:
1. install fully updated f18 (via netinst)
2. run fedup

Actual results:
upgraded system doesn't boot

Expected results:

Additional info:

Comment 1 Petr Schindler 2013-05-23 14:12:46 UTC
Created attachment 752241 [details]

Comment 2 Petr Schindler 2013-05-23 14:13:45 UTC
Created attachment 752242 [details]

Comment 3 Petr Schindler 2013-05-23 14:14:39 UTC
Created attachment 752243 [details]

Comment 4 Petr Schindler 2013-05-23 14:15:21 UTC
Created attachment 752244 [details]
output from journalctl -a

Comment 5 Petr Schindler 2013-05-23 14:17:03 UTC
File from comment 2 is upgrade.log sorry for confusion.

I also forgot to mention, that this happens on UEFI machine.

Comment 6 Fedora Blocker Bugs Application 2013-05-23 14:20:31 UTC
Proposed as a Blocker for 19-beta by Fedora user pschindl using the blocker tracking app because:

 This bug violates the 'upgrade requirements' criterion

Comment 7 Petr Schindler 2013-05-23 14:23:05 UTC
Created attachment 752249 [details]
picture of grub fail message

Comment 8 Adam Williamson 2013-05-23 14:59:39 UTC
This is almost certainly just https://bugzilla.redhat.com/show_bug.cgi?id=949761 come back to haunt us: we worked around that by going to console mode by default for new F19 installs, but F18 installs were graphical and fedup doesn't touch the grub config.

If so, I think we could work around this in fedup or simply fix it in grub2 and fedup would pick up the fixed package, so I don't think we need to re-spin to fix this. But it'd be good if wwoods and pjones could check my interpretation. Especially given how long I've been awake.

Comment 9 Jóhann B. Guðmundsson 2013-05-23 15:42:23 UTC
+1 blocker EFI install are getting commonly used these days and since these seems to have been know by alpha we really ought to have fixed this by now...

Comment 10 Adam Williamson 2013-05-23 15:56:43 UTC
it actually was known at alpha, we just kinda forgot about it.

we kinda need to take a look at how we deal with upgrade issues in general, now the 'normal' way to upgrade is from the mirrors via fedup; very few upgrade bugs will actually require fixing in the frozen set any more. for instance, in this case, I'm pretty sure that all we need to do is submit grub2-2.00-18.fc19 as an update; fedup will then install that grub2 on upgrades and it ought to work (as it has a fix for 949761).

Comment 11 Jóhann B. Guðmundsson 2013-05-23 16:16:38 UTC
We just need rip the "official supported" stamp of upgrades and get it out of the ( blocker ) criteria. There is and never has been any chance for us to properly support and cover users various package mixtures in the project nor any way for us to allow users to fallback on encase of failure heck Gnome itself alone is making incompatible changes between minor releases. 

Will of all people should have know what it would do to us in QA with offical status.

And how fedup manage to magically inherent that official status is beyond my comprehension and smells like a rotten egg. 

It's an new app from scratch and if I'm not mistaken ( since I have not tested it recently )it ( or plymouth ) still lacks progress bar, still just dumps the output from journal if you press esc everytime and still suffers from proper supporting encrypted volume ( plymouth/password prompt )

Comment 12 Kamil Páral 2013-05-23 16:30:04 UTC
I re-tested Petr's findings. I changed grub.cfg to use console mode instead of graphical mode in F18 UEFI and only then started the upgrade. Everything went smooth and the new system boots (the new grub menu is a bit messy - rescue mode before standard boot - but it works well).

This can probably be fixed in fedup itself, and therefore I'd say -1 blocker here.

Comment 13 Adam Williamson 2013-05-23 17:28:53 UTC
Discussed at 2013-05-23 Fedora 19 Beta Go/No-Go meeting, acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting-2/2013-05-23/f19_beta_gono-go_meeting.2013-05-23-17.01.log.txt . Rejected as a blocker on the basis that most upgrades (non-UEFI ones) work, this can be worked around (by setting grub to console mode before upgrading), and it can be recovered from if you hit it (by setting grub to console mode from a live image or recovery mode after upgrading).

Note that as explained in comment #10 we can, and intend to, fix this just by putting the grub2 package that fixes 949761 in the F19 repos; it doesn't require changes to the frozen package set or the RC4 media. We will get it to updates-testing in the next day or two and hopefully to stable soon after that. Then upgrades will pick it up and this bug will go away.

Comment 14 Will Woods 2013-05-24 14:45:08 UTC
(In reply to Jóhann B. Guðmundsson from comment #11)
> It's an new app from scratch and if I'm not mistaken ( since I have not
> tested it recently )it ( or plymouth ) still lacks progress bar

Not relevant to this bug, but the graphical progress bar has been working since December, at least.

> and still suffers
> from proper supporting encrypted volume ( plymouth/password prompt )

Again: not relevant, but this was fixed in March:

> We just need rip the "official supported" stamp of upgrades and get it out
> of the ( blocker ) criteria. There is and never has been any chance for us
> to properly support and cover users various package mixtures...

Discussion of QA/distro policy is *definitely* outside the scope of this bug.
Please take it to IRC or a mailing list.

Comment 15 Adam Williamson 2013-05-25 17:20:21 UTC
The new grub2 package is now in updates-testing:


so can someone check that? (I'll see if I can be that someone, but maybe not). If possible it'd be ideal if we can get it pushed stable by Beta release day.

Comment 16 Kamil Páral 2013-05-28 09:37:22 UTC
grub2-2.00-18.fc19 fixes the problem, but it does not force text mode, as I though it would. Grub still displays in a graphical mode, but it works ok.

I don't know whether to close this, someone informed please adjust accordingly.

Comment 17 Adam Williamson 2013-05-29 00:12:12 UTC
Kamil: that's fine, the intended fix was 'make graphical work' not 'force text on upgrades'. In fact I think the current anaconda code is intended to use graphical grub2 for fresh F19 UEFI-native installs now.

So as -18 is stable now, this can be closed.

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