Fedora 9 Yum error: no id element found
Things are great when they work! Some recent change (around 11/14/2008) to the Yum Extender (or a change to some underlying component) caused it to ‘break’ – since there are quite a few users of this (very nice) package problem reports surfaced quickly (probably within hours or even minutes of the problem…)
If you are not using the Yum Extender then you are missing a great, simple GUI tool for adding and removing software from your Linux system. From the Gnome GUI you can use Add/Remove software to install it (Menu: System–> Administration–> Add Remove Software (search for ‘yum’ and then look for ‘Yum Extender graphical management tool’ in the results…)
Resolving this problem takes a few more steps than simply ‘updating’ since that is the purpose of Yum – if it ‘breaks’ then you can’t auto-update…
By using a somewhat long-tail query I found steps to a solution within the first few posts – search terms:
yum “no id element found”
The search hits provided a solution (manually update to a fixed version) but not a root cause for the problem (most likely a whoops! at some point – a common issue with free software.) The manual steps:
- start command shell – you need to login as the ’super-user’ (root) or make sure that you have appropriate permission to change system level software by using sudo/su
- change to a working folder (/tmp in this example)
- fetch the update OR most current package version (use the wget or some other command line web-file fetching tool – you could also use your browser)
- install the update using the rpm command
- clean-up (remove the package after the successful install, i.e. test yum and remove the .rpm file if all is well)
i.e. (CMD = from the shell, commands and arguments to use listed after ‘CMD:’)
CMD: su
CMD: cd /tmp
CMD: wget http://koji.fedoraproject.org/packages/yumex/2.0.5/3.fc9/noarch/yumex-2.0.5-3.fc9.noarch.rpm
CMD: rpm -Uvh yumex-2.0.5-3.fc9.noarch.rpm
CMD: rm -f yumex-2.0.5-3.fc9.noarch.rpm
This type of problem is really tough to avoid if you use any sort of auto-updating feature with your operating system (OS) or even with automatic application updates. If we did not have the convenience of search the problem solving steps would most likely involve a roll-back step (provided that you have something to roll-back to…) Hopefully, if you are running production systems you have configured them to NOT use auto-updating from external sources.
Consider configuring your productions systems to only update from a vetted source – one that you provide. Once you test (i.e. confirm that an update works as expected and does not introduce negative effects) then you make the update available. You can configure Yum to work in this manner, but of course, you must also provide a server to host your approved updates...
A final note – this type of issue also occurs with commercial software (although my expectation is that this sort of problem would/should be less likely to occur with commercial products); for an Open Source solution it is truly amazing how quickly an update was available and, through a long-tail search how quick/easy it was to locate the steps to a resolution. Hats off to the providers of the Yum Extender (and all other Open Source solutions.)
Related posts:
- SAMBA – mount error 113 = No route to host I had a working network setup with 3 machines (2 Linux boxes...
- VMware under Fedora 9 (not) It should be noted that VMware Server 2.0 does NOT...
- Fedora – sort of broken KSH When you write perfect shell scripts you expect them to...
- VMware under Fedora 8 Since the VMware install under Fedora 9 was problematic and...
- Open Solaris (VDI) under Fedora (FC9) using VirtualBox I get vendor emails on a daily basis - I...