Bug 668570

Summary: Attempting to submit (scp or bugzilla) an exception report fails if networking not active
Product: Red Hat Enterprise Linux 6 Reporter: Gavin Romig-Koch <gavin>
Component: anacondaAssignee: Martin Gracik <mgracik>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: aj.werkman, dmach, gavin, jlaska, jonathan, nikhilmdas, pholica, rhe, rvykydal, rwilliam, sandro, tcallawa, vanmeeuwen+fedora
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: https://fedoraproject.org/wiki/Common_F14_bugs#no-networking-for-exception AcceptedBlocker
Fixed In Version: anaconda-13.21.128-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 635821 Environment:
Last Closed: 2011-12-06 05:29:42 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 635821    
Bug Blocks: 641108    

Description Gavin Romig-Koch 2011-01-10 14:58:52 EST
+++ This bug was initially created as a clone of Bug #635821 +++

Created attachment 448535 [details]
Screenshot

Description of problem:

If you encounter a failure in the installer before networking is active, you are no longer able to submit the failure over the network (scp or bugzilla).  

Version-Release number of selected component (if applicable):
 * anaconda-14.17.3 (F-14-Beta RC2)

How reproducible:
 * easy to reproduce

Steps to Reproduce:
 * Using http://jlaska.fedorapeople.org/updates/traceback.img to intentionally trigger an exception, follow the instructions at https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media

NOTE: the updates.img must be created as an ext2 disk image, not a compress cpio ball in order to be loaded as a floppy disk
  
Actual results:

See screenshot.

Expected results:

Prompt to enable networking

Additional info:

--- Additional comment from jlaska@redhat.com on 2010-09-20 15:48:50 EDT ---

Created attachment 448536 [details]
anacdump.txt

After manually enabling networking, I'm attaching the exception report for the failure I injected.  Note, the exception is intentionally triggered, but I'm attaching this in case the additional logs help identify why NM didn't activate networking.

--- Additional comment from jlaska@redhat.com on 2010-09-21 08:52:31 EDT ---

*** Bug 635985 has been marked as a duplicate of this bug. ***

--- Additional comment from rvykydal@redhat.com on 2010-09-22 08:33:08 EDT ---

I think the NM didn't activate networking because we don't ask it to when handling the exception. Chris, you know better where the network should be (or even if it can be) enabled in this case.

--- Additional comment from clumens@redhat.com on 2010-09-23 13:24:03 EDT ---

Networking used to be enabled in python-meh from within saveToRemove and saveToBugzilla, since those were the only cases where it was strictly necessary.  However, report has taken over all those duties now so I suppose it's responsible for knowing when to bring up the network too.

--- Additional comment from awilliam@redhat.com on 2010-10-01 15:39:22 EDT ---

This was discussed at the 2010-10-01 blocker review meeting. We accept it as a blocker under the (Alpha) criterion "The installer must be able to report failures to Bugzilla, with appropriate information included". Gavin, if you could please look at it ASAP that'd be great. Thanks!

--- Additional comment from gavin@redhat.com on 2010-10-04 17:07:17 EDT ---

I'm working on it.  I'll have a progress report later tonight.

--- Additional comment from gavin@redhat.com on 2010-10-05 02:42:37 EDT ---

Created attachment 451592 [details]
enable network if necessary and requested just before calling save exception

--- Additional comment from gavin@redhat.com on 2010-10-05 02:59:32 EDT ---

I am proposing that this bz be fixed by the patch attached in comment 7 https://bugzilla.redhat.com/show_bug.cgi?id=635821#c7

The code in anaconda for configuring and enabling network devices is intertwined with the anaconda's internal works, and with anaconda's user interface code.  It would not be easy to tease just the network code out of anaconda and into the more general report library, and it's not possible to do it this late in the release cycle.

Instead I'm proposing that anaconda is changed in the following way.  Just before the call that saves an exception, anaconda checks to see if any network devices are active, and if not, asks if the user would like to configure the network, and if yes, does so.  This has the advantage of being the simplest and safeist resolution to this bz.  It has the disadvanatage that, if the network is not configured, it may will if the user would like to configure the network before knowing whether or not the network will be needed to save the exception, or even if there is a network device or not.

It would be possible to change the report library to take 'hasActiveNetDev' and 'enableNetwork' as optional arguments, and only call these functions if the chosen report save target requires the network, but I didn't do the patch this way, assuming the extra risk wasn't worth the slightly improved functionality.  I can redo the patch this way if necessary.

--- Additional comment from rvykydal@redhat.com on 2010-10-05 05:44:30 EDT ---

(In reply to comment #8)
> I am proposing that this bz be fixed by the patch attached in comment 7
> https://bugzilla.redhat.com/show_bug.cgi?id=635821#c7
> 

If we go with this, I have two suggestions for the patch:
1) I'd mention the reason of network enablement (exception/error report) in the first dialog
2) In case of success of enableNetwork() we need to call urlgrabber.grabber.reset_curl_obj() (this is no longer needed in master)

--- Additional comment from clumens@redhat.com on 2010-10-05 10:45:18 EDT ---

