Bug 883075

This is a well known issue, workarounds available in documentation:

https://fedoraproject.org/wiki/FedUp

*** This bug has been marked as a duplicate of bug 873144 ***

Crap, I marked this as a dupe when I probably shouldn't have it isn't a dupe of 873144 even if it is a dupe - trying to do too many things at the same time

We need a central issue to use for the fedup progress display during the actual upgrade and this is high level enough to work as that.

Proposing as a blocker for F18 Final due to a conditional violation of the following 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.

This isn't a clear cut criteria violation but my justification for blocking release is that there needs to be some form of progress display during upgrade. Without that display, a user could be pretty easily convinced that something hung during the upgrade and reboot the system. There is a good chance that rebooting during the upgrade process would break the system and I think that's justification for blocking release.

There are two parts to the lack of progress display and at least one of them would need to be fixed:

Fix the upgrade.img generation such that the fedup theme is used without needing to add 'plymouth.theme=fedup' to the kernel boot params. This is currently being tracked as:
https://bugzilla.redhat.com/show_bug.cgi?id=879295

The other issue is that the text log output is not being displayed behind the plymouth splash screen. The cause of this is not quite understood but could be related to the following issue with using systemd:
https://bugzilla.redhat.com/show_bug.cgi?id=869061

Discussed at 2012-12-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Accepted as a blocker per criterion/justification cited in comment #3.

Since a fix for plymouth is available in https://bugzilla.redhat.com/show_bug.cgi?id=879295 , should we set this to ON_QA?

So 879295 is fixed, plymouth went stable. Do we need to generate a new upgrade.img before we can close this? Will? Tim? Dennis?

I think I also have bug 873144 fixed, so that's cool.

Once the new fedup-dracut build is available you'll need to use it to build new upgrade images - see https://bugzilla.redhat.com/show_bug.cgi?id=879295#c31 for instructions if you want to build and test them yourself.

Not really, I just want to know when we can close the bug :)

I just tested with fedup 2-1 and the "what is going on?" question still isn't answered by the splash flashing 8 and slowly moving progress bar.  An occaisional user prompt as to progress in plain text would be a NTH, although probably not a blocker.

Hit Escape for details. The text you want should be there, assuming the upgrade.img is new enough to have bug 873144 fixed.

Writing "plain text" on the graphical screen involves including another ~15MB of libraries, fonts, font configuration files, etc, so that's probably not going to happen.

So we also need to change the QA Test Case for fedup then as it reads as follows:

The system should boot into the upgrade process and a fedup progress screen should be displayed

    Do not press any key, otherwise the progress screen will be killed and you will have no information about the process

Yes, once you've confirmed that current builds contain fedup-dracut-0.7.2-1.fc18, and that bug 873144 is indeed fixed, that comment should be removed.

I added a note to the wiki page that mentions this.

Could someone please check to see if this bug is fixed when upgrading to current F18 TC builds?

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. Bug 873144 is not fixed.  Used F18-FC4 as source also.

The version of fedup you use on the F17 system isn't relevant. You need an upgrade.img built with fedup-dracut-0.7.2-1.fc18.

In the absence of logs or other info that tell you what packages were used when building the tree, you can check upgrade.img:

  xzgrep 'plymouth pause-progress' upgrade.img && echo fixed || echo not fixed

Which shows that F18-TC4 doesn't contain the fix. So the previous test is moot, and we still need to know if fedup-dracut-0.7.2-1.fc18 fixes the problem.

I am entering an area beyond my present expertise.  The QA:TestCase fedup CLI clearly states:

Find the URL of the branched TC or RC under test. This URL should be of the form http://dl.fedoraproject.org/pub/alt/stage/18-Beta-<name>/Fedora/<arch>/os.

    <name> is the name of the phase under test (Beta, Final etc.)
    <arch> is the name of the arch running on the install to be upgraded (i386, x86_64 ...) 

Start the upgrade prep by executing following command

    sudo fedup-cli --network 18 --debuglog fedupdebug.log --instrepo <URL>
    <URL> is the location found in the previous step 


Due to my slow internet speed I mount the TC/RC iso as a loop mount and serve it from my lan HTTP Server and use it as the instrepo.  I noticed that fedup-0.7.2-1.fc17 used the local repo for 1200+ rpm and then grabbed between 40 and 50 remaining from fedora 18 mirrors.  fedup-0.7.1-1.fc17 grabbed everything over the web from Fedora mirrors which was a long pain.  

I say all the above to ask if you could kindly explain where this ?updates.img? plays into things, I'd be glad to try and test if I had Test Case instructions explaining what you need tested.

(In reply to comment #15)
> I am entering an area beyond my present expertise.  The QA:TestCase fedup
> CLI clearly states:
> 
> Find the URL of the branched TC or RC under test. This URL should be of the
> form
> http://dl.fedoraproject.org/pub/alt/stage/18-Beta-<name>/Fedora/<arch>/os.
> 
>     <name> is the name of the phase under test (Beta, Final etc.)
>     <arch> is the name of the arch running on the install to be upgraded
> (i386, x86_64 ...) 

Hrm, Beta shouldn't be in the URL template. The current URL for testing TC4 would be:
http://dl.fedoraproject.org/pub/alt/stage/18-TC4/Fedora/<arch>/os/

I'll get the test case updated to be more clear but TC4 still doesn't have the newest fedup-dracut.

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)

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.

(In reply to comment #16)
> 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/

It turns out that there is an issue with the upgrade.img I built such that it doesn't work with encrypted disks - it's build problem that I don't quite understand yet but I was able to build a x86_64 upgrade.img that does work with encrypted disks:

http://dl.fedoraproject.org/pub/alt/qa/20130103_f18-smoke13/fedup/

Bottom Line the update crashing when you press escape is fixed, but the problem of not being able to toggle between Graphical and Text and have both work now exists.  I personally would call that NTH and not a blocker as long as it is documented, but the Zappers will have to concur.

marking as ON_QA for https://admin.fedoraproject.org/updates/FEDORA-2012-20810/fedup-dracut-0.7.2-1.fc18 . That update could do with some karma so we can push it stable.

I just performed an upgrade (on a system with an encrypted disk) using dl.fp.org/../development as instrepo, splash works and console details are printed. The only problem is that after returning to splash the progress bar is no longer updates (stays on 0%).

According to tflink this can now be considered fixed, everything is done in RC2/RC3 wrt these bugs, there's nothing more to look after.