This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 873144 - pressing Esc kills plymouth screen
pressing Esc kills plymouth screen
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Reopened
Depends On:
Blocks: F18Blocker/F18FinalBlocker
  Show dependency treegraph
 
Reported: 2012-11-05 04:06 EST by Jens Petersen
Modified: 2013-01-29 15:32 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-09 14:25:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jens Petersen 2012-11-05 04:06:49 EST
Description of problem:
Pressing Esc while upgrade is in progress seems to quit the upgrade process?
or at least makes the progress screen disappear.

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

Steps to Reproduce:
1. do a fedup upgrade
2. press Esc during upgrade
  
Actual results:
UI disappears

Expected results:
Esc key to be ignored or toggle to verbose mode.
Comment 1 Tim Flink 2012-11-05 10:27:13 EST
It doesn't actually stop upgrade, it just kills the plymouth screen.

Unfortunately, there is no way to see the upgrade progress right now unless you enable the upgrade debug shell using a kernel boot arg:
rd.upgradeshell.debugshell

There are a few more details on how to actually use the debug shell in the testing info wiki page I wrote:
https://fedoraproject.org/wiki/QA%3AFedora_18_Upgrade_Testing#Enabling_the_Upgrade_Shell
Comment 2 Tim Flink 2012-11-07 11:45:45 EST
There is supposed to be output behind the plymouth splash but I'm not clear on what exactly is going wrong.

