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):
Steps to Reproduce:
1. do a fedup upgrade
2. press Esc during upgrade
Esc key to be ignored or toggle to verbose mode.
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:
There are a few more details on how to actually use the debug shell in the testing info wiki page I wrote:
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.
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.
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.
This is a useful bug when testing however ( not upgrading)
+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.
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 :
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 :
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.
pretty sure this was fixed a while ago. Are people still seeing this?
*** Bug 883075 has been marked as a duplicate of this bug. ***
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.
(In reply to comment #8)
> pretty sure this was fixed a while ago. Are people still seeing this?
(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).
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.
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:
A new build should be available for testing shortly.
fedup-dracut-0.7.2-1.fc18 has been submitted as an update for Fedora 18.
* 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:
then log in and leave karma (feedback).
So are we going to use this build to build the final F18 updates image?
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.
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.
-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.
F18 TC4 doesn't contain fedup-dracut-0.7.2-1.fc18. You need to test with an image that actually contains the fix.
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:
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:
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)
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.
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.
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.
fedup-dracut-0.7.2-1.fc18 graphical progress is broken after toggling to text progress STILL.
I also tried again with RC1:
$ sudo fedup --network 18
and when upgrading when pressing Esc no progress is shown still.
Ah sorry I guess I need to use http://tflink.fedorapeople.org/fedup/f18-upgrade-testing/x86_64/ ?
Anyway I feel it would be better to leave this open until no user tweaks are needed any more.
boblfoot: we know that, but that's not what this bug covers, and it's likely not a blocker issue.
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.
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?
We don't need any more bugs.
The update is stable, issue is verified, closing.
(In reply to comment #33)
> Ok, "sudo fedup --network 18
> 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:
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.
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.
(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:
So would "sudo fedup --network 18" not be using that?
But it does not have new enough upgrade repo for Esc to text progress?
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.
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.
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.
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.
Right. fedup uses whatever links are returned by:
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.
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.
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:
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:
$ 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.
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.
(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.
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
* "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.
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.)
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.