Bug 633315 - Connections not editable in nm-c-e in anaconda
Summary: Connections not editable in nm-c-e in anaconda
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Radek Vykydal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F14Beta, F14BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2010-09-13 14:52 UTC by Radek Vykydal
Modified: 2010-10-06 22:02 UTC (History)
6 users (show)

Fixed In Version: anaconda-14.17.4-1.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-22 04:08:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
syslog (63.52 KB, text/plain)
2010-09-13 14:52 UTC, Radek Vykydal
no flags Details
syslog Fedora 14 TC1, virtual machine (49.61 KB, text/plain)
2010-09-16 12:34 UTC, Jirka Klimes
no flags Details

Description Radek Vykydal 2010-09-13 14:52:01 UTC
Created attachment 446956 [details]
syslog

Description of problem:

Existing connections having NM_CONTROLLED=yes are not editable in nm-c-e in anaconda.

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


F14 Beta TC1
anaconda 14.17.1
NetworkManager (version 0.8.1-5.git20100818.fc14)

How reproducible:
Always

Steps to Reproduce:
1. Run installation enabling network in loader (fetching ks or stage 2 over network, or using asknetwork boot parameter)
2. Click "Configure Network" in stage 2
3. Try to edit existing connection in nm-c-e
  
Actual results:

Edit is grayed-out

Expected results:

Additional info:

Attaching syslog, see PolicyKit errors, these errors appear when running nm-c-e:

... 
18:26:20,593 ERR NetworkManager: polkit_authority_check_authorization: assertion `POLKIT_IS_AUTHORITY (authority)' failed
18:26:21,071 NOTICE NetworkManager:    ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0
18:26:21,144 INFO polkitd: started daemon version 0.98 using authority implementation `local' version `0.98'
18:27:39,006 ERR NetworkManager: polkit_authority_check_authorization: assertion `POLKIT_IS_AUTHORITY (authority)' failed
...

Comment 1 Radek Vykydal 2010-09-13 15:00:31 UTC
Dan, any ideas?

Comment 2 Radek Vykydal 2010-09-14 08:50:44 UTC
Proposing as a blocker.

Comment 3 Adam Williamson 2010-09-14 20:05:31 UTC
We discussed this at the interim blocker review meeting today. We can't see any reason to consider it a blocker; as far as we can tell, there's no case in which you'd actually need to configure a network interface at this point in order to successfully complete an install. Radek, if you think we missed something, please re-propose it with an explanation of why. thanks.

Comment 4 Radek Vykydal 2010-09-15 09:31:32 UTC
(In reply to comment #3)
> We discussed this at the interim blocker review meeting today. We can't see any
> reason to consider it a blocker; as far as we can tell, there's no case in
> which you'd actually need to configure a network interface at this point in
> order to successfully complete an install. Radek, if you think we missed
> something, please re-propose it with an explanation of why. thanks.

Though I am not sure if it can be subsumed under point 5. F14 of Beta release criteria, I am re-proposing to make sure that you are aware of these cases:

For all network enablement in stage 2 only DHCP will work (as it is default and there is no possibility of editing in nm-c-e used for the enablement), examples:
- netinstall - fatal (with workarounds forcing enablement in stage1 or using ks)
- DVD install: enabling Updates repo (Fedora 14-Beta ... in beta), adding any network repo, or changing Installation Repo to a network target.

Re-proposing to reconsider these cases.

Comment 5 Adam Williamson 2010-09-15 12:28:51 UTC
do you still get to configure the network parameters at the start of installation, as you did with previous releases? i.e. is there actually any change from previous releases here, bearing in mind that in the past there was simply no possibility to do network configuration at this point in install at all, you did it all earlier?

Comment 6 Radek Vykydal 2010-09-15 13:14:50 UTC
In previous releases we did network enablement in stage 2 with our own configuration dialog which is replaced with nm-c-e now. And as with previous releases, user is not asked to enable network (that is to configure selected device) until it is needed which may be in stage 2 in some cases (e.g. that of in comment #4) .

Starting from some release (I guess 10?) till 13, there has not been network _configuration_ strictly speaking (in a sense that you can configure all devices like now in nm-c-e), only network enablement (selecting a device and configuring it in a limited way - no ipv6, no wireless).

To put it short, the cases from comment #4 would work in f13 with our limited stage 2 enablement dialog.

Comment 7 Adam Williamson 2010-09-15 13:27:51 UTC
"To put it short, the cases from comment #4 would work in f13 with our limited
stage 2 enablement dialog."

That seems like the salient point. =) In that case I'd certainly like this fixed for Beta. That means we need a fix v. soon (today preferably).

Comment 8 Radek Vykydal 2010-09-16 08:42:38 UTC
If I add the whole polkit package to initrd.img, the problem is gone. Now to work out how to change the scripts/mk-images file.

Comment 9 Radek Vykydal 2010-09-16 12:30:12 UTC
We need to get these files from polkit into initrd.img:

/usr/libexec/polkitd
/lib/libpolkit-backend-1.so.0
/usr/share/polkit-1/actions/*

This patch should do it, it is not tested yet:

diff --git a/scripts/mk-images b/scripts/mk-images
index d2ca018..b096f4c 100755
--- a/scripts/mk-images
+++ b/scripts/mk-images
@@ -565,6 +565,7 @@ makeinitrd() {
     mkdir -p $MBD_DIR/etc/terminfo/{a,b,d,l,s,v,x}
     mkdir -p $MBD_DIR/tmp
     mkdir -p $MBD_DIR/usr/libexec
+    mkdir -p $MBD_DIR/usr/libexec/polkit-1
     mkdir -p $MBD_DIR/usr/$LIBDIR/NetworkManager
     mkdir -p $MBD_DIR/$LIBDIR/rsyslog
     mkdir -p $MBD_DIR/usr/share/dbus-1/system-services
@@ -600,6 +601,7 @@ makeinitrd() {
 
     cp $IMGPATH/$LIBDIR/libpam_misc.so.0.* $MBD_DIR/$LIBDIR/libpam_misc.so.0
     cp $IMGPATH/$LIBDIR/libwrap*.so* $MBD_DIR/$LIBDIR/
+    cp $IMGPATH/usr/$LIBDIR/libpolkit-backend-1.so.0.* $MBD_DIR/$LIBDIR/libpolkit-backend-1.so.0
 
     if [ "$BUILDARCH" = "s390" -o "$BUILDARCH" = "s390x" ]; then
         ln -s /tmp $MBD_DIR/var/state/xkb
@@ -750,11 +752,14 @@ makeinitrd() {
       cp -a org.freedesktop.PolicyKit1.service $MBD_DIR/usr/share/dbus-1/system-services
     )
     ( cd $IMGPATH/usr/share/polkit/actions
-      cp -a org.freedesktop.policykit.policy $MBD_DIR/usr/share/polkit-1/actions
+      for f in *.policy; do
+          cp -a $f $MBD_DIR/usr/share/polkit-1/actions
+      done
     )
     cp -a $IMGPATH/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf $MBD_DIR/etc/dbus-1/system.d
     cp -a $IMGPATH/etc/dbus-1/system.d/ConsoleKit.conf $MBD_DIR/etc/dbus-1/system.d
     chmod 04755 $IMGPATH/usr/libexec/polkit-1/polkit-agent-helper-1
+    cp -a $IMGPATH/usr/libexec/polkit-1/polkitd $MBD_DIR/usr/libexec/polkit-1
 
     # dbus
     instbin $IMGPATH /usr/bin/dbus-uuidgen $MBD_DIR /sbin/dbus-uuidgen

Comment 10 Jirka Klimes 2010-09-16 12:33:14 UTC
Yes, it seems to be PolicyKit problem.
I've tested it in virtual machine with Fedora 14 TC1.

There are the errors in syslog:
11:18:38,873 WARNING NetworkManager: <warn> failed to create PolicyKit
authority: (23) Error initializing authority: Error calling StartServiceByName
for org.freedesktop.PolicyKit1:
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Cannot launch daemon,
file not found or permissions invalid
11:18:38,874 INFO NetworkManager: <info> monitoring kernel firmware directory
'/lib/firmware'.
11:18:38,901 WARNING NetworkManager: <warn> failed to create PolicyKit
authority: (23) Error initializing authority: Error calling StartServiceByName
for org.freedesktop.PolicyKit1:
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Cannot launch daemon,
file not found or permissions invalid

The full syslog included in the attachment.

PolicyKit isn't correctly configured and a D-Bus call fails, see
http://cgit.freedesktop.org/PolicyKit/tree/src/polkit/polkitauthority.c?#n317

The other subsequent error:
11:20:59,447 ERR NetworkManager: polkit_authority_check_authorization:
assertion `POLKIT_IS_AUTHORITY (authority)' failed
comes due to more strictly parameter checking in PolicyKit:
http://cgit.freedesktop.org/PolicyKit/commit/?id=eab94aa83209559b2c3f48490778177f1f3b6f97

