Red Hat Bugzilla – Full Text Bug Listing
|Summary:||upgrade has no progress indicator (missing/wrong plymouth theme)|
|Product:||[Fedora] Fedora||Reporter:||Kamil Páral <kparal>|
|Component:||plymouth||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||awilliam, drago01, fedora, peter_snygg, rbergero, robatino, rstrode, satellitgo, tflink, wwoods|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-12-20 00:31:09 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kamil Páral 2012-11-22 09:49:48 EST
Description of problem: The upgrade process uses default text plymouth loader screen, which seems fully loaded after a minute or so. Then there is no progress indicator on the screen. Since the upgrade takes 30-60 minutes, this is a very poor behavior. The user is literally in the dark. Please add some progress indicator. Version-Release number of selected component (if applicable): fedup-0.7.1-1.fc17 kernel retrieved from F18 Beta RC1 How reproducible: always
Comment 1 Kamil Páral 2012-11-22 09:50:31 EST
This is so poor user experience it might warrant blocker status.
Comment 2 Tim Flink 2012-11-22 12:31:54 EST
The problem here is in the construction of the initramfs in lorax. There is a plymouth theme for fedup and it does show a graphical representation of upgrade progress. However, there have been some complications in making dracut choose the correct plymouth theme for the upgrade initramfs. We figured that it was better to focus on making sure that upgrade worked instead of making it pretty. You can see upgrade progress if you enable the upgrade debugshell (append rd.upgrade.debugshell) and use 'journalctl -a -o cat'. I realize that this isn't the best user experience but I'm not convinced that it should be a blocker issue. Does it need to be documented with disclaimers, yes. We need to have better documentation on how fedup is expected to work but IMHO, this isn't bad enough to justify blocking beta for.
Comment 3 Tim Flink 2012-11-22 12:36:28 EST
As a side note, I'm using 'we' pretty loosely here. I'm not pretending that I'm doing any of the development work, it's just conceptually easier to phrase that way. Anyhow, the other issue is about no progress being shown behind the plymouth splash. That is a plymouth issue and is being tracked as https://bugzilla.redhat.com/show_bug.cgi?id=873144
Comment 4 Will Woods 2012-11-23 14:23:36 EST
Ah. I'm commandeering this bug for the issue whereby there's no "fedup" theme inside upgrade.img (to check, `lsinitrd upgrade.img | grep fedup`, look for usr/share/plymouth/themes/fedup). I have a patch for plymouth to fix this, which I sent to Ray Strode. I'll attach the patch here.
Comment 5 Will Woods 2012-11-23 14:34:37 EST
Created attachment 650624 [details] patch to make plymouth-populate-initrd change the default theme to be the installed theme Sorry, my mistake - the 'fedup' theme probably *is* in upgrade.img, if there is an upgrade.img to test with. That problem should have been fixed by one of the lorax patches that I sent upstream. If that's the case, the problem is probably that the config file still has the 'charge' theme as the default. You can verify this by unpacking the initramfs and examining /etc/plymouth/plymouthd.conf. This patch fixes *that* issue by changing the default theme, when the default theme is reset by the PLYMOUTH_THEME_NAME variable (which is how lorax builds upgrade.img).
Comment 6 Tim Flink 2012-11-27 10:22:42 EST
This is very noticable in F18 beta, denoting CommonBugs
Comment 7 Will Woods 2012-11-27 15:19:09 EST
As a workaround, adding "plymouth.splash=fedup" to the boot args should make the graphical progress screen appear.
Comment 8 Kamil Páral 2012-11-28 05:17:19 EST
(In reply to comment #7) > As a workaround, adding "plymouth.splash=fedup" to the boot args should make > the graphical progress screen appear. I can confirm this. I'll add the information to relevant wiki pages. Will, do I understand correctly that we can regenerate the relevant files for F18 Beta users so that it works out of the box?
Comment 9 Will Woods 2012-11-28 12:13:16 EST
You could rewrite the upgrade.img that's on the mirrors, but that wouldn't fix the upgrade.img that's inside the DVD images, so.. yes and no.
Comment 10 Kamil Páral 2012-11-29 04:19:28 EST
Our official upgrade documentation  speaks only about network upgrade and using dl.fp.o as the source, so I think fixing the mirror would help most of the people.  https://fedoraproject.org/wiki/FedUp
Comment 11 Tim Flink 2012-11-30 15:10:04 EST
I agree that this needs to be fixed, but I don't think it's a final blocker. It looks bad but doesn't really affect the upgrade or risk data corruption like I think #874144 does. -1 blocker, +1 NTH
Comment 12 Adam Williamson 2012-12-01 03:25:38 EST
agree with tflink, -1 blocker, +1 nth.
Comment 13 Kevin Fenzi 2012-12-04 18:50:32 EST
-1 blocker, +1 nth
Comment 14 Robyn Bergeron 2012-12-05 02:11:51 EST
-1 blocker, +1 NTH. If we really believe that the same reaction of "pull the plug" won't happen here and risk data issues, as tim pointed out as a likely possibility in 873144
Comment 15 Kamil Páral 2012-12-05 04:43:23 EST
(In reply to comment #14) > If we really believe that the same reaction of "pull > the plug" won't happen here and risk data issues, as tim pointed out as a > likely possibility in 873144 I believe that is very likely to happen. We should have a longer discussion about this, in bugzilla voting is not a good idea here, I think.
Comment 16 drago01 2012-12-12 16:19:29 EST
(In reply to comment #11) > I agree that this needs to be fixed, but I don't think it's a final blocker. > It looks bad but doesn't really affect the upgrade or risk data corruption > like I think #874144 does. > > -1 blocker, +1 NTH Sorry but I disagree ... this is not a cosmetic issue but actually very dangerous. It is pretty much the same as https://bugzilla.redhat.com/show_bug.cgi?id=872886 Having a long process without any progress feedback that is very likely result into a broken system once terminated is just not acceptable IMO. Yes it might not hit the wording of a specific criteria but this an obvious blocker to me.
Comment 17 drago01 2012-12-12 16:24:56 EST
(In reply to comment #14) > -1 blocker, +1 NTH. If we really believe that the same reaction of "pull > the plug" won't happen here [...] This believe is based on what exactly? I actually think the opposite is the case ...
Comment 18 Kamil Páral 2012-12-13 07:11:47 EST
drago, this hasn't been rejected as a blocker, it's still in proposed queue. I also believe there _has to be_ some notification what's going on, be it a plymouth splash or console printouts, I don't care. But people have to be notified the upgrade is taking place, or many of them just force reboot after a few minutes of endless waiting when "nothing's happening". I believe this should be a conditional blocker "let people know system is being upgraded". Plymouth doesn't have to the only way to do that.
Comment 19 Will Woods 2012-12-13 09:09:29 EST
There's two problems here: missing plymouth splash, and no text output on tty1. The plymouth splash is missing in Beta because the plymouthd.conf inside initramfs does't say 'Theme=fedup'. The patch to fix this has been accepted upstream: http://cgit.freedesktop.org/plymouth/commit/?id=a9703fb6 So we just need a new plymouth build that includes that. As for missing text.. having debugged and discussed the problem with halfline I'm pretty convinced the problem isn't inside plymouth. My working theory is that this is another manifestation of bug 869061 - just like with journald, the data that should be sent to the console just isn't getting there. It's possible that restarting plymouthd after the second switch-root would work around the problem, but I'd rather fix the root cause if possible. If it comes down to this being the lone remaining release blocker and we have no idea what's going on with systemd, we can always just run 'journalctl -afm' on /dev/tty3.
Comment 20 Adam Williamson 2012-12-13 13:50:41 EST
kparal: I think we were still waiting for you to 'clean up' the reports related to progress display for fedup before discussing them - viz http://meetbot.fedoraproject.org/fedora-qa/2012-12-03/f18final-blocker-review-1.2.2012-12-03-17.25.log.txt . Could you co-ordinate with tflink and ensure they don't fall off the radar for review? Thanks!
Comment 21 Tim Flink 2012-12-13 13:54:14 EST
(In reply to comment #20) > kparal: I think we were still waiting for you to 'clean up' the reports > related to progress display for fedup before discussing them - viz > http://meetbot.fedoraproject.org/fedora-qa/2012-12-03/f18final-blocker- > review-1.2.2012-12-03-17.25.log.txt . Could you co-ordinate with tflink and > ensure they don't fall off the radar for review? Thanks! Actually, I think we're waiting on me to do it. It keeps falling off my todo list for the day but I'll get it done today.
Comment 22 Fedora Update System 2012-12-13 14:02:46 EST
plymouth-0.8.8-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/plymouth-0.8.8-5.fc18
Comment 23 Will Woods 2012-12-13 14:23:40 EST
Err, I was a bit off in comment #19: in order for this to be fixed for the default case (i.e. no 'plymouth.splash=fedup' boot arg), we also need to rebuild upgrade.img. But: the automatic instrepo mirror URL should be coming online any minute now, so people using fedup-cli between now and Final won't need --instrepo. But that means they'll get the Beta upgrade.img, which doesn't have this plymouth fix. So, I'm going to temporarily patch fedup to set 'plymouth.splash=fedup'. That patch should be removed as soon as we start having test builds for F18 Final.
Comment 24 Tim Flink 2012-12-13 16:30:04 EST
I just proposed #883075 as a blocker to represent the entire issue of not enough progress information during the upgrade process. I suggest that we limit this bug to the plymouth theme issue and leave the log display behind plymouth splash to #869061 (assuming that it ends up being a systemd/journald issue)
Comment 25 Fedora Update System 2012-12-14 01:50:02 EST
Package plymouth-0.8.8-5.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 plymouth-0.8.8-5.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20368/plymouth-0.8.8-5.fc18 then log in and leave karma (feedback).
Comment 26 Kamil Páral 2012-12-14 05:24:50 EST
(In reply to comment #23) > That patch should be removed as soon as we start having test builds for F18 > Final. We do have them now: http://dl.fedoraproject.org/pub/alt/stage/ (TC1 and TC2) Will they be picked up automatically by fedup, or just RCs will?
Comment 27 Will Woods 2012-12-14 13:22:22 EST
fedup uses whatever mirrormanager returns for: http://mirrors.fedoraproject.org/metalink?repo=fedora-install-$releasever&arch=$basearch right now that's Beta, since (AFAIK) that's the newest installable release on the mirrors. If alt/stage/ is also on the mirrors and you want the mirrormanager to follow the TC builds instead (i.e. you want anyone who runs 'fedup --network 18' to get the TC build automatically rather then Beta) you should talk to the mirrormanager folks and/or infrastructure team.
Comment 28 Kamil Páral 2012-12-16 11:36:17 EST
Ah, I see. No, alt/stage is not mirrored by default. But you said: > That patch should be removed as soon as we start having test builds for F18 > Final. I'd like to clarify that that won't happen. Since you say that neither TCs nor RCs are picked up automatically by fedup, it means the new fedup-dracut stuff will be available (without --instrepo) only after Fedora 18 is officially released. It also means we won't be able to test fedup the same way our users will use it right after F18 is out. We will have to use --instrepo until the very last day before release.
Comment 29 Kamil Páral 2012-12-17 07:31:29 EST
Will, how can I test this? plymouth update is still not stable. I assume that once it is stable, I can do --instrepo http://dl.fedoraproject.org/pub/fedora/linux/development/18/x86_64/os/ , because os/images/pxeboot/upgrade.img is re-generated every day, is that right? But because the plymouth is not yet stable, could you please generate a fresh upgrade.img with the new plymouth included and post it somewhere (e.g. your fedorapeople page)? I'll then verify it works correctly.
Comment 30 Adam Williamson 2012-12-17 14:03:29 EST
We took https://bugzilla.redhat.com/show_bug.cgi?id=883075 as blocker as a general bug for this issue, so removing blocker nomination from this one.
Comment 31 Will Woods 2012-12-17 19:18:57 EST
You can use 'makefeduprepo' from fedup-dracut git to create a functional repo for use with --instrepo. See the script here: https://github.com/wgwoods/fedup-dracut/blob/master/makefeduprepo In short, find a F18 system, and: 1) install plymouth update 2) install fedup-dracut 3) `mkdir -p ~/fedup-repo; makefeduprepo ~/fedup-repo` then copy ~/fedup-repo somewhere useful. makefeduprepo will be in the next fedup-dracut build; until then: git clone git://github.com/wgwoods/fedup-dracut.git cd fedup-dracut; make && sudo make install mkdir ~/fedup-repo; ./makefeduprepo ~/fedup-repo
Comment 32 Kamil Páral 2012-12-18 08:09:19 EST
I can confirm the new splash with progress bar is shown if I build and use a new upgrade.img according to comment 31.
Comment 33 Fedora Update System 2012-12-20 00:31:13 EST
plymouth-0.8.8-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Comment 34 Fedora Update System 2012-12-20 23:49:45 EST
fedup-0.7.2-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/fedup-0.7.2-1.fc17
Comment 35 Fedora Update System 2013-01-03 02:27:02 EST
fedup-0.7.2-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.