See #869061 for details. I'm waiting for more information before filing a new bug, if needed.
Comment 3 Will Woods 2012-11-21 17:53:54 EST
This is a plymouth bug. The display crashes if you switch to the detailed view while in system-update mode. (Note that it doesn't happen if plymouthd is still in normal "boot" mode). Reassigning.
Comment 4 Tim Flink 2012-11-27 10:33:57 EST
This results in unexpected operation during upgrades, denoting as CommonBugs.

Proposing as a blocker for Fedora 18 final because it appears as if the upgrade has stopped when in reality, it is still going. A common reaction might be to reboot the system which could cause serious problems when rebooted.
Comment 5 satellitgo 2012-11-27 10:43:24 EST
This is a useful bug when testing however ( not upgrading)
Comment 6 Tim Flink 2012-11-30 14:50:31 EST
+1 final blocker. This doesn't prevent upgrades but it makes them much more user-unfriendly than they should be.

My concern is if someone thinks that the upgrade didn't actually start and reboots the machine during upgrade; borking the system either permanently or requiring a non-trivial recovery process.
Comment 7 Tim Flink 2012-11-30 14:57:43 EST
I suppose I should list a violated criterion. This isn't so straightforward because it doesn't directly affect upgrades or violate the F18 final release criterion [1]:

For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using all officially recommended upgrade mechanisms. The upgraded system must meet all release criteria.

However, I think this is a conditional violation of the following F18 final release criterion [1]:

All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs

This doesn't directly cause data corruption but I assert that fixing the issue would help mitigate potential data loss in a situation like what I described above.

[1] http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
Comment 8 Ray Strode [halfline] 2012-11-30 18:05:28 EST
pretty sure this was fixed a while ago. Are people still seeing this?
Comment 9 Tim Flink 2012-12-03 13:31:26 EST
*** Bug 883075 has been marked as a duplicate of this bug. ***
Comment 10 Adam Williamson 2012-12-03 14:00:17 EST
Discussed at 2012-12-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-12-03/f18final-blocker-review-1.2.2012-12-03-17.25.log.txt . Agreed that in principle we want there to be a clear bug for 'there must be a progress indicator for a fedup upgrade whether plymouth is currently showing or not', but we don't have a single clear bug for that at present. tflink will try to re-arrange so everything is clear and re-propose an appropriate bug for the next meeting: we hold the decision until then.
Comment 11 Jens Petersen 2012-12-04 01:13:16 EST
(In reply to comment #8)
> pretty sure this was fixed a while ago. Are people still seeing this?

details?
Comment 13 Jens Petersen 2012-12-04 21:27:43 EST
(In reply to comment #8)
> Are people still seeing this?

I think so - this was reported some days after the latest plymouth build (plymouth-0.8.8-3.fc18) and I saw it again recently after F18 Beta when I did a test upgrade (F17 -> F18).
Comment 14 Adam Williamson 2012-12-17 14:05:56 EST
We took https://bugzilla.redhat.com/show_bug.cgi?id=883075 as a blocker (it's a general bug for 'upgrading is too quiet'), so removing blocker nomination from this bug.
Comment 15 Will Woods 2012-12-20 12:20:33 EST
I'm going to say that this bug represents the missing text output (and/or plymouth crash) when you hit [Esc] during upgrade, and bug 879295 was the missing graphical progress.

This should be fixed in fedup-dracut git:
  https://github.com/wgwoods/fedup-dracut/commit/99a16c2

A new build should be available for testing shortly.
Comment 16 Fedora Update System 2012-12-20 23:52:35 EST
fedup-dracut-0.7.2-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/fedup-dracut-0.7.2-1.fc18
Comment 17 Fedora Update System 2012-12-21 15:01:29 EST
Package fedup-dracut-0.7.2-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedup-dracut-0.7.2-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20810/fedup-dracut-0.7.2-1.fc18
then log in and leave karma (feedback).
Comment 18 drago01 2013-01-01 07:40:36 EST
So are we going to use this build to build the final F18 updates image?
Comment 19 Robert Lightfoot 2013-01-03 14:05:45 EST
Tested 1-3-2013 with fedup-0.7.2-1.fc17.noarch from koji and pressing escape still results in a blank screen with only two warning messages about keymap and something else being deprecated.
Comment 20 Robert Lightfoot 2013-01-03 14:28:59 EST
It should be noted fedup does complete but the operator is "in the blind"  Attempts to send <ctrl><alt><f1> thru <ctrl><alt><f6> produced no change in terminal.
Comment 21 Adam Williamson 2013-01-03 14:36:56 EST
-1 blocker, +1 nth. we do display a progress bar. I don't think we need to block on not continuing to indicate progress if you manually kill it.
Comment 22 Will Woods 2013-01-03 14:48:57 EST
F18 TC4 doesn't contain fedup-dracut-0.7.2-1.fc18. You need to test with an image that actually contains the fix.
Comment 23 Tim Flink 2013-01-03 18:03:08 EST
This is the same info I put in #883075 but is probably worth repeating here:

I've built new upgrade.img files (i386 and x86_64) using the fix in question and put them in a repo on fedorapeople:
http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/

If anyone wants to test this, make sure that you add the arch you're testing to the --instrepo arg so that it would look like:
--instrepo=http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/x86_64

or

--instrepo=http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/i386

From my testing, it is now possible to see text output by pressing esc from the fedup plymouth splash. However, if you switch back to the graphical splash, the progress bar is at 0% and is never updated (I've tried waiting for the reboot after upgrade completion, ~ 20 minutes)
Comment 24 Robert Lightfoot 2013-01-03 18:27:40 EST
Tested with Tim Flinks image on an i386 F17 system.  Upgrade command was fedup-cli --network 18 --debuglog fedupdebug.log --instrepo http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/i386/ --disablerepo=fedora --repourl fedora-local=http://my.lan.http.server/testing/i386  

Note: http://my.lan.http.server/testing/i386 is F18-TC4 loop mounted.

Pressing escape does switch to a line by line printout of packages as installed. It also shows the percentage progress of the total install.  The progress bar does cease to be updated after pressing escape and returning to graphical.
Comment 25 Robert Lightfoot 2013-01-03 20:26:42 EST
Tested with Tim Flinks image on an x86_64 F17 system.  Upgrade command was fedup-cli --network 18 --debuglog fedupdebug.log --instrepo http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/x86_64/ --disablerepo=fedora --repourl fedora-local=http://my.lan.http.server/testing/x86_64/  

Note: http://my.lan.http.server/testing/x86_64 is F18-TC4 loop mounted.

Pressing escape does switch to a line by line printout of packages as installed. It also shows the percentage progress of the total install.  
The progress bar does cease to be updated after pressing escape and returning to graphical.
Comment 26 Fedora Update System 2013-01-05 02:15:33 EST
fedup-dracut-0.7.2-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 27 Robert Lightfoot 2013-01-05 05:08:17 EST
fedup-dracut-0.7.2-1.fc18 graphical progress is broken after toggling to text progress STILL.
Comment 28 Jens Petersen 2013-01-06 21:43:35 EST
I also tried again with RC1:

$ sudo fedup --network 18

and when upgrading when pressing Esc no progress is shown still.

Reopening.
Comment 29 Jens Petersen 2013-01-06 21:45:07 EST
Ah sorry I guess I need to use http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/x86_64/ ?
Comment 30 Jens Petersen 2013-01-06 21:55:54 EST
Anyway I feel it would be better to leave this open until no user tweaks are needed any more.
Comment 31 Adam Williamson 2013-01-06 22:35:31 EST
boblfoot: we know that, but that's not what this bug covers, and it's likely not a blocker issue.
Comment 32 Jens Petersen 2013-01-07 00:17:15 EST
I am still a bit confused:

$ sudo fedup --network 18 --instrepo=http://dl.fedoraproject.org/pub/alt/stage/18-RC1/Fedora/x86_64/os/
setting up repos...
Error: can't get boot images.
The 'cmdline-instrepo' repo was rejected by yum as invalid.
Comment 33 Jens Petersen 2013-01-07 00:21:41 EST
Ok, "sudo fedup --network 18 --instrepo=http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/x86_64" as Tim said in comment 23.

So will this work for RC2 or is there another bug needed for that?
Comment 34 Adam Williamson 2013-01-07 00:59:38 EST
We don't need any more bugs.
Comment 35 Kamil Páral 2013-01-07 03:44:34 EST
The update is stable, issue is verified, closing.
Comment 36 Tim Flink 2013-01-07 09:54:14 EST
(In reply to comment #33)
> Ok, "sudo fedup --network 18
> --instrepo=http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/x86_64"
> as Tim said in comment 23.
> 
> So will this work for RC2 or is there another bug needed for that?

Depends on what you mean by working for RC2 - there were some errors in documentation that I'm planning to fix today.

http://dl.fedoraproject.org/pub/alt/stage/18-RC1/Fedora/x86_64/os/ is not expected to work as --instrepo due to the way that it is built (missing repodata). The only releng repo that can be used for instrepo is:

http://dl.fedoraproject.org/pub/fedora/linux/development/18/x86_64/os/

This has the side effect of only being able to use whatever is in stable which is why I have been building side repos with fedup-dracut that's newer than current stable.
Comment 37 Adam Williamson 2013-01-07 13:51:33 EST
kparal: I left it open and set to VERIFIED intentionally. It's not completely closed until we're sure it's fixed in the to-be-released package set. The fix has to be present in the generated upgrade.img , so just ensuring the package was pushed stable is not enough to close it.
Comment 38 Jens Petersen 2013-01-07 22:20:28 EST
(In reply to comment #36)
> Depends on what you mean by working for RC2 - there were some errors in
> documentation that I'm planning to fix today.

Well, as you said RC1 is not expected to work...
Should we not be expecting the RC2 tree to fix this either?

> The only releng repo that can be used for instrepo is:
> http://dl.fedoraproject.org/pub/fedora/linux/development/18/x86_64/os/

So would "sudo fedup --network 18" not be using that?
But it does not have new enough upgrade repo for Esc to text progress?
Comment 39 Adam Williamson 2013-01-09 14:25:12 EST
According to tflink this and 883075 can now be considered fixed, everything is done in RC2/RC3 wrt these bugs, there's nothing more to look after.
Comment 40 Jens Petersen 2013-01-09 23:15:54 EST
I am still confused so I should not expect text progress to work with
just "fedup --network 18" yet?  Or will it not work until 18 final
is moved to releases/??

I just trying again right now and it is not happening for me.
Comment 41 Jens Petersen 2013-01-10 04:42:43 EST
Ok, sorry for being a bit slow here (though I still think the upgrade repo
choice is unintuitive from the post-Beta PoV).  I think I finally get
the behaviour now: ie "fedup --network 18" currently uses the 18-Beta
upgrade image rather than development/18 that I was hoping for
(until release when it will pick up releases/18 presumably).

Well I suppose it might make sense coming from preupgrade perhaps.
But given that development/18 works and is newer than test/18-Beta
I may file a fedup RFE later to prefer newer development repo in future.
Comment 42 Tim Flink 2013-01-10 10:09:19 EST
Whoops, I wrote this a couple of days ago, forgot to save changes and lost it in a tab. Sorry for the delay but I think it'll confirm the answers you've already found.

(In reply to comment #38)
> (In reply to comment #36)
> > Depends on what you mean by working for RC2 - there were some errors in
> > documentation that I'm planning to fix today.
> 
> Well, as you said RC1 is not expected to work...
> Should we not be expecting the RC2 tree to fix this either?

No, none of the RC repos will be capable of supporting initramfs/vmlinuz fetching. The fix for this bug has been stable for a while now but due to a quirk in the releng process, it is not possible and will not be possible to use the RC trees with the --instrepo arg. the --instrepo URL needs to have yum metadata in order for fedup to be able to use it - yum metadata is explicitly excluded from the public RC trees by releng and thus, it is not possible to use the RC trees with --instrepo.
 
> > The only releng repo that can be used for instrepo is:
> > http://dl.fedoraproject.org/pub/fedora/linux/development/18/x86_64/os/
> 
> So would "sudo fedup --network 18" not be using that?
> But it does not have new enough upgrade repo for Esc to text progress?

No, it still points to the beta tree. Another quirk that stems from fedup's use of mirrormanager to autodetect the --instrepo. Mirrormanager's install repo for F18 still points to the beta tree and will continue to point to that tree until F18 is released.
Comment 43 Will Woods 2013-01-10 21:10:52 EST
Right. fedup uses whatever links are returned by:

  https://mirrors.fedoraproject.org/metalink?repo=fedora-install-$releasever&arch=$basearch

which is controlled (obviously) by mirrormanager.

so if you want to change what mirrors fedup gets, you need to discuss that with the mirrormanager admins.
Comment 44 Jens Petersen 2013-01-11 06:02:18 EST
OK thanks - yeah sounds like it would be good to switch MM over to
development/18 then some time after Beta or at least before final.
Comment 45 Richard Wall 2013-01-27 06:26:01 EST
I don't think this bug is fixed. I encountered it today.

Shortly after rebooting into the F18 upgrade image I got frustrated by lack of feedback and hit escape.

The screen filled with a constant stream of asterisks.

There's another similar report here:
 * http://www.reddit.com/r/Fedora/comments/16m2x0/fedora_18_is_live/c7xcp9r

"""
Tue Jan 15 16:41:38 2013 UTC
 I tried pressing escape to see some real feedback on the upgrade process, but I got a screen full of asterisks. I have custom RPMs installed and sometimes I need to see what's going on.
"""

I assumed the upgrade had crashed and hit CTRL-ALT-DEL

Rebooted into F18 upgrade image again and let the upgrade complete.

Here's some more info about the upgrade.

* Lenovo Thinkpad x121e
* Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz
* 8GB RAM
* Fedora 17


$ sudo tail /var/log/yum.log
...
Jan 27 00:53:28 Installed: fedup-0.7.2-1.fc17.noarch


I was following these instructions:
 * https://fedoraproject.org/wiki/FedUp

{{{
$ sudo yum upgrade

$ sudo yum --enablerepo=updates-testing install fedup

$ sudo fedup-cli --network 18 --debuglog fedupdebug.log

# there was one error in the fedupdebug.log reporting a 404 while connecting to livna mirror
}}}

Rebooted into the fedora 18 upgrade image.
Comment 46 Adam Williamson 2013-01-28 16:45:59 EST
we tested it multiple times. it definitely works. what you're seeing may be some kind of other issue; the asterisks may also simply be the output of some operation that takes place during the upgrade, in which case it's not even a bug.
Comment 47 drago01 2013-01-28 16:51:19 EST
(In reply to comment #46)
> we tested it multiple times. it definitely works. what you're seeing may be
> some kind of other issue; the asterisks may also simply be the output of
> some operation that takes place during the upgrade, in which case it's not
> even a bug.

The "screen full of asterisks" is probably the selinux relabeling taking place.
This is not a bug.
Comment 48 Richard Wall 2013-01-28 17:11:14 EST
You're the experts, but it was pretty disconcerting.

There are more reports of asterisks and stars here:
 * "fedup: it's full of stars" http://www.spinics.net/linux/fedora/fedora-users/msg427867.html

...and here...
 * "Upgrade doesn't start for systems with more than one encrypted partitions" https://bugzilla.redhat.com/show_bug.cgi?id=896010

I don't have an encrypted partitions, so that wasn't causing my stars.

-RichardW.
Comment 49 Jens Petersen 2013-01-29 01:36:16 EST
I have seen the asterisks too: I assumed it was some plymouth race-condition -
rebooting avoided it for me.

If it is relabeling there should at least be a message to that effect.

(I still think it would be safer not to use plymouth for upgrades by default.)
Comment 50 Will Woods 2013-01-29 15:32:09 EST
Rebooting probably "avoided" it because the relabel had finished, so there was nothing to relabel on the next boot.

SELinux relabel progress reporting is done by 'fixfiles' in the 'policycoreutils' package; that's where bug reports (or, better, patches) about that should go.

On the other hand, if you've got stars *and* problems getting the upgrade to start *and* you have multiple encrypted partitions, that's bug 896010.

In either case, these discussions are outside the scope of *this* bug, which is:

 - you hit Escape, and
 - the screen goes black, and
 - no text appears on-screen, and
 - pressing Escape again gives a plymouth error message

If that's what happens to you, feel free to reopen this bug. Otherwise try one of the other bugs, or open a new one.

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