Should component be changed to anaconda or something else?

Comment 11 Jirka Klimes 2010-09-16 12:34:41 UTC
Created attachment 447727 [details]
syslog Fedora 14 TC1, virtual machine

Comment 12 Radek Vykydal 2010-09-17 08:55:42 UTC
Thanks for explanation Jirka, I am reassigning back to anaconda. Final version of tested patch is in a-d-l.

Comment 13 Fedora Update System 2010-09-17 20:03:42 UTC
anaconda-14.17.3-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.17.3-1.fc14

Comment 14 Adam Williamson 2010-09-18 08:46:39 UTC
Confirmed with RC1 this works. However, I did notice that if you do a network install and create an invalid network configuration, you get stuck: you get into a cycle of error messages which offer you the ability to retry, or to edit the repository configuration, but not to edit the network configuration. I imagine this is because, in the previous system, the network configuration was tested at the actual configuration step, and it wouldn't let you proceed until the network config worked. With the new system, you can set up any network config you like in nm-c-e - even one that doesn't work - and then the repo step is where the failure is caught.

So we should either modify the repo config step so that when it fails, you have the option to edit the network configuration; or we should not let the user out of the nm-c-e step until they have a working network config. I think the former would probably be more 'polite', but whatever.

We should probably track this in a new report, but for now I'm leaving this open, since the anaconda package hasn't actually been pushed stable yet.

Comment 15 Adam Williamson 2010-09-18 10:30:55 UTC
I'm going to mark this VERIFIED as the bug tracked here is fixed. I'll file a new report for the issue I just mentioned.

Comment 16 Adam Williamson 2010-09-18 10:42:13 UTC
New issue filed as https://bugzilla.redhat.com/show_bug.cgi?id=635239

Comment 17 Fedora Update System 2010-09-20 18:41:38 UTC
anaconda-14.17.3-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.17.3-1.fc14

Comment 18 Fedora Update System 2010-09-20 23:32:10 UTC
anaconda-14.17.4-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.17.4-1.fc14

Comment 19 Fedora Update System 2010-09-22 04:07:35 UTC
anaconda-14.17.4-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 20 Fedora Update System 2010-10-06 22:02:48 UTC
anaconda-14.18-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.18-1.fc14


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