Bug 723475 - anaconda-16.12 - Unable to activate networking in anaconda (stage2)
anaconda-16.12 - Unable to activate networking in anaconda (stage2)
Status: CLOSED DUPLICATE of bug 727501
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F16Alpha/F16AlphaBlocker
  Show dependency treegraph
 
Reported: 2011-07-20 06:17 EDT by Tao Wu
Modified: 2014-10-28 19:45 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-05 16:52:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/tmp/anaconda.log (16.60 KB, text/plain)
2011-07-20 09:37 EDT, James Laska
no flags Details
/tmp/syslog (66.90 KB, text/plain)
2011-07-20 09:37 EDT, James Laska
no flags Details
importatnt parts of syslog and ifcfg.log merged (7.69 KB, text/plain)
2011-07-20 11:19 EDT, Radek Vykydal
no flags Details
importatnt parts of syslog and ifcfg.log merged (15.72 KB, text/plain)
2011-07-20 11:21 EDT, Radek Vykydal
no flags Details
syslog for iso from previous comment (Fedora-16-test-20110721-3-i386.iso) (69.90 KB, text/plain)
2011-07-25 09:04 EDT, Radek Vykydal
no flags Details
anaconda error while (after) creating LVM (337.68 KB, text/plain)
2011-08-01 08:09 EDT, Jirka Klimes
no flags Details
anaconda error while updating existing installation (in KVM) (188.61 KB, text/plain)
2011-08-01 08:11 EDT, Jirka Klimes
no flags Details

  None (edit)
Description Tao Wu 2011-07-20 06:17:58 EDT
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:
Comment 1 Radek Vykydal 2011-07-20 06:39:49 EDT
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.
Comment 2 James Laska 2011-07-20 08:06:16 EDT
(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
Comment 3 James Laska 2011-07-20 08:24:20 EDT
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
Comment 4 Radek Vykydal 2011-07-20 08:43:24 EDT
(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.
Comment 5 James Laska 2011-07-20 09:36:59 EDT
(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
Comment 6 James Laska 2011-07-20 09:37:30 EDT
Created attachment 514009 [details]
/tmp/anaconda.log
Comment 7 James Laska 2011-07-20 09:37:47 EDT
Created attachment 514010 [details]
/tmp/syslog
Comment 8 James Laska 2011-07-20 10:43:59 EDT
(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!
Comment 9 Radek Vykydal 2011-07-20 11:19:08 EDT
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.
Comment 10 Radek Vykydal 2011-07-20 11:21:26 EDT
Created attachment 514035 [details]
importatnt parts of syslog and ifcfg.log merged

This is the same log as in previous comment for F15.
Comment 11 Radek Vykydal 2011-07-20 11:33:39 EDT
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
Comment 12 Radek Vykydal 2011-07-20 11:37:52 EDT
Jirka, could you take a look at comments #9, #10, #11 and see if NM is involved?
Comment 13 Tao Wu 2011-07-21 05:57:00 EDT
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.
Comment 14 Tim Flink 2011-07-21 12:47:03 EDT
(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.
Comment 15 Tim Flink 2011-07-22 17:15:30 EDT
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.
Comment 16 Tao Wu 2011-07-25 05:55:16 EDT
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!
Comment 17 Radek Vykydal 2011-07-25 09:04:16 EDT
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.
Comment 18 Tim Flink 2011-07-28 16:56:48 EDT
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?
Comment 19 James Laska 2011-07-29 08:09:33 EDT
(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.
Comment 20 Tim Flink 2011-07-29 13:12:28 EDT
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.
Comment 21 Jirka Klimes 2011-08-01 08:01:41 EDT
(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.
Comment 22 Jirka Klimes 2011-08-01 08:07:34 EDT
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.
Comment 23 Jirka Klimes 2011-08-01 08:09:38 EDT
Created attachment 516120 [details]
anaconda error while (after) creating LVM
Comment 24 Jirka Klimes 2011-08-01 08:11:24 EDT
Created attachment 516122 [details]
anaconda error while updating existing installation (in KVM)
Comment 25 James Laska 2011-08-01 08:56:47 EDT
(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.
Comment 26 Radek Vykydal 2011-08-01 09:30:57 EDT
(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.
Comment 27 Radek Vykydal 2011-08-01 11:56:39 EDT
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?
Comment 28 Jirka Klimes 2011-08-02 06:33:09 EDT
(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.
Comment 29 Jirka Klimes 2011-08-02 06:42:05 EDT
(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.
Comment 30 Radek Vykydal 2011-08-02 08:32:50 EDT
(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.
Comment 31 James Laska 2011-08-03 14:43:28 EDT
(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.
Comment 32 Radek Vykydal 2011-08-04 04:53:49 EDT
James, thanks for filing the specific bugs.

(In reply to comment #31)
> I assume you will use this bug to track #1?

Exactly.
Comment 33 Tim Flink 2011-08-04 17:25:57 EDT
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.
Comment 34 James Laska 2011-08-05 10:41:11 EDT
(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.
Comment 35 Tim Flink 2011-08-05 16:52:32 EDT

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

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