Version-Release number of selected component (if applicable):
Steps to Reproduce:
Make sure that your graphics driver supports KMS.
Make sure you have rhgb quiet options in kernel commandline and no nomodeset
1. Start shutdown process
I see only text mode with shutdown logs during >10 second shutdown.
You should see ring progress bar while the computer is shutting down; no texts
or shutdown logs.
I see text mode with shutdown logs now with short graphical Plymouth just before halt. Perhaps there is 5 seconds delay applied in shutdown process?
There shouldn't be any Plymouth delay during shutdown.
there is an intentional 5 second delay at shutdown. The idea is, if it takes less than 5 seconds to shut down (as it often will) then we shouldn't bother showing the boot splash.
Comment 0 made me think plymouth was adding an additional delay to the shutdown process on the order of 10 secs. If the current behavior is like comment 1 and not like comment 0 (i.e. plymouth doesn't slow down shutdown and shows up after 5 seconds) i think it's probably working "as designed" and we can close this bug out. Is that the case?
s/boot splash/shutdown splash/
There are still text logs during shutdown. I don't see them during boot until I hit Escape.
embarrassing maybe, but not a blocker
I have proof-of-concept run: echo -en "\e[1;1H\e[2J" > /dev/tty1
This clears boot logs from VT and that's what I see during shutdown before Plymouth kicks in or machine resets.
This VT control sequence should by handled by Plymouth or systemd when shutdown/restart process is started, just before GDM is killed.
you could argue this is a tier 3 blocker under the clause:
* any significant usability issue with major features in RHEL7
that make them look unfinished
We're pretty late to the party here but if we can figure out a minimal fix it might make sense to try to squeeze it in.
though, if the problem is in fact, just bug 1076010 then it seems to me the most minimal, least invasive fix is to just fix that bug.
(In reply to Ray Strode [halfline] from comment #10)
> though, if the problem is in fact, just bug 1076010 then it seems to me the
> most minimal, least invasive fix is to just fix that bug.
There are also other messages from boot. And I reproduce this on baremetal, while bug 1076010 is only on VM.
I'm going to close this bug. comment 0 isn't a problem, comment 1 is "by design" and the remaining issue probably needs to be fixed in GDM or systemd or something since the flicker happens before plymouth is started. Since this report has so much going on in it, I'd rather there was a new bug for the remaining issue.
Adding following line into /usr/lib/systemd/system/gdm.service fixes the issue:
ExecStop=/bin/sh -c 'echo -en "\e[1;1H\e[2J" > /dev/tty1'
Martin, do you mind filing this as a new bug and closing this one again?
It's a completely different issue, different component, etc...
okay vincent filed bug 1076222, reclosing this one.
(In reply to Ray Strode [halfline] from comment #15)
> okay vincent filed bug 1076222, reclosing this one.
^ vbenes, not vincent my hands typed something different than i was voicing there.