Created attachment 448535 [details]
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)
* 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
Prompt to enable networking
Created attachment 448536 [details]
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.
*** Bug 635985 has been marked as a duplicate of this bug. ***
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.
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.
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!
I'm working on it. I'll have a progress report later tonight.
Created attachment 451592 [details]
enable network if necessary and requested just before calling save exception
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.
(In reply to comment #8)
> I am proposing that this bz be fixed by the patch attached in comment 7
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)
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?
(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.
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?
You can't go wrong by doing it yourself :)
Moving to ASSIGNED
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!
Try updates=http://clumens.fedorapeople.org/635821.img (put on a usb key or something, of course).
Created attachment 452409 [details]
try to bring up the network before saving exceptions
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
Created attachment 452435 [details]
Screenshot demonstrating failure testing patch (text-mode)
Leave it to text mode to be the thing that screws up. Can you hit the same updates= URL again?
(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.
anaconda-14.19-1.fc14 has been submitted as an update for Fedora 14.
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
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.
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.
anaconda-14.20-1.fc14 has been submitted as an update for Fedora 14.
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
anaconda-14.21-1.fc14 has been submitted as an update for Fedora 14.
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.