I upgraded from F13 to F13 using the installation DVD downloaded from http://mirrors.kernel.org/fedora/releases/14/Fedora/i386/iso/Fedora-14-i386-...
The checksum was good. I burned and booted with the DVD I burned, and I let Anaconda perform integrity check. All went well. I selected to upgrasde from the anaconda menu.
Upgrade went without a hitch (although, it took almost 14 hours!! to finish).
Upon reboot (into single user mode), I brought up the network - no problems there.
I then ran
yum -y update
And yum falls on it's face because it is unable to properly handle dependencies.
For example it funds updates for some particular dependency, but it is unable to resolve the problem of some other package depending on the dependency which it is trying to upgrade to a higher version.
So, yum gets stuck in a loop.
I have the output file saved.
I would like to attach that file, but in the past, the listserv has dumped my message because of an attachment.
Any suggestions?
On 03/29/2011 11:57 AM, JD wrote:
Upon reboot (into single user mode), I brought up the network - no problems there.
First, I presume you meant you went from F 13 to F 14. Second, did you actually boot into single-user mode (init 1) or simply a CLI instead of a GUI, which is init 3? I ask because not only doesn't init 1 have the network up (Yes, I know you wrote that you brought it up.) it also doesn't have a completely functional system. Among other things, the only partition mounted is /. Depending on what level you were in, and how your system is partitioned, it might make a difference. And, I must admit that I'm a tad concerned about why it took 14 hours for an upgrade from DVD. Please let us know exactly what you did when you rebooted, because which init level you were in may well have made a difference.
On 03/29/2011 12:10 PM, Joe Zeff wrote:
On 03/29/2011 11:57 AM, JD wrote:
Upon reboot (into single user mode), I brought up the network - no problems there.
First, I presume you meant you went from F 13 to F 14. Second, did you actually boot into single-user mode (init 1) or simply a CLI instead of a GUI, which is init 3? I ask because not only doesn't init 1 have the network up (Yes, I know you wrote that you brought it up.) it also doesn't have a completely functional system. Among other things, the only partition mounted is /. Depending on what level you were in, and how your system is partitioned, it might make a difference. And, I must admit that I'm a tad concerned about why it took 14 hours for an upgrade from DVD. Please let us know exactly what you did when you rebooted, because which init level you were in may well have made a difference.
I said: I rebooted into single user mode. I brought up the network without problems. i.e., in single user mode I ran service wpa_supplicant start service network start and I said: no problems there. By no problems, I meant: ping www.fedoraproject.com worked just fine!!
Which init level? I said I rebooted into single user mode!! If you do not know how to do that, you need to read the wiki.
JD <jd1008 <at> gmail.com> writes:
...
This is my cure-all medicine:
# yum-complete-transaction # yum clean all # yum distro-sync # yum check # package-cleanup --dupes | problems | orphans if any dupes or problems show up, show us the output; ignore orphans for now. # find /etc -iname "*.rpm*" and reconcile them if any # ldconfig -v # prelink -aR # reboot
Meltdown :-)
JB
On 03/29/2011 12:18 PM, JD wrote:
Which init level? I said I rebooted into single user mode!! If you do not know how to do that, you need to read the wiki.
Instead of getting hysterical and trying (unsuccessfully) to insult me, you might have noticed that I mentioned both init 1 and init 3. The reason I wanted to confirm which init level you were really in is because I couldn't be sure that *you* knew the difference. I've seen, both here and at fedoraforum.org, enough posts from people who thought that a CLI was "single user mode" that I don't assume that an unknown poster really was in init 1 without checking.
Now that we know that, the question becomes, "Why use single user mode for a yum update?" You could either have booted into text mode (init 3) or used Ctrl-Alt-F2 to get to a CLI after a normal boot, logged in as root and done the update there. Or, easiest of all, done a normal boot, logged in, started a terminal and used su. So: "Why use single user mode?"
On 03/29/2011 12:18 PM, JB wrote:
JD<jd1008<at> gmail.com> writes:
...
This is my cure-all medicine:
# yum-complete-transaction # yum clean all # yum distro-sync # yum check # package-cleanup --dupes | problems | orphans if any dupes or problems show up, show us the output; ignore orphans for now. # find /etc -iname "*.rpm*" and reconcile them if any # ldconfig -v # prelink -aR # reboot
Meltdown :-)
JB
Will this uninstall any packages I already have?
On 03/29/2011 12:36 PM, Joe Zeff wrote:
On 03/29/2011 12:18 PM, JD wrote:
Which init level? I said I rebooted into single user mode!! If you do not know how to do that, you need to read the wiki.
Instead of getting hysterical and trying (unsuccessfully) to insult me, you might have noticed that I mentioned both init 1 and init 3. The reason I wanted to confirm which init level you were really in is because I couldn't be sure that *you* knew the difference. I've seen, both here and at fedoraforum.org, enough posts from people who thought that a CLI was "single user mode" that I don't assume that an unknown poster really was in init 1 without checking.
Now that we know that, the question becomes, "Why use single user mode for a yum update?" You could either have booted into text mode (init 3) or used Ctrl-Alt-F2 to get to a CLI after a normal boot, logged in as root and done the update there. Or, easiest of all, done a normal boot, logged in, started a terminal and used su. So: "Why use single user mode?"
I am neither hysterical nor insulting. I merely thought that since you did not know that one can boot directly into single user mode, (i.e. without booting into the normal level 5, and then using a shell terminal to "sudo init s"), I thought you are probably a newbie, and thus suggested you read the wiki. Why is that an insult? And no, I did not do anything as you say in your second paragraph. So, keep you from guessing, please read http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/
Cheers,
JD
JD <jd1008 <at> gmail.com> writes:
On 03/29/2011 12:18 PM, JB wrote:
JD<jd1008<at> gmail.com> writes:
...
This is my cure-all medicine:
# yum-complete-transaction # yum clean all # yum distro-sync # yum check # package-cleanup --dupes | problems | orphans if any dupes or problems show up, show us the output; ignore orphans for now. # find /etc -iname "*.rpm*" and reconcile them if any # ldconfig -v # prelink -aR # reboot
Meltdown
JB
Will this uninstall any packages I already have?
The only entry of interest would be: # yum distro-sync
According to: $ man yum ... distribution-synchronization or distro-sync Synchronizes the installed package set with the latest packages available, this is done by either obsoleting, upgrading or down‐ grading as appropriate. This will "normally" do the same thing as the upgrade command however if you have the package FOO installed at version 4, and the latest available is only version 3, then this command will downgrade FOO to version 3.
This command does not perform operations on groups, local pack‐ ages or negative selections. ...
it may reshuffle some packages, but only for the good/integrity of the installation.
JB
On 03/29/2011 01:38 PM, JD wrote:
I merely thought that since you did not know that one can boot directly into single user mode, (i.e. without booting into the normal level 5, and then using a shell terminal to "sudo init s")
I not only know how to boot into single-user mode, I know how to do it from a CLI without using sudo, which I personally consider a pointless crutch on a home box. (If you've been on this list for more than a few days, you've seen my opinion on that.) I've been using Linux since *before* FC 1, and have been using Fedora as my main OS since F 9. You seem to be interested only in telling me how to boot into init 1, and ignoring the fact that I only wanted to make sure that you *really were* in single-user mode, not init 3. Now, instead of repeatedly trying to tell your grandfather how to suck eggs, try answering the question I asked in my last message: "Why were you using single-user mode?"
On 03/29/2011 01:55 PM, JB wrote:
JD<jd1008<at> gmail.com> writes:
On 03/29/2011 12:18 PM, JB wrote:
JD<jd1008<at> gmail.com> writes:
...
This is my cure-all medicine:
# yum-complete-transaction # yum clean all # yum distro-sync # yum check # package-cleanup --dupes | problems | orphans if any dupes or problems show up, show us the output; ignore orphans for now. # find /etc -iname "*.rpm*" and reconcile them if any # ldconfig -v # prelink -aR # reboot
Meltdown
JB
Will this uninstall any packages I already have?
The only entry of interest would be: # yum distro-sync
According to: $ man yum ... distribution-synchronization or distro-sync Synchronizes the installed package set with the latest packages available, this is done by either obsoleting, upgrading or down‐ grading as appropriate. This will "normally" do the same thing as the upgrade command however if you have the package FOO installed at version 4, and the latest available is only version 3, then this command will downgrade FOO to version 3.
This command does not perform operations on groups, local pack‐ ages or negative selections....
it may reshuffle some packages, but only for the good/integrity of the installation.
JB
I did that. I did update a lot of fc13 packages to fc14. But it still chocked on the dependencies that had other packages depending on the very dependencies it tries to update. Yum simply does not seem to be able to handle this chain of dependencies scenario. I consider it broken!
JD <jd1008 <at> gmail.com> writes:
... I did that. I did update a lot of fc13 packages to fc14. But it still chocked on the dependencies that had other packages depending on the very dependencies it tries to update. Yum simply does not seem to be able to handle this chain of dependencies scenario. I consider it broken!
I would execute this: # yum distro-sync
and post the full output (dependencies conflict, etc) to the list.
It would be interesting to see what yum can not handle. Perhaps there is something unusual we will be able to identify (before you decide what to do next: file a Bugzilla report, etc).
Also, I would double check the plugins with regard to packages update protections and their configurations. Or any exclusions, etc in your main yum config file.
JB
On Wednesday 30 March 2011 00:09:58 JD wrote:
Yum simply does not seem to be able to handle this chain of dependencies scenario. I consider it broken!
Use the --skip-broken parameter to see if the dependency resolution goes further.
FWIW the interplay between the packages that you have installed and those available in the repositories can be at fault and not yum.
On 03/29/2011 04:29 PM, JB wrote:
JD<jd1008<at> gmail.com> writes:
... I did that. I did update a lot of fc13 packages to fc14. But it still chocked on the dependencies that had other packages depending on the very dependencies it tries to update. Yum simply does not seem to be able to handle this chain of dependencies scenario. I consider it broken!
I would execute this: # yum distro-sync
and post the full output (dependencies conflict, etc) to the list.
It would be interesting to see what yum can not handle. Perhaps there is something unusual we will be able to identify (before you decide what to do next: file a Bugzilla report, etc).
Also, I would double check the plugins with regard to packages update protections and their configurations. Or any exclusions, etc in your main yum config file.
JB
That's what I meant when I said 'I did that' Sorry that I did not save the output.
It does take a long time and produces a list of what is "set to be installed" - but because it encounters errors with some packages and their dependencies, it does not install any of them.
What I have been doing is that for every dependency that causes conflicts, I uninstall the conflicting dependency and all packages that depend on it, and then I "yum install" them and that fixes the problem with that dependency. So, next time I do yum update, the problem with that specific dependency is gone and the new dependencies are installed. And on with the next conflict ...etc. So, it has been a rather slow and painful process to do things that yum should be doing for me.
On 03/29/2011 09:39 PM, José Matos wrote:
On Wednesday 30 March 2011 00:09:58 JD wrote:
Yum simply does not seem to be able to handle this chain of dependencies scenario. I consider it broken!
Use the --skip-broken parameter to see if the dependency resolution goes further.
FWIW the interplay between the packages that you have installed and those available in the repositories can be at fault and not yum.
Well, I had no such problems in fc13. How come that interplay did not cause conflicts in fc13?
And yes, --skip-broken does work as far as installing things that have no conflicts. But the conflicts remain and every time I run yum to install or update something, it belches out the report about broken packages.
On Wednesday 30 March 2011 06:27:41 JD wrote:
Well, I had no such problems in fc13. How come that interplay did not cause conflicts in fc13?
Because the repositories that you now using are from f14.
There could be several reason for the problems you see. One example, imagine that a package has been discontinued in f14. If you have that file installed from f13 yum will refuse to remove it, unless you tell it otherwise. The problem with this package is that it could drag the update process due its dependencies not being fulfilled in f14.
In order to fix issues like this you can search for this information that is usually available either in the release notes or in the fedora wiki.
And yes, --skip-broken does work as far as installing things that have no conflicts. But the conflicts remain and every time I run yum to install or update something, it belches out the report about broken packages.
When running yum with --skip-broken it prints a nice list of conflits and the related reason why it has failed. Walktrough those and fix the dependencies as apropriate.
On 03/29/2011 11:23 PM, José Matos wrote:
On Wednesday 30 March 2011 06:27:41 JD wrote:
Well, I had no such problems in fc13. How come that interplay did not cause conflicts in fc13?
Because the repositories that you now using are from f14.
There could be several reason for the problems you see. One example, imagine that a package has been discontinued in f14. If you have that file installed from f13 yum will refuse to remove it, unless you tell it otherwise. The problem with this package is that it could drag the update process due its dependencies not being fulfilled in f14.
In order to fix issues like this you can search for this information that is usually available either in the release notes or in the fedora wiki.
And yes, --skip-broken does work as far as installing things that have no conflicts. But the conflicts remain and every time I run yum to install or update something, it belches out the report about broken packages.
When running yum with --skip-broken it prints a nice list of conflits and the related reason why it has failed. Walktrough those and fix the dependencies as apropriate.
And that's exactly what I have resorted to. One broken package at a time :)