Description of problem: Version-Release number of selected component (if applicable): How reproducible: use fedup to perform a system upgrade from fedora 20 to fedora 21 During the reboot to perform the actual upgrade, the system displays progress message for packages installed or upgraded. It appears that when the screensaver timeout occurs, the screen is blanked, but the whatever is writing these progress messages still tries to update the messages on the screen resulting in the messages appearing to be garbled. pressing the spacebar to get out of screen-saver mode corrects the display until the next timeout interval. It would seem the simplest fix here would be to disable the screen-saver timeout during the upgrade process.
The *correct* fix would be, obviously, to not garble the on-screen messages when the screen is blanked. So that should probably get filed as a separate bug against plymouth? But you're right - it's probably a good idea to disable consoleblank / powerdown during the upgrade anyway, since people have a tendency to think the upgrade has broken if the screen goes blank.
*** Bug 1175877 has been marked as a duplicate of this bug. ***
Worth noting that the screen "corruption" isn't unique to fedup, and happens outside plymouth - I've seen it when the consoleblank kicks in on long-running yum updates on virtual machines, for example. So that problem is very likely a kernel bug.
This should be fixed in git: https://github.com/rhinstaller/fedup-dracut/commit/d21dd8a The fix will appear after I do a new fedup-dracut build and that package gets used in a new Fedora.
Created attachment 1025933 [details] corrupted screen Will, should this be fixed or was it not applied after all? Because I just tried upgrading F20 -> F22 with --instrepo http://dl.fedoraproject.org/pub/alt/stage/22_TC4/Server/x86_64/os/ , and I still see corrupted screen exactly after 10 minutes. The screen gets less and less information and finally goes fully black (at least in this case, usually I saw a narrow column of characters and everything else black). See screenshot.
I believe this was marked fixed because the upgrade form fedora 21 to fedora 22 (once fedora 22 is released) should work without running into this issue. It was never said this would not occur for an update form fedora 20 to a pre-release version of fedora 22.
That patch should be in fedup-dracut-0.9.0-2, which is in F22. So I guess "setterm -blank 0" isn't sufficient? Ah well. What about the normal progress bar? That should be the default display - is it not showing up? If not, *that* should get fixed, rather than spending more time and effort working around this weird kernel bug.
Have you actually ever run fedup? The upgrade boot does not run rhgb.
Besides a progress bar that takes over an hour to progress is less than useful.
But I do see your point, a graphical screen with a installing package 100 out of 1500 with a progress bar would be more user friendly.
(In reply to Will Woods from comment #7) > What about the normal progress bar? That should be the default display - is > it not showing up? If not, *that* should get fixed, rather than spending > more time and effort working around this weird kernel bug. I was upgrading a minimal install, which has rd_NO_PLYMOUTH on the kernel cmdline, and it seems to be transferred to fedup cmdline as well. I assume that's why the graphical progress bar was not shown (I'll pay more attention during my future "standard" upgrades). But I have to agree with other comments that a simple progress bar is not that helpful for such long operations, and most people I know switch to console during fedup upgrades, just to have some reasonable overview of progress. OTOH I understand your reluctance to spend too much time with kernel issues.
(In reply to Bill Gianopoulos from comment #8) > Have you actually ever run fedup? The upgrade boot does not run rhgb. I'm going to pretend that this comment was in good faith, and you meant something more like "Are you sure it's supposed to be graphical? I've never seen it do that." To answer that question: yes - if your system uses plymouth normally, it should do so during the upgrade as well. There's even a special plymouth theme specifically for upgrades: https://github.com/rhinstaller/fedup-dracut/tree/master/plymouth So if your system normally uses a graphical boot splash and the upgrade isn't using the graphical progress bar, that's a bug (which should, of course, be filed separately from this one). (In reply to Bill Gianopoulos from comment #9) > Besides a progress bar that takes over an hour to progress is less than > useful. Well, most users I've talked to don't actually sit for an hour watching the progress bar; they go get lunch or something and come back to check on it later. fedup-dracut-0.9.0 made the progress bar 400 pixels wide (instead of 100 pixels) so you can see progress changes a little better. The ones who do want detailed progress hit Esc so they can see the progress messages. If the screen blanks, you can hit any key to bring it back. That's pretty sensible behavior, if you ask me. It'd be nice if we could disable the blanking, but so far I haven't found a way to do it. The kernel bug causing the partial-blanking thing is definitely weird, and *someone* should probably be trying to fix that. I don't know the VT/console subsystem well enough to fix it, but feel free to file a bug against kernel for that. I'm gonna move this back to ASSIGNED until we determine whether or not it's possible to disable console blanking/poweroff in plymouth / during the upgrade.
OK. I will try one more time to explain what I originally encountered and it seems still happens. I have Red Hat Graphical Boot enabled. When I run fedup, it DOES NOT DO A GRAPHICAL REBOOT. It displays cli type info a bout progress. Once the blank screen or lock screen enables it after unlocking or on leaving blank screen it displays complete garbage. If you let it run ignoring the garbage the update completes and all is fine. However, a normal user would be tempted to reboot and try again which results in a non recoverable situation.
I just did a fedup upgrade form fedora 21 to fedora 22, and, unlike the upgrade from fedora 20 to fedora 21 which ran in non-graphics mode, the upgrade to fedora 22 ran in graphics mode, and displayed a graphical progress bar which completely avoids the issue.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is now tracked at https://github.com/rpm-software-management/dnf-plugin-system-upgrade/issues/26 . It should only affect text mode.
*** Bug 1278213 has been marked as a duplicate of this bug. ***
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Let's track this upstream.