Bug 966586 - System doesn't boot after upgrade on UEFI
System doesn't boot after upgrade on UEFI
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
RejectedBlocker https://fedoraproject...
: CommonBugs
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-23 10:09 EDT by Petr Schindler
Modified: 2013-05-28 20:12 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-28 20:12:12 EDT
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)
fedup.log (762 bytes, text/x-log)
2013-05-23 10:12 EDT, Petr Schindler
no flags Details
upgrade.log (427.71 KB, text/plain)
2013-05-23 10:13 EDT, Petr Schindler
no flags Details
/EFI/grub.cfg (7.72 KB, text/plain)
2013-05-23 10:14 EDT, Petr Schindler
no flags Details
output from journalctl -a (414.08 KB, text/plain)
2013-05-23 10:15 EDT, Petr Schindler
no flags Details
picture of grub fail message (55.94 KB, image/jpeg)
2013-05-23 10:23 EDT, Petr Schindler
no flags Details

  None (edit)
Description Petr Schindler 2013-05-23 10:09:33 EDT
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):
fedup-0.7.3-4.fc18

How reproducible:
100%

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 10:12:46 EDT
Created attachment 752241 [details]
fedup.log
Comment 2 Petr Schindler 2013-05-23 10:13:45 EDT
Created attachment 752242 [details]
upgrade.log
Comment 3 Petr Schindler 2013-05-23 10:14:39 EDT
Created attachment 752243 [details]
/EFI/grub.cfg
Comment 4 Petr Schindler 2013-05-23 10:15:21 EDT
Created attachment 752244 [details]
output from journalctl -a
Comment 5 Petr Schindler 2013-05-23 10:17:03 EDT
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 10:20:31 EDT
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 10:23:05 EDT
Created attachment 752249 [details]
picture of grub fail message
Comment 8 Adam Williamson 2013-05-23 10:59:39 EDT
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 11:42:23 EDT
+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 11:56:43 EDT
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 12:16:38 EDT
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 12:30:04 EDT
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 13:28:53 EDT
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 10:45:08 EDT
(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:
https://github.com/wgwoods/fedup-dracut/commit/9c8fc29

> 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...
[snip]

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 13:20:21 EDT
The new grub2 package is now in updates-testing:

https://admin.fedoraproject.org/updates/FEDORA-2013-9069/grub2-2.00-18.fc19

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 05:37:22 EDT
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-28 20:12:12 EDT
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.