Bug 883075 - fedup upgrading is too quiet
fedup upgrading is too quiet
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: fedup-dracut (Show other bugs)
18
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
AcceptedBlocker
: Reopened
Depends On:
Blocks: F18Blocker/F18FinalBlocker
  Show dependency treegraph
 
Reported: 2012-12-03 12:54 EST by m-redhat
Modified: 2013-01-09 14:25 EST (History)
9 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:53 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 m-redhat 2012-12-03 12:54:18 EST
Description of problem:

This is just a inconvenience for the user.

After executing fedup-cli and doing the reboot, system upgrading starts. What is annoying is that the upgrading process is so *quiet*, the user has NO idea what is going on. It did not display a single message (like e.g. "unpacking packages, installing packages, configuring blahblahblah"). Of course, a status bar for the overall progress would be awesome, but I would be happy already with just some text messages telling me what is going on.

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

fedup.noarch                         0.7.1-1.fc18                installed      

How reproducible:

Use fedup to upgrade a F17 system to F18beta.
  
Actual results:

Besides the blue/white 'bar' at the bottom of the screen I see NO information about the upgrading process.

Expected results:

Displaying some information about what is going on. Maybe even an ETA or something.
Comment 1 Tim Flink 2012-12-03 13:31:26 EST
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 ***
Comment 2 Tim Flink 2012-12-03 13:53:15 EST
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
Comment 3 Tim Flink 2012-12-13 16:26:19 EST
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
Comment 4 Adam Williamson 2012-12-17 11:58:39 EST
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.
Comment 5 Adam Williamson 2012-12-17 14:03:05 EST
Since a fix for plymouth is available in https://bugzilla.redhat.com/show_bug.cgi?id=879295 , should we set this to ON_QA?
Comment 6 Adam Williamson 2012-12-20 00:59:38 EST
So 879295 is fixed, plymouth went stable. Do we need to generate a new upgrade.img before we can close this? Will? Tim? Dennis?
Comment 7 Will Woods 2012-12-20 12:27:37 EST
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.
Comment 8 Adam Williamson 2012-12-20 20:48:21 EST
Not really, I just want to know when we can close the bug :)
Comment 9 Robert Lightfoot 2012-12-31 11:51:41 EST
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.
Comment 10 Will Woods 2013-01-02 12:41:12 EST
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.
Comment 11 Robert Lightfoot 2013-01-02 23:31:17 EST
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
Comment 12 Will Woods 2013-01-03 11:07:52 EST
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?
Comment 13 Robert Lightfoot 2013-01-03 14:06:51 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. Bug 873144 is not fixed.  Used F18-FC4 as source also.
Comment 14 Will Woods 2013-01-03 15:03:18 EST
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.
Comment 15 Robert Lightfoot 2013-01-03 17:01:13 EST
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.
Comment 16 Tim Flink 2013-01-03 18:01:10 EST
(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)
Comment 17 Robert Lightfoot 2013-01-03 18:30:03 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 18 Robert Lightfoot 2013-01-03 20:26:17 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 19 Tim Flink 2013-01-04 03:34:50 EST
(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/
Comment 20 Robert Lightfoot 2013-01-04 05:38:36 EST
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.
Comment 21 Adam Williamson 2013-01-04 19:57:17 EST
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.
Comment 22 Kamil Páral 2013-01-08 06:00:18 EST
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%).
Comment 23 Adam Williamson 2013-01-09 14:25:53 EST
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.

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