I have created liveCD today, and installing it on hard drive I have get this bug during detecting disks (in attachment). So installation failed. If I downgrade NetworkManager (and dbus-glib) to previous version, this bug is absent.
Created attachment 440634 [details] Anaconda traceback
I have the exact same problem with the same anaconda error as in Arkady's attachment, when trying to respin Fedora using revisor, and then trying to install with Kickstart. The previous version worked, but it's cumbersome as revisor doesn't allow to use older packages.
Created attachment 441356 [details] Anaconda tracelog with NM crash
*** Bug 628037 has been marked as a duplicate of this bug. ***
I've created F13 LiveCD with the latest NM (NetworkManager-0.8.1-4.git20100817.fc13.x86_64) and test this - confirm the behaviour descripted. When previous NetworkManager is installed, the installation works. However, after debugging it showed up that the bug is not in NetworkManager, but rather in anaconda. It reads 'Devices' property on a bad interface: "org.freedesktop.NetworkManager" instead of "org.freedesktop.NetworkManager.Connection.Active" Reported error: anaconda 13.42 exception report Traceback (most recent call first): File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking message, timeout) File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__ **keywords) File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 68, in __call__ return self._proxy_method(*args, **keywords) File "/usr/lib/anaconda/network.py", line 86, in getDefaultHostname devices = active_connection_props_iface.Get(isys.NM_MANAGER_IFACE, 'Devices') File "/usr/lib/anaconda/iw/network_gui.py", line 37, in getScreen self.hostname = network.getDefaultHostname(anaconda) File "/usr/lib/anaconda/gui.py", line 1393, in setScreen new_screen = self.currentWindow.getScreen(anaconda) File "/usr/lib/anaconda/gui.py", line 1314, in nextClicked self.setScreen () DBusException: org.freedesktop.DBus.Error.AccessDenied: Interface "org.freedesktop.NetworkManager" isn't exported (or may not exist), can't access property "Devices" The bug started to appear due to a change in dbus-glib, that now strictly checks interfaces. See https://bugzilla.redhat.com/show_bug.cgi?id=585394 for detailed discussion and dbus-glib commit: http://cgit.freedesktop.org/dbus/dbus-glib/commit/?h=rhel5&id=9a6bce9b615abca6068348c1606ba8eaf13d9ae0 NetworkManager swiches this behaviour on by calling dbus_glib_global_set_disable_legacy_property_access(), if it's available. http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=92babdb658109cab5cdf9fc0280264ef0715f37d You can try these commands: dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/ActiveConnection/0 org.freedesktop.DBus.Properties.Get string:"org.freedesktop.NetworkManager.Connection.Active" string:"Devices" dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/ActiveConnection/0 org.freedesktop.DBus.Properties.Get string:"whatever" string:"Devices" The first works always, the second just with previous NetworkManager (dbus-glib) versions without checking interface.
Created attachment 442145 [details] Patch fixing NM D-Bus interface for 'Devices' property And six lines bellow: ip4_config_path = device_props_iface.Get(isys.NM_MANAGER_IFACE, 'Ip4Config') should read ip4_config_path = device_props_iface.Get(isys.NM_DEVICE_IFACE, 'Ip4Config') Please, check other properties as well (using d-feet is very helpful).
This is fixed in anaconda-14.6-1, or Fedora 14. *** This bug has been marked as a duplicate of bug 594716 ***
whether this patch will be back ported?
I second the request for the fix to be back-ported to Fedora 13 since it also affects Fedora 13. On the livecd-tools mailing list I saw a user being told to downgrade NetworkManager. Not a good solution.
We don't release updates for anaconda as that requires making entirely new media spins which requires additional QA work, rel-eng work, etc. It may be possible to configure your livecd-creator kickstart file to grab patched version of anaconda.
Also DVD respin does not work with this bug.
(In reply to comment #10) > We don't release updates for anaconda as that requires making entirely new > media spins which requires additional QA work, rel-eng work, etc. > It may be possible to configure your livecd-creator kickstart file to grab > patched version of anaconda. You don't have to roll-out new media spins. The problem is if some one tries to create a remix of Fedora like (omega.dgplug.org) using livecd-creator it won't work because of this bug.
Alright, reassigning to livecd-tools - they will know better how to configure kisckstart so that updated anaconda is used to create the Live CD.
You just add the repository in which the new Anaconda is in and add that as a package in %packages This isn't a livecd-creator or livecd-tools bug, and one person mentions revisor, which makes this the wrong component if you are reassigning just to get information.
Thanks for info Jasper, sorry but I can't decide if it is livecd-tools bug or not. From the anaconda point of view, the bug is fixed and we can't do anything to help the reporter. Taking your word that it is not a livecd-tools bug, I am reassigning to revisor then.
(In reply to comment #14) > You just add the repository in which the new Anaconda is in and add that as a > package in %packages This isn't a livecd-creator or livecd-tools bug, and one > person mentions revisor, which makes this the wrong component if you are > reassigning just to get information. If the fixed anaconda in rawhide and if i enable that repository won't that become a remix of F14? I downloaded anaconda-14.6-1 rpm and added it to my custom repo, building livecd failed with the following dependency failure /usr/lib/python2.6/site-packages/imgcreate/errors.py:45: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 return unicode(self.message) Error creating Live CD : Failed to build transaction : anaconda-14.16-1.fc14.i686 requires python-meh >= 0.8 anaconda-14.16-1.fc14.i686 requires pykickstart >= 1.77 anaconda-14.16-1.fc14.i686 requires libz.so.1(ZLIB_1.2.3.3) anaconda-14.16-1.fc14.i686 requires python(abi) = 2.7 anaconda-14.16-1.fc14.i686 requires libblkid.so.1(BLKID_2.18)
Since when does updating a package require the re-release of install media? That statement is absurd... at least from the outside where I'm sitting. I also don't see how you keep trying to push the bug off to other packages. It appears that the NetworkManager update caused the bug in anaconda to manifest itself. The better answer would be to: 1) Fix NetworkManager so it doesn't cause anaconda's failure - It is fine to reassign the bug to NetworkManager in this case. or 2) Update anaconda so the NetworkManager caused bug no longer applies - Updating anaconda in Fedora 14 only and assuming people can use it in previous releases doesn't seem to be working out. In any event, the longer it goes unfixed... the longer respin and remix makers are dead in the water.
*** Bug 629320 has been marked as a duplicate of this bug. ***
I modded my kickstart with a simple "yum update --exclude=NetworkManager-glib,NetworkManager-gnome,NetworkManager". Now they build and install successfully.
Im respinning a Fedora 12 DVD. Did also removing NetworkManager* from revisor repositories and configured kickstart to not install them with explicit at %packages block -NetworkManager -NetworkManager-gnome -NetworkManager-openconnect -NetworkManager-openvpn -NetworkManager-pptp -NetworkManager-vpnc Also tried text install from kickstart and --install-nogr at revisor command line to get a better debug, but the same problem plus it could not detect my network card.
(In reply to comment #20) > Im respinning a Fedora 12 DVD. > > Did also removing NetworkManager* from revisor repositories and configured > kickstart to not install them with explicit at %packages block > -NetworkManager > -NetworkManager-gnome > -NetworkManager-openconnect > -NetworkManager-openvpn > -NetworkManager-pptp > -NetworkManager-vpnc > > Also tried text install from kickstart and --install-nogr at revisor command > line to get a better debug, but the same problem plus it could not detect my > network card. Try these https://bugzilla.redhat.com/show_bug.cgi?id=624028#c25
I deleted NetworkManager-0.8.3* from /var/tmp/revisor-yumcache/updates/packages and changed to enabled=0 at the [update] sector on /etc/revisor/conf.d/[myrespin].conf It was sucessful to me. Thanks Arun.
*** Bug 632575 has been marked as a duplicate of this bug. ***
Ok, let me get this right... the bug is in anaconda... although it isn't a bug really... it is just that dbus was changed and NetworkManager uses the changed dbus... and anaconda doesn't handle these changes well so it crashes. Someone mentioned "revisor" in one of the posts... so someone who has power to reassign bugs... decided that they'd just reassign this bug to revisor (even though it has nothing to do with revisor)... and here it stays parked and unresolved. I assume revisor was chosen because whoever moved it to revisor wouldn't have deal with it because that isn't a package they maintain. I'm sure there is some sarcasm implied above... but I don't really mean it that way. I'm just trying to understand the status of this bug. Is that the proper assessment?
What needs to happen here is that someone needs to backport various patches from F14 anaconda to F13 and do a rebuild of that package so it can be updated and included in future respins. In the past, Jeroen has done this for other anaconda fixes. He's got commit access (or should - if not, I can fix that) and this bug is assigned to him so he's aware of it. The anaconda team in general does not release updates for previous releases, as it's enough work keeping up with these kinds of unannounced changes for the various upcoming releases, in addition to trying to get something new done from time to time.
Created attachment 447334 [details] Patches anaconda 13.42 to support new D-Bus spec of NetworkManager
Created attachment 447335 [details] Updated anaconda-13.42 RPM spec file
The above patch for anaconda-13.42 has been tested on i686 and x86_64. For some reasons the D-Bus spec of the NetworkManager-0.8.1-x has changed and crashed anaconda. There is also an anaconda patch for the latest Fedora 12 NetworkManager available
Created attachment 447358 [details] Patch for anaconda 12.46 to support new D-Bus spec of NetworkManager
Created attachment 447359 [details] Updated anaconda-12.46 RPM spec file
Thanks for the patches, Richard! Is there any kind soul here who can commit them? Jeroen?
After trying out the patches, I also found that they seem to be incomplete. The following line seems to have the same problem as the others: From isys.py: device_type = int(device_props_iface.Get(NM_MANAGER_IFACE, "DeviceType")) I don't know what the correct line is, but commenting this one out allowed me to continue.
(In reply to comment #32) I tested the patches before going public. Everything worked fine here but we never know for sure until others test... I see, you are a wireless user... I am still wired... this is the part I could not thoroughly test. Well, that should be easy to fix. Since I do not have a wireless card to test could you do that for me? Just replace NM_MANAGER_IFACE with NM_DEVICE_IFACE of that line. This should work. For those interested in the D-Bus spec of the NetworkManager here is the link for more info http://projects.gnome.org/NetworkManager/developers/spec-08.html . Chris, let me know you test result so that I can go ahead and create a new patch. Thanks Richard
(In reply to comment #27) > Created attachment 447335 [details] > Updated anaconda-13.42 RPM spec file My LiveUSB as built last night: $ uname -a Linux localhost.localdomain 2.6.34.6-54.fc13.i686 #1 SMP Sun Sep 5 17:52:31 UTC 2010 i686 i686 i386 GNU/Linux I applied the patch for anaconda 13.42 and now it fails here: anaconda 13.42 exception report Traceback (most recent call first): File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking message, timeout) File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__ **keywords) File "/usr/lib/anaconda/isys.py", line 400, in getMacAddress device_macaddr = device_props_iface.Get(NM_WIRED_DEVICE_IFACE, "HwAddress").upper() File "/usr/lib/anaconda/network.py", line 391, in available hwaddr = isys.getMacAddress(dev) File "/usr/lib/anaconda/network.py", line 343, in __init__ available_devices = self.available() File "/usr/sbin/anaconda", line 546, in network self._network = network.Network() File "/usr/lib/anaconda/iw/network_gui.py", line 82, in getNext self.anaconda.network.hostname = hostname File "/usr/lib/anaconda/gui.py", line 1309, in nextClicked rc = self.currentWindow.getNext () DBusException: org.freedesktop.DBus.Error.AccessDenied: Interface "org.freedesktop.NetworkManager.Device.Wired" isn't exported (or may not exist), can't access property "HwAddress" It was only when I checked manually that the patch had been applied correctly that I realized the failing line - 400 - was part of the patch. This is very important for me so please let me know if there is anything i can do to help. Note. I applied the patch file to network.py and isys.py. I looked at the updated spec file and concluded it was only needed for re-building the rpm. If there was any information in that file that I should have acted upon please let me know.
Created attachment 448383 [details] d-feet screenshot showing property "HwAddress" My anaconda traceback said: DBusException: org.freedesktop.DBus.Error.AccessDenied: Interface "org.freedesktop.NetworkManager.Device.Wired" isn't exported (or may not exist), can't access property "HwAddress" This attached png file shows d-feet accessing the required value and everything looks right to me, but I only installed d-feet yesterday and I am a complete d-bus novice. In case it helps... $ yum list NetworkManager . . . Installed Packages NetworkManager.i686 1:0.8.1-6.git20100831.fc13 @updates/$releasever
(In reply to comment #35) > Created attachment 448383 [details] > d-feet screenshot showing property "HwAddress" ... > NetworkManager.i686 1:0.8.1-6.git20100831.fc13 Hi Andrew, I tested 32/64 bit with NetworkManager '-4' and '-6'. In fact, I installed last Friday my LiveUSB build from last week on an N450 Atom board and did not any issues... I posted the updated Anaconda RPM build file since some of the dependencies have changed and one more dependency had to be added. Please make sure that the 'device-mapper-multipath >= 0.4.9-14' is available in your LiveUSB build. I ran in this issue when I only modified the isys.py and network.py files but did not have this package installed. Also make sure that you are using the latest updates when building your LiveUSB. I sometimes flush my local cache (/var/cache/live) to force the livecd build script to re-download those packages.
(In reply to comment #36) > ... > I posted the updated Anaconda RPM build file since some of the dependencies > have changed and one more dependency had to be added. Please make sure that > the 'device-mapper-multipath >= 0.4.9-14' is available in your LiveUSB build. > I ran in this issue when I only modified the isys.py and network.py files but > did not have this package installed. > Also make sure that you are using the latest updates when building your > LiveUSB. I sometimes flush my local cache (/var/cache/live) to force the > livecd build script to re-download those packages. All the versions looked OK but I have deleted my cache and am running a new download/build to run overnight. I'll let you know what happens tomorrow
> All the versions looked OK but I have deleted my cache and am running a new > download/build to run overnight. I'll let you know what happens tomorrow Same results as yesterday. I apologise in advance for being a perl hacker who knows enough python to understand more or less what is going on but not enough to write solid code. I looked at the defines in isys.py (patched) and realized there was a define for the device interface of an ethernet card ( NM_WIRED_DEVICE_IFACE = "org.freedesktop.NetworkManager.Device.Wired" ) but not for a Wireless card (something like NM_WIRELESS_DEVICE_IFACE = "org.freedesktop.NetworkManager.Device.Wireless" ) I found a notebook whose wifi I could disable, disabled wifi and tried a live install. Perfect - it went straight from collecting the hostname to the timezone entry dialog. I went no further than that as it wasn't my notebook and the owner did not wish to upgrade to F13 at this time. Disabling the Wifi adaptor is not an option on the notebook I am trying to install. So I have a couple of comments about the getMacAddress(dev) function in isys.py and I apologize AGAIN for not knowing enough python to provide a fix... 1) I believe it should determine if the interface is wired or wireless and select .Wired or .Wireless accordingly when calling the Get method Alternatively: 2) isys.py (patched) Line 400: device_macaddr = device_props_iface.Get(NM_WIRED_DEVICE_IFACE, "HwAddress").upper() is in a try - except block but does not fail gracefully. Would it work if you put a try-(Get Wireless HW Address)-except block in the existing except block and only abort if you reach the new internal except block? I managed to rebuild my iso last night but won't be able to do another until the kmods for the new kernel are released. The ones I need were not available this morning. No problem to apply patches to the existing installation though
*** Bug 636141 has been marked as a duplicate of this bug. ***
(In reply to comment #38) ... > I looked at the defines in isys.py (patched) and realized there was a define > for the device interface of an ethernet card ( NM_WIRED_DEVICE_IFACE = > "org.freedesktop.NetworkManager.Device.Wired" ) > > but not for a Wireless card (something like NM_WIRELESS_DEVICE_IFACE = > "org.freedesktop.NetworkManager.Device.Wireless" ) ... Andrew, That is absolutely correct. I did not have any wireless card... but now I do so I added a bit more code to the getMacAddress(dev) method. I tested it with wireless only and with wired-only network. Now, everything should work as expected for wireless and wired users - even then when no network is detected/configured. I will post a patch soon
Created attachment 449078 [details] Updated isys.py (still doesn't work if network device has no mac address) (In reply to comment #40) > Andrew, > That is absolutely correct. I did not have any wireless card... but now I do > so I added a bit more code to the getMacAddress(dev) method. I tested it with > wireless only and with wired-only network. Now, everything should work as > expected for wireless and wired users - even then when no network is > detected/configured. > > I will post a patch soon Richard, I took the python book off the shelf and did some simple changes to isys.py until I had something that works. Then for the hell of it I plugged in a Huawei 3G USB key to see what happens and there were similar failures again. As 3G interfaces are now being built into notebooks it's probably worth the effort to get that bit right as well. My changes looked as if they were going to be good. It went through the process of copying the image onto the hard disk OK but just before the end it failed for the reason described below. The Huawei 3G key appears as a NetworkManager GSM device (and a ModemManager device) but NetworkManager does not export HardwareAddress for GSM or CDMA devices. I returned False when getMacAddress(dev) was called for it. Right at the end of the install process (according to the progress bar) various properties of the device are concatenated somewhere in network.py and it fails because it cannot concatenate a string and a boolean. Maybe instead of returning False I should have returned a dummy address like '00:00:00:00:00:00' Here is the new failure in network.py anaconda 13.42 exception report Traceback (most recent call first): File "/usr/lib/anaconda/network.py", line 259, in __str__ s = s + key + "=" + self.info[key] + "\n" File "/usr/lib/anaconda/network.py", line 578, in write f.write(str(dev)) File "/usr/sbin/anaconda", line 697, in write self.network.write(instPath=self.rootPath, anaconda=self) File "/usr/lib/anaconda/backend.py", line 313, in writeConfiguration anaconda.write() File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1313, in nextClicked self.anaconda.dispatch.gotoNext() File "/usr/lib/anaconda/iw/progress_gui.py", line 79, in renderCallback self.intf.icw.nextClicked() File "/usr/lib/anaconda/gui.py", line 1334, in handleRenderCallback self.currentWindow.renderCallback() TypeError: cannot concatenate 'str' and 'bool' objects Local variables in innermost frame: keys: ['HWADDR'] s: DEVICE=ttyUSB0 I have attached the code I used to get this far so you can see what I did. (Just new defines and changes to getMacAddress(dev) ) If it helps to see what the 3G card looks like with d-feet just let me know. I hope this helps... Going to bed now...
3G devices have no real hardware address because they are often not Ethernet-based devices, but operate on a higher layer with PPP. Enabling 3G devices in anaconda would be additional code beyond what's there already because of this. Not a ton if you're using NetworkManager + ModemManager, but enough. UI bits to ask for [APN, user, password] for GSM devices, and just user/password for CDMA devices. Next, we'd need to figure out how to put all that into ifcfg files and make NM able to read them, since we don't enable the NM 'keyfile' config plugin by default, and since ifcfg files can't yet express all the settings we need here (like APN). And then a few more things. Basically, all 3G devices need some setup and configuration above and beyond what anaconda code already does. So they won't "just work" unless a chunk of work is put into it.
For the sake of completeness of my previous post I am posting the modifications I have done to isys.py and network.py of Anaconda 12.46 and 13.42. During the update cycles of Fedora 12 and Fedora 13, dbus/NetworkManager were updated and somehow broke Anaconda. Since I am frequently creating new LiveCD spins, I rely on a working Anaconda so I created a patch to work around this issue. Anaconda 14.22, however, seems to work without the modifications I had to do on Anaconda 12.46 and 13.42. I have tested this patch with wireless devices as well as with a Sierra 3G modem device. My previous patch only covered wired and wireless devices while this new patch also takes care of GSM/CDMA devices but does not configure them. It seems to me a better approach implementing a workaround in anaconda instead of modifying dbus/NetworkManager.
Created attachment 460292 [details] Anaconda 12.46 patch for Wired/WIFI/GSM/CDMA
Created attachment 460294 [details] Anaconda 13.42 patch for Wired/WIFI/GSM/CDMA
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.