Hi,
running the update from 17 to 18 failed after going 67% through, please see https://bugzilla.redhat.com/show_bug.cgi?id=972358 .
What can I do now so I'm not stuck with a mixture of 17 and 18?
On 06/08/2013 01:51 PM, lee wrote:
Hi,
running the update from 17 to 18 failed after going 67% through, please see https://bugzilla.redhat.com/show_bug.cgi?id=972358 .
What can I do now so I'm not stuck with a mixture of 17 and 18?
Have you tried yum-complete-transaction? If that doesn't work, what does /etc/fedora-release have in it? If it says you're running F 18, maybe distro-sync will work.
Joe Zeff joe@zeff.us writes:
On 06/08/2013 01:51 PM, lee wrote:
Hi,
running the update from 17 to 18 failed after going 67% through, please see https://bugzilla.redhat.com/show_bug.cgi?id=972358 .
What can I do now so I'm not stuck with a mixture of 17 and 18?
Have you tried yum-complete-transaction?
I tried and it has nothing to complete.
If that doesn't work, what does /etc/fedora-release have in it?
It says 18 but yum was still thinking it's 17. I managed to change out the fedora-release package so it _should_ be thinking it's 18 --- but I can't tell what it might think now.
If it says you're running F 18, maybe distro-sync will work.
It doesn't, says no packages are marked for sync.
It seems that I have now about 1355 packages from Fedora 17 installed which are dupes of packages from Fedora 18. Things aren't working because different versions of packages don't go together. Nothing can be updated or upgraded, and if I tried to remove the packages from 17, the system would probably crash even before they're all removed.
Is there any way to sort out this mess? If not, I'm done with Fedora. It has the big stamp "UNRELIABLE" on it now just like windoze, so there's no point in reinstalling. Having to reinstall all the time instead of being able to upgrade is not an option. What they call package management is totally broken.
I have updated the bug report, too: https://bugzilla.redhat.com/show_bug.cgi?id=972358
I give it until Tuesday and if it's not fixed by then, I'll install something else.
On Sat, 08 Jun 2013 22:51:52 +0200 lee lee@yun.yagibdah.de wrote:
Hi,
running the update from 17 to 18 failed after going 67% through, please see https://bugzilla.redhat.com/show_bug.cgi?id=972358 .
What can I do now so I'm not stuck with a mixture of 17 and 18?
Reboot with enforcing=0 on the kernel then at the command prompt sudo yum --releasever=18 distro-sync, it should restore all *.rpms to 18 release.
Frank Murphy frankly3d@gmail.com writes:
On Sat, 08 Jun 2013 22:51:52 +0200 lee lee@yun.yagibdah.de wrote:
Hi,
running the update from 17 to 18 failed after going 67% through, please see https://bugzilla.redhat.com/show_bug.cgi?id=972358 .
What can I do now so I'm not stuck with a mixture of 17 and 18?
Reboot with enforcing=0 on the kernel then at the command prompt sudo yum --releasever=18 distro-sync, it should restore all *.rpms to 18 release.
Same result, no packages marked for sync. It doesn't do anything and the packages from 17 remain installed along with the ones from 18.
Is there a way to get rid of the packages from 17 and to replace them with those from 18 without breaking anything? This is something the package management is supposed to take care of in the first place so a situation like this should never occur ...
lee lee@yun.yagibdah.de writes:
Frank Murphy frankly3d@gmail.com writes:
On Sat, 08 Jun 2013 22:51:52 +0200 lee lee@yun.yagibdah.de wrote:
Hi,
running the update from 17 to 18 failed after going 67% through, please see https://bugzilla.redhat.com/show_bug.cgi?id=972358 .
What can I do now so I'm not stuck with a mixture of 17 and 18?
Reboot with enforcing=0 on the kernel then at the command prompt sudo yum --releasever=18 distro-sync, it should restore all *.rpms to 18 release.
Same result, no packages marked for sync. It doesn't do anything and the packages from 17 remain installed along with the ones from 18.
Is there a way to get rid of the packages from 17 and to replace them with those from 18 without breaking anything? This is something the package management is supposed to take care of in the first place so a situation like this should never occur ...
Hmm, I could do
package-cleanup --dupes | grep fc17 | xargs yum remove
... but how do I know if essential packages are being removed that way? At least what yum says looks good as in that there don't seem to be any packages from 18 removed that way, and I'd get rid of 1289 packages.
On Sun, 09 Jun 2013 21:20:30 +0200 lee lee@yun.yagibdah.de wrote:
Hmm, I could do
package-cleanup --dupes | grep fc17 | xargs yum remove
... but how do I know if essential packages are being removed that way? At least what yum says looks good as in that there don't seem to be any packages from 18 removed that way, and I'd get rid of 1289 packages.
You likely want 'package-cleanup --cleandupes' instead.
That will remove the older of any duplicate package.
kevin
Kevin Fenzi kevin@scrye.com writes:
On Sun, 09 Jun 2013 21:20:30 +0200 lee lee@yun.yagibdah.de wrote:
Hmm, I could do
package-cleanup --dupes | grep fc17 | xargs yum remove
... but how do I know if essential packages are being removed that way? At least what yum says looks good as in that there don't seem to be any packages from 18 removed that way, and I'd get rid of 1289 packages.
You likely want 'package-cleanup --cleandupes' instead.
That will remove the older of any duplicate package.
Ah hm, I've done the above and removed some other packages that don't seem to be needed anymore. Let me try cleandupes ...
Dupes are all gone now, it didn't find any. I have orphaned packages:
,---- | [root@yun ~]# package-cleanup --orphan |grep fc17 | NetworkManager-gtk-0.9.6.4-3.fc17.x86_64 | a52dec-0.7.4-16.fc17.x86_64 | ar9170-firmware-2009.05.28-4.fc17.noarch | db4-4.8.30-10.fc17.x86_64 | eject-2.1.5-22.fc17.x86_64 | faac-1.28-4.fc17.x86_64 | faad2-libs-2.7-2.fc17.x86_64 | kernel-3.7.9-104.fc17.x86_64 | kernel-3.8.4-102.fc17.x86_64 | kernel-3.8.13-100.fc17.x86_64 | kernel-devel-3.7.9-104.fc17.x86_64 | kernel-devel-3.8.4-102.fc17.x86_64 | kernel-devel-3.8.13-100.fc17.x86_64 | kernel-headers-3.8.13-100.fc17.x86_64 | kmod-nvidia-3.7.9-104.fc17.x86_64-304.64-7.fc17.8.x86_64 | kmod-nvidia-3.8.13-100.fc17.x86_64-304.88-1.fc17.7.x86_64 | kmod-nvidia-3.8.4-102.fc17.x86_64-304.88-1.fc17.x86_64 | libdca-0.0.5-6.fc17.x86_64 | libdvbpsi-0.2.2-2.fc17.x86_64 | libmimic-1.0.4-5.fc17.x86_64 | libmpeg2-0.5.1-9.fc17.x86_64 | librtmp-2.4-0.2.20110811gitc58cfb3e.fc17.x86_64 | libusb1-1.0.9-0.6.rc1.fc17.x86_64 | mesa-dri-filesystem-8.0.4-1.fc17.x86_64 | nc-1.109.20120711-1.fc17.x86_64 | procps-3.2.8-28.20110302git.fc17.x86_64 | samba4-libs-4.0.0-60alpha18.fc17.x86_64 | smolt-1.4.3-6.fc17.noarch | smolt-firstboot-1.4.3-6.fc17.noarch | system-config-network-tui-1.6.5-1.fc17.noarch | system-setup-keyboard-0.8.8-2.fc17.x86_64 | twolame-libs-0.3.13-2.fc17.x86_64 | udev-182-3.fc17.x86_64 | xvidcore-1.3.2-3.fc17.x86_64 | [root@yun ~]# `----
When I attempt remove these, yum wants to remove packages from 18 as well due to dependencies. Are there packages in 18 that depend on packages from 17, and why would that be?
The list is quite a bit longer when not limiting it to packages from 17, but I guess that's because packages are listed no other packages depend on.
What can I do about the packages that remain from 17 now? Go through them one by one and see what happens when attempting to remove them?
Services that didn't work anymore are now working again. I haven't rebooted yet after removing packages, though.
Oh and I moved the repo files for rpmfusion out of the way because that all seemed to refer to Fedora 17 instead of 18. IIRC I need those (at least) for the NVIDIA driver. What do I need to do about those?
,---- | [root@yun ~]# ls -la /etc/yum.repos.d/ | total 28 | drwxr-xr-x. 2 root root 4096 Jun 9 18:11 . | drwxr-xr-x. 146 root root 12288 Jun 9 21:37 .. | -rw-r--r--. 1 root root 1145 Dec 20 06:21 fedora.repo | -rw-r--r--. 1 root root 1105 Dec 20 06:21 fedora-updates.repo | -rw-r--r--. 1 root root 1163 Dec 20 06:21 fedora-updates-testing.repo | [root@yun ~]# `----
On Sun, Jun 9, 2013 at 1:29 PM, lee lee@yun.yagibdah.de wrote:
Ah hm, I've done the above and removed some other packages that don't seem to be needed anymore. Let me try cleandupes ...
Dupes are all gone now, it didn't find any. I have orphaned packages:
<snip list>
I wouldn't worry about these. A package being "orphaned" just means that you didn't manually install them and they are no longer required as a dependency of anything else. In fact, the mechanism yum uses to track these might be confused by the partial upgrade. There are some rather important packages in that list you probably don't want to remove listed there, such as NetworkManager for instance.
When I attempt remove these, yum wants to remove packages from 18 as well due to dependencies. Are there packages in 18 that depend on packages from 17, and why would that be?
That's not quite what's happening. You have a lot of packages on your system that are still at the F17 version, and that version just happens to satisfy the dependencies of F18 packages just fine. They would be equally happy if a F18 version took their place.
The list is quite a bit longer when not limiting it to packages from 17, but I guess that's because packages are listed no other packages depend on.
What can I do about the packages that remain from 17 now? Go through them one by one and see what happens when attempting to remove them?
As I said previously, you probably really want to keep these packages; you just need to get them updated to F18. If we can fix distro-sync, we can fix this.
Services that didn't work anymore are now working again. I haven't rebooted yet after removing packages, though.
Oh and I moved the repo files for rpmfusion out of the way because that all seemed to refer to Fedora 17 instead of 18. IIRC I need those (at least) for the NVIDIA driver. What do I need to do about those?
Hmm, the RPMFusion .repo files as installed by rpmfusion-(non)free-release don't hardcode the distribution version; they use $releasever to have yum figure it out for them. Did you see the number "17" in the rpmfusion-*.repo files themselves, or did yum report this? If yum is confused about the version of Fedora you are using that could explain why distro-sync is acting up.
-T.C.
"T.C. Hollingsworth" tchollingsworth@gmail.com writes:
On Sun, Jun 9, 2013 at 1:29 PM, lee lee@yun.yagibdah.de wrote:
Ah hm, I've done the above and removed some other packages that don't seem to be needed anymore. Let me try cleandupes ...
Dupes are all gone now, it didn't find any. I have orphaned packages:
<snip list>
I wouldn't worry about these. A package being "orphaned" just means that you didn't manually install them and they are no longer required as a dependency of anything else. In fact, the mechanism yum uses to track these might be confused by the partial upgrade. There are some rather important packages in that list you probably don't want to remove listed there, such as NetworkManager for instance.
How can they be orphaned when there are packages that depend on them?
Network manager is actually obsolete, it's only there because of messed up dependencies, i. e. too many packages depending on it without any of them needing it.
When I attempt remove these, yum wants to remove packages from 18 as well due to dependencies. Are there packages in 18 that depend on packages from 17, and why would that be?
That's not quite what's happening. You have a lot of packages on your system that are still at the F17 version, and that version just happens to satisfy the dependencies of F18 packages just fine. They would be equally happy if a F18 version took their place.
Not really a lot anymore, I hope?
The list is quite a bit longer when not limiting it to packages from 17, but I guess that's because packages are listed no other packages depend on.
What can I do about the packages that remain from 17 now? Go through them one by one and see what happens when attempting to remove them?
As I said previously, you probably really want to keep these packages; you just need to get them updated to F18. If we can fix distro-sync, we can fix this.
Ok how do we fix distro-sync then? I don't want to have any such problems as I had now when updating to the next release --- and I will have a Gentoo or arch installer ready before starting to update in case it doesn't work again.
Services that didn't work anymore are now working again. I haven't rebooted yet after removing packages, though.
Oh and I moved the repo files for rpmfusion out of the way because that all seemed to refer to Fedora 17 instead of 18. IIRC I need those (at least) for the NVIDIA driver. What do I need to do about those?
Hmm, the RPMFusion .repo files as installed by rpmfusion-(non)free-release don't hardcode the distribution version; they use $releasever to have yum figure it out for them. Did you see the number "17" in the rpmfusion-*.repo files themselves, or did yum report this?
IIRC, I followed some instructions to install NVIDIA drivers which involved adding the rpmfusion repo. Is there a Fedora package to add this repo which provids these files?
If yum is confused about the version of Fedora you are using that could explain why distro-sync is acting up.
It shouldn't be confused anymore. When I figured out that it seems to be confused, I tried to make it assume that this is Fedora 18 now by removing the fedora-release package from 17 and reinstalling the fedora-release package from 18 after finding [1] and another post somewhere that pointed out that there is such a package. I didn't want to change the variables mentioned in [1] in yum.conf, and the fedora-release package seemed to fix the problem.
Now when install a package, the package from 18 gets installed. However, I have now the two directories, "17" and "18", in /var/cache/yum/x86_64/. Shouldn't that somehow be cleaned?
[1]: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
On Mon, 10 Jun 2013 15:43:10 +0200 lee lee@yun.yagibdah.de wrote: d the fedora-release package seemed to fix the problem.
Now when install a package, the package from 18 gets installed. However, I have now the two directories, "17" and "18", in /var/cache/yum/x86_64/. Shouldn't that somehow be cleaned?
I have found, the 17 will not get cleaned unless you do: yum --releasever=17 clean all. As that is where a "17" release would store it's cache and yum metadata
Am 10.06.2013 16:45, schrieb Frank Murphy:
On Mon, 10 Jun 2013 15:43:10 +0200 lee lee@yun.yagibdah.de wrote: d the fedora-release package seemed to fix the problem.
Now when install a package, the package from 18 gets installed. However, I have now the two directories, "17" and "18", in /var/cache/yum/x86_64/. Shouldn't that somehow be cleaned?
I have found, the 17 will not get cleaned unless you do: yum --releasever=17 clean all. As that is where a "17" release would store it's cache and yum metadata
that is why i do "rm -rf /var/cache/yum/*" since years before dist-upgrades and after *every time* i used "--releasever=" wich a changed param
Reindl Harald h.reindl@thelounge.net writes:
Am 10.06.2013 16:45, schrieb Frank Murphy:
On Mon, 10 Jun 2013 15:43:10 +0200 lee lee@yun.yagibdah.de wrote: d the fedora-release package seemed to fix the problem.
Now when install a package, the package from 18 gets installed. However, I have now the two directories, "17" and "18", in /var/cache/yum/x86_64/. Shouldn't that somehow be cleaned?
I have found, the 17 will not get cleaned unless you do: yum --releasever=17 clean all. As that is where a "17" release would store it's cache and yum metadata
that is why i do "rm -rf /var/cache/yum/*" since years before dist-upgrades and after *every time* i used "--releasever=" wich a changed param
Sounds good, but I don't know if that might remove files which are still needed ...
Am 11.06.2013 01:15, schrieb lee:>> that is why i do "rm -rf /var/cache/yum/*" since years
before dist-upgrades and after *every time* i used "--releasever=" wich a changed param
Sounds good, but I don't know if that might remove files which are still needed...
there are no files needed in /var/cache/yum otherwise a blank install would not work and all my test and production servers would be damaged since years
cache is what it is - a cache
Reindl Harald h.reindl@thelounge.net writes:
Am 11.06.2013 01:15, schrieb lee:>> that is why i do "rm -rf /var/cache/yum/*" since years
before dist-upgrades and after *every time* i used "--releasever=" wich a changed param
Sounds good, but I don't know if that might remove files which are still needed...
there are no files needed in /var/cache/yum otherwise a blank install would not work and all my test and production servers would be damaged since years
cache is what it is - a cache
It seems to be fine with the cache from 17 moved out of the way :)
One question that just occurred to me when looking at [1]: Do I need to do anything about grub? Yum says the version from Fedora 18 is installed, so I should be fine?
[1]: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum
Am 11.06.2013 23:39, schrieb lee:
One question that just occurred to me when looking at [1]: Do I need to do anything about grub? Yum says the version from Fedora 18 is installed, so I should be fine?
the grub-configuration abd grub itself in the MBR is usally not touch at upgrades which is good because it is usually harmless having an older bootloader and people who cae cna update it any time - the bootloader is very critical and i would not have much fun if it would be automatically updated and possibly breaks
man grub2-mkconfig man grub2-install
which are both different things one geneartes the config and one installs the current version in the MBR
Reindl Harald h.reindl@thelounge.net writes:
Am 11.06.2013 23:39, schrieb lee:
One question that just occurred to me when looking at [1]: Do I need to do anything about grub? Yum says the version from Fedora 18 is installed, so I should be fine?
the grub-configuration abd grub itself in the MBR is usally not touch at upgrades which is good because it is usually harmless having an older bootloader and people who cae cna update it any time
Ok, but the grub package from 17 isn't installed anymore, and I didn't do anything about it. It seems like fedup might have replaced it automatically --- or the new grub is only installed as a package and the old one is still being used because it wasn't updated.
Am 12.06.2013 08:49, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
Am 11.06.2013 23:39, schrieb lee:
One question that just occurred to me when looking at [1]: Do I need to do anything about grub? Yum says the version from Fedora 18 is installed, so I should be fine?
the grub-configuration abd grub itself in the MBR is usally not touch at upgrades which is good because it is usually harmless having an older bootloader and people who cae cna update it any time
Ok, but the grub package from 17 isn't installed anymore, and I didn't do anything about it. It seems like fedup might have replaced it automatically --- or the new grub is only installed as a package and the old one is still being used because it wasn't updated
what is installd as package is one thing, what lives in the MBR is a different story - at boot time you see the GRUB version on top of the boot menu (press some key or whatever, AFAIK they managed to hidfe it from new users)
P.S.: you do not see my posts because i am moderated nd hey they had no problem yesterday to reject a post but release poosts is done at the next weekend or monday.....
Allegedly, on or about 11 June 2013, lee sent:
Sounds good, but I don't know if that might remove files which are still needed ...
Nothing should need to be kept in the cache, if anything is needed in the future, it will be redownloaded.
Frank Murphy frankly3d@gmail.com writes:
On Mon, 10 Jun 2013 15:43:10 +0200 lee lee@yun.yagibdah.de wrote: d the fedora-release package seemed to fix the problem.
Now when install a package, the package from 18 gets installed. However, I have now the two directories, "17" and "18", in /var/cache/yum/x86_64/. Shouldn't that somehow be cleaned?
I have found, the 17 will not get cleaned unless you do: yum --releasever=17 clean all. As that is where a "17" release would store it's cache and yum metadata
Thank you! Is that supposed to remove all files and directories under /var/cache/yum/x86_64/17/? I tried it and there are still files and directories there.
On Mon, Jun 10, 2013 at 6:43 AM, lee lee@yun.yagibdah.de wrote:
"T.C. Hollingsworth" tchollingsworth@gmail.com writes:
On Sun, Jun 9, 2013 at 1:29 PM, lee lee@yun.yagibdah.de wrote:
Ah hm, I've done the above and removed some other packages that don't seem to be needed anymore. Let me try cleandupes ...
Dupes are all gone now, it didn't find any. I have orphaned packages:
<snip list>
I wouldn't worry about these. A package being "orphaned" just means that you didn't manually install them and they are no longer required as a dependency of anything else. In fact, the mechanism yum uses to track these might be confused by the partial upgrade. There are some rather important packages in that list you probably don't want to remove listed there, such as NetworkManager for instance.
How can they be orphaned when there are packages that depend on them?
My apologies, I confused "orphans" with "leaves". Orphans are packages yum can't find in the repos.
A number of the packages are from RPMFusion and are only showing here because the RPMFusion repos aren't enabled, thus making them orphans as far as yum is concerned.
Others look like some packages didn't get obsoleted correctly. For instance, procps should have been replaced by procps-ng. Do you have a "procps-ng" package installed on your system?
A few might be true orphans, and are no longer shipped with the package collection.
Network manager is actually obsolete, it's only there because of messed up dependencies, i. e. too many packages depending on it without any of them needing it.
When I attempt remove these, yum wants to remove packages from 18 as well due to dependencies. Are there packages in 18 that depend on packages from 17, and why would that be?
That's not quite what's happening. You have a lot of packages on your system that are still at the F17 version, and that version just happens to satisfy the dependencies of F18 packages just fine. They would be equally happy if a F18 version took their place.
Not really a lot anymore, I hope?
Yeah, how bad is it? Maybe distro-sync isn't working because you've already fixed it mostly? What does `rpm -qa *fc17*` say?
Does a regular `yum update` do anything? Does it attempt to "replace" a bunch of packages with packages with a different name?
The list is quite a bit longer when not limiting it to packages from 17, but I guess that's because packages are listed no other packages depend on.
What can I do about the packages that remain from 17 now? Go through them one by one and see what happens when attempting to remove them?
As I said previously, you probably really want to keep these packages; you just need to get them updated to F18. If we can fix distro-sync, we can fix this.
Ok how do we fix distro-sync then? I don't want to have any such problems as I had now when updating to the next release --- and I will have a Gentoo or arch installer ready before starting to update in case it doesn't work again.
Services that didn't work anymore are now working again. I haven't rebooted yet after removing packages, though.
Oh and I moved the repo files for rpmfusion out of the way because that all seemed to refer to Fedora 17 instead of 18. IIRC I need those (at least) for the NVIDIA driver. What do I need to do about those?
Hmm, the RPMFusion .repo files as installed by rpmfusion-(non)free-release don't hardcode the distribution version; they use $releasever to have yum figure it out for them. Did you see the number "17" in the rpmfusion-*.repo files themselves, or did yum report this?
IIRC, I followed some instructions to install NVIDIA drivers which involved adding the rpmfusion repo. Is there a Fedora package to add this repo which provids these files?
To get the NVidia drivers and other packages from RPMFusion you need to install the rpmfusion-free-release and rpmfusion-nonfree-release packages as explained here: http://rpmfusion.org/Configuration
If yum is confused about the version of Fedora you are using that could explain why distro-sync is acting up.
It shouldn't be confused anymore. When I figured out that it seems to be confused, I tried to make it assume that this is Fedora 18 now by removing the fedora-release package from 17 and reinstalling the fedora-release package from 18 after finding [1] and another post somewhere that pointed out that there is such a package. I didn't want to change the variables mentioned in [1] in yum.conf, and the fedora-release package seemed to fix the problem.
Yeah, your `yum repolist` output indicates that yum thinks you're on the right version.
Now when install a package, the package from 18 gets installed. However, I have now the two directories, "17" and "18", in /var/cache/yum/x86_64/. Shouldn't that somehow be cleaned?
You can delete this manually, but it should be harmless.
-T.C.
"T.C. Hollingsworth" tchollingsworth@gmail.com writes:
On Mon, Jun 10, 2013 at 6:43 AM, lee lee@yun.yagibdah.de wrote:
"T.C. Hollingsworth" tchollingsworth@gmail.com writes:
On Sun, Jun 9, 2013 at 1:29 PM, lee lee@yun.yagibdah.de wrote:
Ah hm, I've done the above and removed some other packages that don't seem to be needed anymore. Let me try cleandupes ...
Dupes are all gone now, it didn't find any. I have orphaned packages:
<snip list>
I wouldn't worry about these. A package being "orphaned" just means that you didn't manually install them and they are no longer required as a dependency of anything else. In fact, the mechanism yum uses to track these might be confused by the partial upgrade. There are some rather important packages in that list you probably don't want to remove listed there, such as NetworkManager for instance.
How can they be orphaned when there are packages that depend on them?
My apologies, I confused "orphans" with "leaves". Orphans are packages yum can't find in the repos.
A number of the packages are from RPMFusion and are only showing here because the RPMFusion repos aren't enabled, thus making them orphans as far as yum is concerned.
Yes, that would make sense.
Others look like some packages didn't get obsoleted correctly. For instance, procps should have been replaced by procps-ng. Do you have a "procps-ng" package installed on your system?
,---- | [root@yun etc]# yum list installed |grep procps | procps.x86_64 3.2.8-28.20110302git.fc17 installed | procps-ng.x86_64 3.3.3-4.20120807git.fc18 installed `----
I'll remove the one from 17 ...
A few might be true orphans, and are no longer shipped with the package collection.
Network manager is actually obsolete, it's only there because of messed up dependencies, i. e. too many packages depending on it without any of them needing it.
When I attempt remove these, yum wants to remove packages from 18 as well due to dependencies. Are there packages in 18 that depend on packages from 17, and why would that be?
That's not quite what's happening. You have a lot of packages on your system that are still at the F17 version, and that version just happens to satisfy the dependencies of F18 packages just fine. They would be equally happy if a F18 version took their place.
Not really a lot anymore, I hope?
Yeah, how bad is it? Maybe distro-sync isn't working because you've already fixed it mostly? What does `rpm -qa *fc17*` say?
,---- | [root@yun etc]# rpm -qa *fc17* | kmod-nvidia-3.8.13-100.fc17.x86_64-304.88-1.fc17.7.x86_64 | kmod-nvidia-3.7.9-104.fc17.x86_64-304.64-7.fc17.8.x86_64 | kmod-nvidia-3.8.4-102.fc17.x86_64-304.88-1.fc17.x86_64 `----
They are probably not needed.
,---- | [~] yum list installed |grep kmod-nvidia | akmod-nvidia.x86_64 1:304.88-1.fc18 installed | kmod-nvidia.x86_64 1:304.88-1.fc18.10 installed | kmod-nvidia-3.7.9-104.fc17.x86_64.x86_64 | kmod-nvidia-3.8.13-100.fc17.x86_64.x86_64 | kmod-nvidia-3.8.4-102.fc17.x86_64.x86_64 | kmod-nvidia-3.9.4-200.fc18.x86_64.x86_64 | [~] `----
Hm, not sure what to do about these.
Does a regular `yum update` do anything? Does it attempt to "replace" a bunch of packages with packages with a different name?
It says "No Packages marked for Update".
IIRC, I followed some instructions to install NVIDIA drivers which involved adding the rpmfusion repo. Is there a Fedora package to add this repo which provids these files?
To get the NVidia drivers and other packages from RPMFusion you need to install the rpmfusion-free-release and rpmfusion-nonfree-release packages as explained here: http://rpmfusion.org/Configuration
Cool, I got those now :) Doesn't seem to change anything atm, though.
Now when install a package, the package from 18 gets installed. However, I have now the two directories, "17" and "18", in /var/cache/yum/x86_64/. Shouldn't that somehow be cleaned?
You can delete this manually, but it should be harmless.
Ok, I'll move the cache for 17 out of the way. Then I'll go through the orphaned packages and see if I can remove them ...
Now all the orphaned packages are gone, except for one which I installed myself and need to keep. There are a few leaves, all from 18, which probably is also ok because I might have installed some to be able to compile stuff. And package-cleanup doesn't find any problems, either.
Some packages from 17 are still installed. I tried to remove two of them and there are packages of Fedora 18 depending on them. There doesn't seem to be a replacement in 18 --- for example, there's a package called agg-2.5-13.fc17.x86_64, and both gnash-1:0.8.10-4.fc18 and gnash-plugin-1:0.8.10-4.fc18 would also be removed.
So when someone installs Fedora 18, they will have to remain without gnash because required packages are missing in 18? Or what does this mean?
On Sun, 09 Jun 2013 22:29:37 +0200 lee lee@yun.yagibdah.de wrote:
When I attempt remove these, yum wants to remove packages from 18 as well due to dependencies. Are there packages in 18 that depend on packages from 17, and why would that be?
Not all pkgs marked *fc17* are from Fedora 17, there can be a number of them from Fedora\rpmfusion 18 repos particularly rpmfusion.
How many kernels do you keep, cat /etc/yum.conf? installonly_limit=? When in doubt do not touch.
Frank Murphy frankly3d@gmail.com writes:
On Sun, 09 Jun 2013 22:29:37 +0200 lee lee@yun.yagibdah.de wrote:
When I attempt remove these, yum wants to remove packages from 18 as well due to dependencies. Are there packages in 18 that depend on packages from 17, and why would that be?
Not all pkgs marked *fc17* are from Fedora 17, there can be a number of them from Fedora\rpmfusion 18 repos particularly rpmfusion.
Then how do I know which ones are from 17 and which ones are from 18? I could assume that the ones labled fc17 might go away over time when they are replaced with more recent versions --- but for all I know, that might never happen.
How many kernels do you keep, cat /etc/yum.conf? installonly_limit=?
installonly_limit=3
When in doubt do not touch.
Kernels seem ok, there aren't many kept. I only reboot when a software update seems to require it or lets it seem advisable, so I don't really know --- three seems about right.
On Sun, Jun 9, 2013 at 11:34 AM, lee lee@yun.yagibdah.de wrote:
Same result, no packages marked for sync. It doesn't do anything and the packages from 17 remain installed along with the ones from 18.
Hmm, maybe your repository configuration is still unhappy? What does `yum repolist` say?
Also, you could try a `yum clean all` and retry it; perhaps there's some stale data screwing up the works.
Are you using a F17 yum/rpm or an F18 yum/rpm? (`rpm -q yum rpm` will tell you.) A mixture of these could also be causing issues.
Is there a way to get rid of the packages from 17 and to replace them with those from 18 without breaking anything?
This is exactly what `yum distro-sync` is supposed to do. Figuring out why it's unhappy is the first step to getting your system back into working order.
This is something the package management is supposed to take care of in the first place so a situation like this should never occur ...
I'm not aware of any package manager that doesn't have issues like these from time to time. dpkg/apt aren't any better; I've seen Debian and Ubuntu upgrades go south and leave the system in an inconsistent state too.
Remember, Murphy's Law always applies. ;-)
-T.C.
"T.C. Hollingsworth" tchollingsworth@gmail.com writes:
On Sun, Jun 9, 2013 at 11:34 AM, lee lee@yun.yagibdah.de wrote:
Same result, no packages marked for sync. It doesn't do anything and the packages from 17 remain installed along with the ones from 18.
Hmm, maybe your repository configuration is still unhappy? What does `yum repolist` say?
,---- | [~] yum repolist | Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit, remove- | : with-leaves, show-leaves | Loading mirror speeds from cached hostfile | * fedora: fedora.mirror.root.lu | * updates: ftp.uni-siegen.de | repo id repo name status | fedora/18/x86_64 Fedora 18 - x86_64 33,868 | updates/18/x86_64 Fedora 18 - x86_64 - Updates 15,538 | repolist: 49,406 | [~] `----
Also, you could try a `yum clean all` and retry it; perhaps there's some stale data screwing up the works.
I tried 'yum clean all' a few times and it didn't make any difference.
Are you using a F17 yum/rpm or an F18 yum/rpm? (`rpm -q yum rpm` will tell you.) A mixture of these could also be causing issues.
,---- | [~] rpm -q yum rpm | yum-3.4.3-54.fc18.noarch | rpm-4.10.3.1-1.fc18.x86_64 | [~] `----
Is there a way to get rid of the packages from 17 and to replace them with those from 18 without breaking anything?
This is exactly what `yum distro-sync` is supposed to do. Figuring out why it's unhappy is the first step to getting your system back into working order.
Maybe there's nothing to sync because yum figures this is Fedora 18?
This is something the package management is supposed to take care of in the first place so a situation like this should never occur ...
I'm not aware of any package manager that doesn't have issues like these from time to time. dpkg/apt aren't any better; I've seen Debian and Ubuntu upgrades go south and leave the system in an inconsistent state too.
I've been using Debian for 15 years or so and never had an update fail. Then when they messed up so badly with their brokenarch, I switched to Fedora. However, I avoided dist upgrades by running testing after finding out that it's easier to go in little steps than to make a more or less big leap from one stable release to the next. Over time, another advantage showed: Too much of the software in stable was ancient.
Remember, Murphy's Law always applies. ;-)
Well, look at pages like [1] and think about what kind of update procedure they came up with:
+ contradictory information about how to update + using the recommended method fails miserably + alternative methods don't work at all + there is no information at all available what to do when the update fails + the user is required to fix a bug in the recommended update software + the recommended method can finally be tried again + the recommended method fails miserably again + the user is forced to spend hours trying to fix problems + what he's trying can very well leave him with an unusable system + even if the problems can be mostly solved, the next update is likely to fail miserably again + the user has classified Fedora as unreliable and will not recommend it to others anymore, at least not without a big warning + the user would have switched to another distribution if that wasn't so much work and if they didn't need a working system NOW and not after a week or so + if it doesn't work next time, the user is forced to switch + the user doesn't dare to reboot because the system might not start
What kind of update procedure is that? Sure things can go wrong and not everything can be foreseen when testing the update procedure, but a total failure like that simply must not happen. That it can means that they need to rethink their update procedure and design it in such a way that it can't happen, or it needs a way to roll back.
[1]: http://fedoraproject.org/wiki/User_base
Am 10.06.2013 16:34, schrieb lee:
This is exactly what `yum distro-sync` is supposed to do. Figuring out why it's unhappy is the first step to getting your system back into working order.
Maybe there's nothing to sync because yum figures this is Fedora 18?
distro-sync does not care if it is Fedora 18
hecne the releasever=18 is only to switch to a specific repo version and ignore /etc/redhat-release and that is why you should "yum clean all" before use it to get rid of old metainfos ending up in a mix
distro-sync is supposed to upgrade/downgrade all packages to the exact versions in the online-repos and in case you had updates-testing enabled as example the way to go to revert this in a predictable way
Reindl Harald h.reindl@thelounge.net writes:
Am 10.06.2013 16:34, schrieb lee:
This is exactly what `yum distro-sync` is supposed to do. Figuring out why it's unhappy is the first step to getting your system back into working order.
Maybe there's nothing to sync because yum figures this is Fedora 18?
distro-sync does not care if it is Fedora 18
hecne the releasever=18 is only to switch to a specific repo version and ignore /etc/redhat-release and that is why you should "yum clean all" before use it to get rid of old metainfos ending up in a mix
distro-sync is supposed to upgrade/downgrade all packages to the exact versions in the online-repos and in case you had updates-testing enabled as example the way to go to revert this in a predictable way
Ok, let's try this:
,---- | [root@yun etc]# yum clean all | [root@yun etc]# yum distro-sync | [...] | No Packages marked for Distribution Synchronization | [root@yun etc]# `----
It's always been saying that, so I doubt that this acutally syncs.
,---- | [root@yun etc]# yum list installed |grep fc17 | NetworkManager-gtk.x86_64 1:0.9.6.4-3.fc17 installed | [...] `----
For example, is this version of networkmanager-gtk in Fedora 18? This package is not installed in a version labled fc18. So I guess I could remove it, but why doesn't distro-sync do that?
Now I removed it, without any dependencies showing up, so it's kinda obvious that it shouldn't be installed anymore, and distro-sync should have removed it already.
,---- | [root@yun etc]# yum list available "NetworkManager-gtk*" | [...] | Error: No matching Packages to list `----
So what's distro-sync doing?
Am 11.06.2013 01:43, schrieb lee:> Reindl Harald h.reindl@thelounge.net writes:
distro-sync is supposed to upgrade/downgrade all packages to the exact versions in the online-repos and in case you had updates-testing enabled as example the way to go to revert this in a predictable way
Ok, let's try this:
,---- | [root@yun etc]# yum clean all | [root@yun etc]# yum distro-sync | [...] | No Packages marked for Distribution Synchronization | [root@yun etc]# `----
It's always been saying that, so I doubt that this acutally syncs.
,---- | [root@yun etc]# yum list installed |grep fc17 | NetworkManager-gtk.x86_64 1:0.9.6.4-3.fc17 installed | [...] `----
For example, is this version of networkmanager-gtk in Fedora 18?
there is no "networkmanager-gtk" at all in Fedora 18 and that is what is called orphan
[root@srv-rhsoft:~]$ yum install NetworkManager-gtk No package NetworkManager-gtk available. Error: Nothing to do
[root@srv-rhsoft:~]$ rpm -qa | grep -i networkmanager NetworkManager-glib-0.9.8.2-1.fc18.x86_64
Reindl Harald h.reindl@thelounge.net writes:
Am 11.06.2013 01:43, schrieb lee:> Reindl Harald h.reindl@thelounge.net writes:
distro-sync is supposed to upgrade/downgrade all packages to the exact versions in the online-repos and in case you had updates-testing enabled as example the way to go to revert this in a predictable way
Ok, let's try this:
,---- | [root@yun etc]# yum clean all | [root@yun etc]# yum distro-sync | [...] | No Packages marked for Distribution Synchronization | [root@yun etc]# `----
It's always been saying that, so I doubt that this acutally syncs.
,---- | [root@yun etc]# yum list installed |grep fc17 | NetworkManager-gtk.x86_64 1:0.9.6.4-3.fc17 installed | [...] `----
For example, is this version of networkmanager-gtk in Fedora 18?
there is no "networkmanager-gtk" at all in Fedora 18 and that is what is called orphan
It seems so --- the question is why aren't such packages removed by yum distro-sync?
Am 11.06.2013 04:10, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
| [root@yun etc]# yum list installed |grep fc17 | NetworkManager-gtk.x86_64 1:0.9.6.4-3.fc17 installed | [...] `----
For example, is this version of networkmanager-gtk in Fedora 18?
there is no "networkmanager-gtk" at all in Fedora 18 and that is what is called orphan
It seems so --- the question is why aren't such packages removed by yum distro-sync?
because it is not it's job to remove any package which is not found in the repos because you may have installed it manually
it's job is to bring packages which are existing in the repos to the *exact* version in the repos no matter if this means downgrade ur upgrade them
Reindl Harald h.reindl@thelounge.net writes:
Am 11.06.2013 04:10, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
| [root@yun etc]# yum list installed |grep fc17 | NetworkManager-gtk.x86_64 1:0.9.6.4-3.fc17 installed | [...] `----
For example, is this version of networkmanager-gtk in Fedora 18?
there is no "networkmanager-gtk" at all in Fedora 18 and that is what is called orphan
It seems so --- the question is why aren't such packages removed by yum distro-sync?
because it is not it's job to remove any package which is not found in the repos because you may have installed it manually
it's job is to bring packages which are existing in the repos to the *exact* version in the repos no matter if this means downgrade ur upgrade them
Ah ok, that makes sense. Which way is there to upgrade from one release to the next when neither distro-sync, nor fedup can do this?
Is there an equivalent to Debian testing for Fedora so that I can avoid failing upgrades?
Am 11.06.2013 21:55, schrieb lee:
It seems so --- the question is why aren't such packages removed by yum distro-sync?
because it is not it's job to remove any package which is not found in the repos because you may have installed it manually
it's job is to bring packages which are existing in the repos to the *exact* version in the repos no matter if this means downgrade ur upgrade them
Ah ok, that makes sense. Which way is there to upgrade from one release to the next when neither distro-sync, nor fedup can do this?
i did dist-upgrade swith yum since Fedora 3 several hundret times even on a *lot* of production servers and "package-cleanup" is not that hard to hanlde
no idea what is your problem to type "package-cleanup --leaves --all" and remove unused packages as well as "pckage-cleanup --orphans" shows you which can probably removed and if you not blindly say "yes" if there are deps you do not want to remove this is all really easy to handle twice a year
Reindl Harald h.reindl@thelounge.net writes:
Am 11.06.2013 21:55, schrieb lee:
It seems so --- the question is why aren't such packages removed by yum distro-sync?
because it is not it's job to remove any package which is not found in the repos because you may have installed it manually
it's job is to bring packages which are existing in the repos to the *exact* version in the repos no matter if this means downgrade ur upgrade them
Ah ok, that makes sense. Which way is there to upgrade from one release to the next when neither distro-sync, nor fedup can do this?
i did dist-upgrade swith yum since Fedora 3 several hundret times even on a *lot* of production servers and "package-cleanup" is not that hard to hanlde
I just followed the recommended method using fedup, and it failed at 67%, leaving me with a mess. I'm not too familiar yet with the package management Fedora uses.
no idea what is your problem to type "package-cleanup --leaves --all" and remove unused packages
That lists 353 packages. The "problem" is:
+ I never trust computers, they do all kinds of weird and stupid stuff and sometimes the hardware fails, too.
+ I'm not very familiar with the package management Fedora uses.
+ There doesn't seem to be anything like aptitude Debian has that lets you view what packages there are, what is installed, etc.. I know there's some GUI gnome tool for that --- which, unfortunately, doesn't seem to even come close. I'm not using gnome and I forgot how this tool is called. It probably won't be helpful anyway.
+ After the upgrade failed, I could not make other assumptions about the status of the package management other than that it is probably in some sort of broken state. This assumption was apparently right because the package management still seemed to figure it was Fedora 17 while it was actually not.
+ I have no way to verify whether the package management is still in a broken state or not.
+ I have no way to verify whether my attempts to fix the mess the recommended upgrade process left me with were (sufficiently) successful.
as well as "pckage-cleanup --orphans" shows you which can probably removed and if you not blindly say "yes" if there are deps you do not want to remove this is all really easy to handle twice a year
For all I know, the recommended upgrade process could have left me stuck with an inoperational system, and I was only lucky that it didn't. I was also lucky that my attempts to fix the mess didn't seem to break anything and didn't seem to make things worse. Taking chances like that twice a year is /not/ easy to handle. It is out of the question, and I'm not going to do it. Reliability is required.
Looking at 353 packages and deciding whether to remove them or not may be be more or less easy to handle. I could make a perl script that feeds the package names to yum one by one so that I can decide for each of them to either remove it or not. Then Fedora should update [1] and add a statement that users of Fedora must be programmers.
That looking at 353 packages may be easy to handle doesn't mean that it is something I would want to do twice a year --- or even once. It is something the package management should take care of, and it should at least tell me whether a package is installed because I wanted it or because the package management wanted it. I'm pretty sure that I didn't install all these 353 packages because I wanted them. So why are they installed?
For example, I know for sure that I never needed or wanted the package "xorg-x11-drv-mga-1.6.2-6.fc18.x86_64", yet it is listed by "package-cleanup --leaves --all". Why is this package installed, and since I didn't install it, why does it remain installed?
Can the package management answer such questions? It should be able to since it was used to install them, and it is supposed to know what the dependencies are. It should also know when a package was installed, and it would be nice if it was possible to add a comment when installing or removing a package so that I could tell myself why I installed or removed something. Provided I added such comments, the package management could now tell me things like "you installed [package] on [some date] because [my comment]" or "[package] was installed on [some date] for dependencies when [package] was installed because [my comment]".
[1]: http://fedoraproject.org/wiki/User_base
Am 12.06.2013 00:41, schrieb lee:
For example, I know for sure that I never needed or wanted the package "xorg-x11-drv-mga-1.6.2-6.fc18.x86_64", yet it is listed by "package-cleanup --leaves --all". Why is this package installed, and since I didn't install it, why does it remain installed?
because it was in some defualt group or installed by whatever dependency
"package-cleanup --leaves --all" ha sto be used with care it lists practically all was it not neede for the base-system but it is a good indicator what coul be theoretically removed and on my systems there is no single unused package which makes upgrades much faster and last but not least update conflicts a thing i hadrly see over years
BTW, for some reason I don't seem to get your posts from the list. It could be some sort of dupe checking gnus does on my side, but I thought I should mention it just in case.
Reindl Harald h.reindl@thelounge.net writes:
Am 12.06.2013 00:41, schrieb lee:
For example, I know for sure that I never needed or wanted the package "xorg-x11-drv-mga-1.6.2-6.fc18.x86_64", yet it is listed by "package-cleanup --leaves --all". Why is this package installed, and since I didn't install it, why does it remain installed?
because it was in some defualt group or installed by whatever dependency
Yes, I'd think so --- and now this dependency doesn't exist anymore, or the group doesn't pull it in anymore. Therefore, the package management should have removed it since I didn't tell it to install it.
"package-cleanup --leaves --all" ha sto be used with care it lists practically all was it not neede for the base-system but it is a good indicator what coul be theoretically removed and on my systems there is no single unused package which makes upgrades much faster and last but not least update conflicts a thing i hadrly see over years
I think I'll make that perl script to go through these packages and remove those I don't need. Apparently they don't hurt anything, but it's better not to have packages installed that aren't needed.
On 06/11/2013 03:41 PM, lee wrote:
- There doesn't seem to be anything like aptitude Debian has that lets you view what packages there are, what is installed, etc.. I know there's some GUI gnome tool for that --- which, unfortunately, doesn't seem to even come close. I'm not using gnome and I forgot how this tool is called. It probably won't be helpful anyway.
What you're looking for is yumex, which isn't Gnome-specific AFAIK. I'm not sure if it's the right tool for this job, but at least it's worth looking at.
FWIW, a hung upgrade once left me with no GUI, and enough dupes that package-cleanup --cleandupes seemed to be hanging as well. What I did, as root, was to run package-cleanup --dupes and pipe the output into a text file. Then, I used yum manually to get rid of some of the dupes. Lather, rinse, repeat as time allowed, until the number of dupes got small enough for --cleandupes to handle. Then, and only then, I started getting X working again, on the principle of one thing at a time. It was either that, or a complete fresh install, and I was stubborn enough that I decided not to re-install unless I had to. And, of course, being retired, I had plenty of time to devote to the exercise. In a production environment, I'd never have considered spending that much time on repair because replacement would have been far more cost effective.
Joe Zeff joe@zeff.us writes:
On 06/11/2013 03:41 PM, lee wrote:
- There doesn't seem to be anything like aptitude Debian has that lets you view what packages there are, what is installed, etc.. I know there's some GUI gnome tool for that --- which, unfortunately, doesn't seem to even come close. I'm not using gnome and I forgot how this tool is called. It probably won't be helpful anyway.
What you're looking for is yumex, which isn't Gnome-specific AFAIK. I'm not sure if it's the right tool for this job, but at least it's worth looking at.
Thank you! I installed and tried it and removed it ...
FWIW, a hung upgrade once left me with no GUI, and enough dupes that package-cleanup --cleandupes seemed to be hanging as well. What I did, as root, was to run package-cleanup --dupes and pipe the output into a text file. Then, I used yum manually to get rid of some of the dupes. Lather, rinse, repeat as time allowed, until the number of dupes got small enough for --cleandupes to handle. Then, and only then, I started getting X working again, on the principle of one thing at a time. It was either that, or a complete fresh install, and I was stubborn enough that I decided not to re-install unless I had to. And, of course, being retired, I had plenty of time to devote to the exercise. In a production environment, I'd never have considered spending that much time on repair because replacement would have been far more cost effective.
There seems to be some agreement that upgrades of Fedora have a tendency to go wrong and that it's usually still fixable. That speaks against it and at the same time, it speaks for it. I'll just have to see what happens on the next upgrade.
On Sat, 08 Jun 2013 22:51:52 +0200 lee lee@yun.yagibdah.de wrote:
Hi,
running the update from 17 to 18 failed after going 67% through, please see https://bugzilla.redhat.com/show_bug.cgi?id=972358 .
What can I do now so I'm not stuck with a mixture of 17 and 18?
Apologies, for the link to complete instruction: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum?rd=YumUpgradeFaq#F...
-
Frank Murphy -
Joe Zeff -
Kevin Fenzi -
lee -
Reindl Harald -
T.C. Hollingsworth -
Tim