Description of problem: Anaconda 16.12 can not save traceback to bugzilla, which dues to the network problem, while the network is fine Version-Release number of selected component (if applicable): 16.12 How reproducible: Steps to Reproduce: 1. Install the Fedora-16-test-i386.iso or Fedora-16-test-x86_64.iso in KVM 2. Select the default options and follow the installation process 3. Anaconda run correctly until the step of partition, then it crashed before next step. 4. Select the 'save' option to submit the bug to bugzilla Actual results: It can't save to bugzilla Expected results: It save the bug information to bugzilla successfully Additional info:
This bug is concerning any network enablement in anaconda GUI. Workarounds: - Enable network in loader using asknetwork boot option. - When enabling network in anaconda GUI, check [X] Connect Automatically in NetworkManager Connection Editor.
(In reply to comment #1) > This bug is concerning any network enablement in anaconda GUI. > > Workarounds: > - Enable network in loader using asknetwork boot option. > - When enabling network in anaconda GUI, check [X] Connect Automatically in > NetworkManager Connection Editor. Actually ... the second point will also need another bug report. There's something funky about the nm-connection-editor dialog. None of the checkboxes work when you click them. Meaning, you click them (or press space bar when the element has focus), and nothing happens. Therefore, it's not possible to select [X] Connect Automatically
Requesting as a F16Alpha blocker as the presence of this bug impacts the following criteria in pxeboot and DVD.iso installation scenarios ... "The installer must be able to report failures to Bugzilla, with appropriate information included" When booting anaconda-16.12-1 as a netinst/boot.iso, anaconda also fails to activate networking when attempting to access the online repos. This impacts a number of Alpha release criteria, most notably ... "The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media " [1] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
(In reply to comment #2) > > Actually ... the second point will also need another bug report. There's > something funky about the nm-connection-editor dialog. None of the checkboxes > work when you click them. Meaning, you click them (or press space bar when the > element has focus), and nothing happens. Therefore, it's not possible to > select [X] Connect Automatically I'd guess it is some theme issue, for me checked and unchecked boxes are (though hardly) distinguishable by square of slightly different shade, but it can be just in my VM.
(In reply to comment #4) > I'd guess it is some theme issue, for me checked and unchecked boxes are > (though hardly) distinguishable by square of slightly different shade, but it > can be just in my VM. It could be ... in F14 and F15, you could just click 'close/cancel' at the nm-connection-editor dialog, and it would attempt to activate the previously selected device using DHCP. It attempts to do that in anaconda-16.12-1 also, but just fails. It seems like some NM configuration issue or a timeout of some sort? From /tmp/syslog ... 12:32:31,0 NOTICE dbus: [system] Activating service name='org.freedesktop.ModemManager' (using servicehelper) 12:32:31,0 NOTICE dbus: [system] Activated service 'org.freedesktop.ModemManager' failed: Cannot launch daemon, file not found or permissions invalid
Created attachment 514009 [details] /tmp/anaconda.log
Created attachment 514010 [details] /tmp/syslog
(In reply to comment #1) > Workarounds: > - Enable network in loader using asknetwork boot option. This definitely works as a temporary workaround, thanks for the suggestion Radek!
Created attachment 514034 [details] importatnt parts of syslog and ifcfg.log merged There seem to be changes of behaviour of inotify handling of ONBOOT= value modifications in ifcfg file between f15 and f16. In anaconda, we enable the device in GUI this way: - some default ifcfg file is written by anaconda (with ONBOOT=no, NM_CONTROLLED=yes) - nm-c-e is run - nm-c-e writes configuration set by user into ifcfg file (ONBOOT is usually no as nobody checks [x] Connect Automatically) - Anaconda writes ONBOOT=yes into the ifcfg file which should activate the device. In F16 it does not - hence this bug. (Note that the last step is missing if nm-c-e is invoked with "Configure Network" button). This can be seen from log I am attaching which is extract from syslog with log messages from ifcfg.log added at proper places. I'll add also equivalent log from F15 to compare.
Created attachment 514035 [details] importatnt parts of syslog and ifcfg.log merged This is the same log as in previous comment for F15.
I also tried to change the ONBOOT value manually in tty2 after setting the configuration in nm-c-e using "Configure network" button both in F15 and F16 and the difference makes me believe that there is inotify mechanism change out of anaconda. In F15: ======= ... 13:40:28,0 NOTICE NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-p3p1 13:40:28,0 NOTICE NetworkManager: ifcfg-rh: Managing connection 'System p3p1' and its device because NM_CONTROLLED was true. 13:40:28,0 INFO NetworkManager: <info> (p3p1): now managed 13:40:28,0 INFO NetworkManager: <info> (p3p1): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] 13:40:28,0 INFO NetworkManager: <info> (p3p1): bringing up device. 13:40:28,400 INFO kernel:[ 99.644069] pcnet32 0000:00:11.0: p3p1: link up 13:40:29,0 INFO NetworkManager: <info> (p3p1): preparing device. 13:40:29,0 INFO NetworkManager: <info> (p3p1): deactivating device (reason: 2). 13:40:29,0 INFO NetworkManager: <info> (p3p1): carrier now ON (device state 20) 13:40:29,0 INFO NetworkManager: <info> (p3p1): device state change: unavailable -> disconnected (reason 'carrier-chagned') [20 30 40] running nm-c-e (Configure Network button on hostname page) 13:40:36,0 NOTICE NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-p3p1 13:40:40,229 DEBUG kernel:[ 111.474355] p3p1: no IPv6 routers present editing ifcfg-p3p1 in vi (ONBOOT=no -> ONBOOT=yes) 13:41:09,0 NOTICE NetworkManager: ifcfg-rh: removed /etc/sysconfig/network-scripts/ifcfg-p3p1. 13:41:09,0 NOTICE NetworkManager: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-p3p1 .... 13:41:09,0 NOTICE NetworkManager: ifcfg-rh: read connection 'System p3p1' 13:41:09,0 INFO NetworkManager: <info> Activation (p3p1) starting connection 'System p3p1' 13:41:09,0 INFO NetworkManager: <info> (p3p1): device state change: disconnected -> prepare (reason 'none') [30 40 0] 13:41:09,0 INFO NetworkManager: <info> Activation (p3p1) Stage 1 of 5 (Device Prepare) scheduled... ... success In F16: ======= 13:59:43,0 NOTICE NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-p3p1 13:59:43,0 NOTICE NetworkManager: ifcfg-rh: Managing connection 'System p3p1' and its device because NM_CONTROLLED was true. 13:59:43,0 INFO NetworkManager: <info> (p3p1): now managed 13:59:43,0 INFO NetworkManager: <info> (p3p1): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] 13:59:43,0 INFO NetworkManager: <info> (p3p1): bringing up device. 13:59:43,929 INFO kernel:[ 139.583013] pcnet32 0000:00:11.0: p3p1: link up 13:59:44,0 INFO NetworkManager: <info> (p3p1): preparing device. 13:59:44,0 INFO NetworkManager: <info> (p3p1): deactivating device (reason: 2). 13:59:44,0 INFO NetworkManager: <info> (p3p1): carrier now ON (device state 20) 13:59:44,0 INFO NetworkManager: <info> (p3p1): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40] running nm-c-e (Configure Network button on hostname page) 13:59:54,0 NOTICE NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-p3p1 13:59:55,016 DEBUG kernel:[ 150.674260] p3p1: no IPv6 routers present editing ifcfg-p3p1 in vi (ONBOOT=no -> ONBOOT=yes) 14:00:23,0 NOTICE NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-p3p1 14:00:29,0 NOTICE dbus: [system] Activating service name='org.freedesktop.ModemManager' (using servicehelper) 14:00:29,0 NOTICE dbus: [system] Activated service 'org.freedesktop.ModemManager' failed: Cannot launch daemon, file not found or permissions invalid ... no success so trying something different: mv /etc/sysconfig/network-scripts/ifcfg-p3p1 /tmp 14:02:14,0 NOTICE NetworkManager: ifcfg-rh: removed /etc/sysconfig/network-scripts/ifcfg-p3p1. 14:02:29,0 NOTICE dbus: [system] Activating service name='org.freedesktop.ModemManager' (using servicehelper) 14:02:29,0 NOTICE dbus: [system] Activated service 'org.freedesktop.ModemManager' failed: Cannot launch daemon, file not found or permissions invalid cp /tmp/ifcfg-p3p1 /etc/sysconfig/network-scripts 14:02:54,0 NOTICE NetworkManager: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-p3p1 .... 14:02:54,0 NOTICE NetworkManager: ifcfg-rh: read connection 'System p3p1' 14:02:54,0 INFO NetworkManager: <info> Auto-activating connection 'System p3p1'. 14:02:54,0 INFO NetworkManager: <info> Activation (p3p1) starting connection 'System p3p1' 14:02:54,0 INFO NetworkManager: <info> (p3p1): device state change: disconnected -> prepare (reason 'none') [30 40 0] ... success
Jirka, could you take a look at comments #9, #10, #11 and see if NM is involved?
Thanks to Radek and James, The workarounds method worked and helped me to complete the rest tests, but I found another weird issue about anaconda. Although it is not always happening, but there might be something wrong with it, please refer Bug 723831.
(In reply to comment #3) > Requesting as a F16Alpha blocker as the presence of this bug impacts the > following criteria in pxeboot and DVD.iso installation scenarios ... > "The installer must be able to report failures to Bugzilla, with appropriate > information included" > > When booting anaconda-16.12-1 as a netinst/boot.iso, anaconda also fails to > activate networking when attempting to access the online repos. This impacts a > number of Alpha release criteria, most notably ... > "The installer must boot (if appropriate) and run on all primary > architectures from default live image, DVD, and boot.iso install media " Sounds like multiple reasons to vote +1 alpha blocker on this.
Discussed in the 2011-07-22 blocker bug review meeting. We could not come to an agreement on whether or not the workarounds listed in comment #1 would be enough to disqualify this bug as an alpha blocker. It will be reviewed again at next week's blocker bug review meeting.
Greeting, I'm happy to tell you that according to the test results of the latest version (Fedora-16-test-20110721-3-i386.iso), this problem has been resolved!
Created attachment 515039 [details] syslog for iso from previous comment (Fedora-16-test-20110721-3-i386.iso) Seems like another change of behaviour of NM in the Fedora-16-test-20110721-3-i386.iso (NM version 0.8.9997-5.git20110702.fc16). Now 'Wired connection 1' is activated automatically (by NM) with dhcp when device becomes nm-controlled (by anaconda). Changeing ifcfg-p3p1 (ONBOOT=no -> ONBOOT=yes) has still no effect.
Has this been resolved? comment #16 says that it has been fixed but comment #17 makes it sound like there is still work to do (or might be another bug). Can someone confirm whether or not the issue in this bug has or has not been resolved?
(In reply to comment #18) > Can someone confirm whether or not the issue in this bug has or has not been > resolved? I'm able to work around the original problem reported in this bug. I am able to activate networking from graphical anaconda. However, as Radek points out ... there are definitely some bugs lurking. 1) The nm-connection-editor dialog is themed such that it's impossible to distinguish between ... [ ] Connect automatically and [X] Connect automatically 2) there are duplicate devices listed in nm-connection-editor (as Radek points out in comment#17). http://jlaska.fedorapeople.org/screenshots/Screenshot.png #2 might be related to the original bug report. I hesitate to consider this bug resolved until we have official rel-eng produced ISO media to test with. If the problem doesn't occur there, we can move on to two new bug reports for the above issues.
Discussed in the 2011-07-29 blocker review meeting. Since the branched composes have not been completed at this time, we decided to wait another week before closing this bug out. Please create new bugs for the other issues described in the comments. They won't be considered for blocker status until new bugs are created for them.
(In reply to comment #12) > Jirka, could you take a look at comments #9, #10, #11 and see if NM is > involved? I don't see any problems in NetworkManager. At least for Fedora-16-test-20110721-3-i386.iso. I tested the ISO in KVM: $ qemu-kvm -hda /tmp/fedora-scratch.img -cdrom Download/Fedora-16-test-20110721-3-i386.iso -m 1024 -boot d * inotify functionality of kernel seems O.K. - tested using http://marc.info/?l=linux-kernel&m=124732816314881&w=4 * Here's what happening: - ifcfg-eth0 is not in place when NetworkManager starts, that's why NM creates default connection "Wired connection 1" and auto-activates that. - Then ifcfg-eth0 is created with ONBOOT="no" and NM_CONTROLLED="no" => eth0 is unmanaged by NM and thus disconnected - Then ifcfg-eth0 is updated with NM_CONTROLLED="yes" => eth0 is managed by NM and thus "Wired connection 1" is auto-activated again - When ifcfg-eth0 is updated with ONBOOT="yes", no new activation occurs, because the interface already has a valid active connection ("Wired connection 1") If you would like to prevent creation of default "Wired connection 1", ifcfg-eth0 has to be created *before* NM starts. Or add "no-auto-default=<MAC-of-the-interface>" option to NetworkManager.conf. (In reply to comment #5) > From /tmp/syslog ... > > 12:32:31,0 NOTICE dbus: [system] Activating service > name='org.freedesktop.ModemManager' (using servicehelper) > 12:32:31,0 NOTICE dbus: [system] Activated service > 'org.freedesktop.ModemManager' failed: Cannot launch daemon, file not found or > permissions invalid There's no /usr/sbin/modem-manager As far as GUI is concerned, I see the bad theming in nm-c-e as well. Entries have no borders, checkboxes are distinguished just by slightly more dark grey square.
For the record, Fedora-16-test-20110721-3-i386.iso uses anaconda 16.13 and NM 0.8.9997-5.git20110702.fc16. I encounter 2 errors while trying to install: 1) creating LVM when installing 2) trying to refresh/update already installed iso (installed previously without LVM) I was able to send both logs from KVM machine to my real machine using network (scp) without any problem.
Created attachment 516120 [details] anaconda error while (after) creating LVM
Created attachment 516122 [details] anaconda error while updating existing installation (in KVM)
(In reply to comment #22) > For the record, Fedora-16-test-20110721-3-i386.iso uses anaconda 16.13 and NM > 0.8.9997-5.git20110702.fc16. > > I encounter 2 errors while trying to install: > 1) creating LVM when installing Known issue (see bug#723144). Workaround by disabling LVM > 2) trying to refresh/update already installed iso (installed previously without > LVM) Likely same/similar cause as previous. > As far as GUI is concerned, I see the bad theming in nm-c-e as well. Entries > have no borders, checkboxes are distinguished just by slightly more dark grey > square. Yeah, we'll need a new bug report for that issue. I haven't yet filed it. Did you also see duplicate devices listed in the nm-c-editor dialog? This can be observed at http://jlaska.fedorapeople.org/screenshots/Screenshot.png? Assuming those are the only remaining issues, I think we can close this issue as the original problem of activating networking during graphical anaconda has been resolved.
(In reply to comment #21) > If you would like to prevent creation of default "Wired connection 1", > ifcfg-eth0 has to be created *before* NM starts. Or add > "no-auto-default=<MAC-of-the-interface>" option to NetworkManager.conf. > Jirka thanks for analysing, this is caused by systemd starting NM in F16. We seem to need to disable it, or to restart NM after we write out our initial ifcfg files. I am looking into it. I wonder why in the log/case from comment #9 (a bit earlier compose of F16 than the 0721-3) there is no auto connection, loader probably wins the race and writes the initial ifcfg files in time, but the ONBOOT=yes change doesn't work anyway.
So we seem to have two serious problems here: 1) Original issue of this BZ: NM doesn't activate a device after change of its ifcfg ONBOOT value from no to yes (comments #1 #9 #10 #11) Jirka Klimes is investigating this. 2) Automatic default "Wired connection X" is activated because systemd starts NM before anaconda writes out inital ifcfg files (or they can race). Comments #17, #19 2). It was hit in compose 0721 and it can hide problem 1). We could restart NM after we write ifcfg files in loader (that's what I'd prefer) or disable it when creating install image. 1) and 2) deserve separate BZs. Also some minor problems are mentioned: 3) The ModemManager error message from comment #5 has been there for some time and is harmless. As Jirka says /usr/sbin/modem-manager is missing in our image. 4) State of checkboxes in nm-c-e (Connect automatically) is hard to distinguish. Is it anaconda specific or is it there also post-install?
(In reply to comment #27) > So we seem to have two serious problems here: > > 1) Original issue of this BZ: NM doesn't activate a device after change of its > ifcfg ONBOOT value from no to yes (comments #1 #9 #10 #11) > > Jirka Klimes is investigating this. > There was a regression in NM's ifcfg-rh plugin. It's been fixed upstream, see bug 727501.
(In reply to comment #25) > Did you also see duplicate devices listed in the nm-c-editor dialog? This can > be observed at http://jlaska.fedorapeople.org/screenshots/Screenshot.png? > That's correct because there are two interface and each interface has one default connection and one from ifcfg-ethX file.
(In reply to comment #28) > There was a regression in NM's ifcfg-rh plugin. It's been fixed upstream, see > bug 727501. Thanks! I tested locally a build of patched ifcfg-rh that Jirka sent me and it fixes the issue (1) from comment #27) in anaconda.
(In reply to comment #27) > So we seem to have two serious problems here: > > 1) Original issue of this BZ: NM doesn't activate a device after change of its > ifcfg ONBOOT value from no to yes (comments #1 #9 #10 #11) > > Jirka Klimes is investigating this. > > 2) Automatic default "Wired connection X" is activated because systemd starts > NM before anaconda writes out inital ifcfg files (or they can race). Comments > #17, #19 2). It was hit in compose 0721 and it can hide problem 1). > > We could restart NM after we write ifcfg files in loader (that's what I'd > prefer) or disable it when creating install image. Filed as bug#727951 > 1) and 2) deserve separate BZs. I assume you will use this bug to track #1? > Also some minor problems are mentioned: > > 3) The ModemManager error message from comment #5 has been there for some time > and is harmless. As Jirka says /usr/sbin/modem-manager is missing in our image. Filed as bug#727946 > 4) State of checkboxes in nm-c-e (Connect automatically) is hard to > distinguish. Is it anaconda specific or is it there also post-install? I'm not sure, I've not managed to get a system installed+booted yet.
James, thanks for filing the specific bugs. (In reply to comment #31) > I assume you will use this bug to track #1? Exactly.
Just to recap what issues are in what bugs: > 1) Original issue of this BZ: NM doesn't activate a device after change of its > ifcfg ONBOOT value from no to yes (comments #1 #9 #10 #11 bug 727501 > 2) Automatic default "Wired connection X" is activated because systemd starts > NM before anaconda writes out inital ifcfg files (or they can race). Comments > #17, #19 2). It was hit in compose 0721 and it can hide problem 1). bug 727951 > 3) The ModemManager error message from comment #5 has been there for some time > and is harmless. As Jirka says /usr/sbin/modem-manager is missing in our image bug 727946 > 4) State of checkboxes in nm-c-e (Connect automatically) is hard to > distinguish. Is it anaconda specific or is it there also post-install? not triaged or filed. Is this bug just a tracker then? It seems to me that all of the issues mentioned in this bug have been filed elsewhere or are still undergoing triage.
(In reply to comment #31) > > 4) State of checkboxes in nm-c-e (Connect automatically) is hard to > > distinguish. Is it anaconda specific or is it there also post-install? > > I'm not sure, I've not managed to get a system installed+booted yet. I tested a custom built boot.iso yesterday using the latest pungi, lorax and anaconda packages ... and whatever else is in f16-stable. The nm-connection-editor checkboxes looked just fine. They properly display a [X] when selecting "Connect automatically". I think issue#4 magically may have fixed itself.
*** This bug has been marked as a duplicate of bug 727501 ***