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
This is so poor user experience it might warrant blocker status.
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.
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
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.
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).
This is very noticable in F18 beta, denoting CommonBugs
As a workaround, adding "plymouth.splash=fedup" to the boot args should make the graphical progress screen appear.
(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?
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.
Our official upgrade documentation [1] 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. [1] https://fedoraproject.org/wiki/FedUp
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
agree with tflink, -1 blocker, +1 nth.
-1 blocker, +1 nth
-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
(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.
(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.
(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 ...
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.
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.
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!
(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.
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
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.
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)
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).
(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?
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.
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.
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.
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.
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[1] 3) `mkdir -p ~/fedup-repo; makefeduprepo ~/fedup-repo` then copy ~/fedup-repo somewhere useful. [1]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
I can confirm the new splash with progress bar is shown if I build and use a new upgrade.img according to comment 31.
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.
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
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.