Red Hat Bugzilla – Bug 966586
System doesn't boot after upgrade on UEFI
Last modified: 2013-05-28 20:12:12 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:
Created attachment 752241 [details] fedup.log
Created attachment 752242 [details] upgrade.log
Created attachment 752243 [details] /EFI/grub.cfg
Created attachment 752244 [details] output from journalctl -a
File from comment 2 is upgrade.log sorry for confusion. I also forgot to mention, that this happens on UEFI machine.
Proposed as a Blocker for 19-beta by Fedora user pschindl using the blocker tracking app because: This bug violates the 'upgrade requirements' criterion
Created attachment 752249 [details] picture of grub fail message
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.
+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...
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).
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 )
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.
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.
(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.
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.
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.
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.