I agree that this is the probably the least invasive and therefore best patch for where we are in F14.  I also agree with Radek's assessment of the patch - we definitely want a more descriptive error message.  It'd be nice to include a sentence saying how saving the traceback to a network destination won't work.

What happens if you go ahead and try to save via bugzilla or scp despite the lack of network?  Are they going to hit another traceback?

--- Additional comment from gavin@redhat.com on 2010-10-05 12:11:39 EDT ---

(In reply to comment #10) 
> What happens if you go ahead and try to save via bugzilla or scp despite the
> lack of network?  Are they going to hit another traceback?

No, not a traceback.  An error message; most commonly the message is about not being able to connect to the relevant URL or host.

--- Additional comment from gavin@redhat.com on 2010-10-06 09:38:04 EDT ---

I apologise for not knowing the protocol here.  Do I need to be the one to make these changes to the patch, or is someone from the Anaconda team handling that?

--- Additional comment from awilliam@redhat.com on 2010-10-06 11:28:40 EDT ---

You can't go wrong by doing it yourself :)

--- Additional comment from poelstra@redhat.com on 2010-10-06 17:22:09 EDT ---

Moving to ASSIGNED

--- Additional comment from awilliam@redhat.com on 2010-10-08 13:57:17 EDT ---

Discussed at the 2010-10-08 review meeting. Just a note that we'd like to have a fix by Monday 2010-10-11 for TC1, and we need a fix by Monday 2010-10-18 (ideally Friday 2010-10-15) for RC1. Thanks!

--- Additional comment from clumens@redhat.com on 2010-10-08 14:35:21 EDT ---

Try updates=http://clumens.fedorapeople.org/635821.img (put on a usb key or something, of course).

--- Additional comment from clumens@redhat.com on 2010-10-08 14:37:12 EDT ---

Created attachment 452409 [details]
try to bring up the network before saving exceptions

--- Additional comment from jlaska@redhat.com on 2010-10-08 16:44:18 EDT ---

Created attachment 452434 [details]
Screenshot demonstrating working patch (graphical)

(In reply to comment #16)
> Try updates=http://clumens.fedorapeople.org/635821.img (put on a usb key or
> something, of course).

See attached screenshot, I combined your updates.img with an existing image used to force a failure on the welcome screen (see https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla).

When the failure occurs, I clicked 'Save'.  I was prompted to enabled networking (see screenshot).  I tested ...
 1. Enabling networking using DHCP and the nm-c-editor dialogs, saved traceback to bugzilla
   * PASS - graphical works (see attached screenshot)
   * FAIL - text-mode fails when attempting to activate networking (see attached screenshot)
 2. Ignoring the prompt and click 'No' ... I played around a bit to make sure nothing else was lurking.  I attempted to file bugs using scp and bugizlla.  Both fail with an error dialog.  I was able to go back, and activate networking again.
   * PASS - graphical
   * PASS - text-mode

--- Additional comment from jlaska@redhat.com on 2010-10-08 16:44:46 EDT ---

Created attachment 452435 [details]
Screenshot demonstrating failure testing patch (text-mode)

--- Additional comment from clumens@redhat.com on 2010-10-11 10:00:30 EDT ---

Leave it to text mode to be the thing that screws up.  Can you hit the same updates= URL again?

--- Additional comment from jlaska@redhat.com on 2010-10-11 15:06:50 EDT ---

(In reply to comment #20)
> Leave it to text mode to be the thing that screws up.  Can you hit the same
> updates= URL again?

That fixes the FAIL test in comment#18.  Thanks.

--- Additional comment from updates@fedoraproject.org on 2010-10-11 17:46:44 EDT ---

anaconda-14.19-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.19-1.fc14

--- Additional comment from updates@fedoraproject.org on 2010-10-11 22:38:05 EDT ---

anaconda-14.19-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update anaconda'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/anaconda-14.19-1.fc14

--- Additional comment from rhe@redhat.com on 2010-10-14 06:27:33 EDT ---

I see this has been fixed in anaconda 14.19 since I filed a bug to bugzilla without network active in advance. Move it to VERIFIED.

--- Additional comment from sm@sandro-mathys.ch on 2010-10-14 16:30:09 EDT ---

Can verify this as well, filed a bug with no network active beforehand. Someone should still test this with the traceback.img and provide karma for the update with the result.

--- Additional comment from updates@fedoraproject.org on 2010-10-14 19:57:15 EDT ---

anaconda-14.20-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.20-1.fc14

--- Additional comment from updates@fedoraproject.org on 2010-10-15 00:09:00 EDT ---

anaconda-14.20-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update anaconda'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/anaconda-14.20-1.fc14

--- Additional comment from updates@fedoraproject.org on 2010-10-18 23:22:59 EDT ---

anaconda-14.21-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.21-1.fc14

--- Additional comment from updates@fedoraproject.org on 2010-10-19 18:23:51 EDT ---

anaconda-14.21-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 1 RHEL Product and Program Management 2011-06-06 15:59:42 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.
Comment 3 Pavel Holica 2011-11-15 07:12:53 EST
Reproduced on RHEL6.1 x86_64 Server.
Verified on RHEL6.2-20111109.1 x86_64 Server.
Comment 4 errata-xmlrpc 2011-12-06 05:29:42 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1565.html