Hi,
I started an upgrade from fc13 x86_64 to fc14 x86_64, and the computer locked up during the install. I thought the problem with the PC was that it was locking up due to insufficient memory. I've added more memory, but now the upgrade won't complete.
When rebooting to the fc14 upgrade kernel, it says it can't find the install image, so I booted into the fc13 kernel, and started the yum upgrade method. During that process, it fails with the following:
--> Processing Dependency: /usr/bin/update-gdk-pixbuf-loaders for package: libwmf-0.2.8.4-22.fc13.x86_64 --> Finished Dependency Resolution Skip-broken could not solve problems Error: Package: libwmf-0.2.8.4-22.fc13.x86_64 (@updates/13) Requires: /usr/bin/update-gdk-pixbuf-loaders Removing: gtk2-2.20.1-1.fc13.i686 (@fedora/13) Not found Updated By: gtk2-2.22.0-1.fc14.1.i686 (fedora) Not found ** Found 267 pre-existing rpmdb problem(s), 'yum check' output follows: GraphicsMagick-1.3.12-2.fc14.x86_64 is a duplicate with GraphicsMagick-1.3.12-1.fc13.x86_64
followed by hundreds of other duplicates...
The command I ran was:
# yum --releasever=14 distro-sync --skip-broken
I've tried clearing the yum cache, various package-cleanup options, and it still fails. Running "package-cleanup --cleandupes", but it says:
Error: Trying to remove "yum", which is protected You could try using --skip-broken to work around the problem
I think it basically tries to remove every package on the system, because it lists thousands of packages.
I also tried to install from a local DVD, but it fails with a "debug" "save" "exit" error that it can't install some package, I think. Perhaps the same one as shown above.
How can I pick up where it left off, or delete what's been done already, or restart and force the install of fc14 packages that are already installed?
Thanks, Alex '
On Mon, Mar 7, 2011 at 11:03 AM, Alex mysqlstudent@gmail.com wrote:
Hi,
I started an upgrade from fc13 x86_64 to fc14 x86_64, and the computer locked up during the install. I thought the problem with the PC was that it was locking up due to insufficient memory. I've added more memory, but now the upgrade won't complete.
When rebooting to the fc14 upgrade kernel, it says it can't find the install image, so I booted into the fc13 kernel, and started the yum upgrade method. During that process, it fails with the following:
--> Processing Dependency: /usr/bin/update-gdk-pixbuf-loaders for package: libwmf-0.2.8.4-22.fc13.x86_64 --> Finished Dependency Resolution Skip-broken could not solve problems Error: Package: libwmf-0.2.8.4-22.fc13.x86_64 (@updates/13) Requires: /usr/bin/update-gdk-pixbuf-loaders Removing: gtk2-2.20.1-1.fc13.i686 (@fedora/13) Not found Updated By: gtk2-2.22.0-1.fc14.1.i686 (fedora) Not found ** Found 267 pre-existing rpmdb problem(s), 'yum check' output follows: GraphicsMagick-1.3.12-2.fc14.x86_64 is a duplicate with GraphicsMagick-1.3.12-1.fc13.x86_64
followed by hundreds of other duplicates...
The command I ran was:
# yum --releasever=14 distro-sync --skip-broken
I've tried clearing the yum cache, various package-cleanup options, and it still fails. Running "package-cleanup --cleandupes", but it says:
Error: Trying to remove "yum", which is protected You could try using --skip-broken to work around the problem
I think it basically tries to remove every package on the system, because it lists thousands of packages.
I also tried to install from a local DVD, but it fails with a "debug" "save" "exit" error that it can't install some package, I think. Perhaps the same one as shown above.
How can I pick up where it left off, or delete what's been done already, or restart and force the install of fc14 packages that are already installed?
Thanks, Alex
Back up your important files to an external device. Burn a CD or DVD and install from it.
On Monday, March 07, 2011 02:03:20 pm Alex wrote:
Hi,
I started an upgrade from fc13 x86_64 to fc14 x86_64, and the computer locked up during the install. I thought the problem with the PC was that it was locking up due to insufficient memory. I've added more memory, but now the upgrade won't complete.
While you've been given the advice to reinstall, much like a Windows system, there is one other utility you can try first, if you haven't completely blown out the yum transaction, that is.
yum install yum-utils yum-complete-transaction
That's probably a slim possibility, but I had to do that with one F13->F14 upgrade; but yum-complete-transaction was the very first command I ran, and I didn't try another install in between, and the repositories hadn't changed enough to change the contents of the yum transaction (which will abort it).
Another possibility is to run package-cleanup --dupes to list the duplicates, an rpm -aq to list all packages, edit out the dupes, then manually install the needed rpms to upgrade from the DVD. Good luck.
On Mon, Mar 07, 2011 at 14:31:41 -0500, Lamar Owen lowen@pari.edu wrote:
While you've been given the advice to reinstall, much like a Windows system, there is one other utility you can try first, if you haven't completely blown out the yum transaction, that is.
yum install yum-utils yum-complete-transaction
This should have a good shot. Though some other hand cleanup might be needed.
Another possibility is to run package-cleanup --dupes to list the duplicates, an rpm -aq to list all packages, edit out the dupes, then manually install the needed rpms to upgrade from the DVD. Good luck.
That may have issues if the f14 packages need something that wasn't installed yet. Doing a yum downgrade with releasever set to 13 might get you back to where you were before the upgrade attempt.
I have done a number of yum upgrades to go between Fedora releases that were done part at a time. (Sometimes because of not a enough free space on /; sometimes because of broken or missing obsoletes or retired packages without replacements and sometimes because something went wrong part way though the update.) So far I have always been able to keep going forward and complete the update. Sometimes you may need to remove some packages that are blocking updates but are not properly replaced in the next release. Finding those can be tricky when a big transaction is failing, but you can usually get some clues. Also you can update smaller groups of packages at once to try to work around the problem or make it easier to figure out what is blocking the transaction.
Hi,
yum install yum-utils yum-complete-transaction
This should have a good shot. Though some other hand cleanup might be needed.
I should have mentioned that I had tried this as well.
the update. Sometimes you may need to remove some packages that are blocking updates but are not properly replaced in the next release. Finding those can be tricky when a big transaction is failing, but you can usually get
I think this may be my next effort. I'll see if I can identify which packages may be causing a problem.
Is there a way to find out the full 1240 list of packages it said initially needed to be updated? Couldn't I then use rpm to force them to install?
Thanks, Alex
On 03/07/2011 03:10 PM, Alex wrote:
Hi,
yum install yum-utils yum-complete-transaction
This should have a good shot. Though some other hand cleanup might be needed.
I should have mentioned that I had tried this as well.
the update. Sometimes you may need to remove some packages that are blocking updates but are not properly replaced in the next release. Finding those can be tricky when a big transaction is failing, but you can usually get
I think this may be my next effort. I'll see if I can identify which packages may be causing a problem.
Is there a way to find out the full 1240 list of packages it said initially needed to be updated? Couldn't I then use rpm to force them to install?
Alex, When I'm upgrading, and it fails, I try to reduce the amount I can upgrade at "one time". As long as the fedora-release-14 package is already installed (install it by hand if you have to!), you should break your work load into smaller units.
Start with something like:
yum upgrade rpm yum
When this completes, go on to something else. For the most part, I find myself doing:
yum upgrade a* yum upgrade b* yum upgrade c*
etc. When I complete the alphabet, I can usually do the rest (packages whose names start with a capital letter) in one fell swoop:
yum upgrade
If you run into a problem with a letter group of packages, break it down into something smaller. The l's can be difficult because of all of the different libraries involved. The g's contain all of the gnome packages, the k's all of kde, and of course, most of X starts with the x's. I have upgraded my main server this way on more than 1 occasion, and my laptop as well (I even did the x86->x86_64 change with this laptop upgrade from FC6 to F9). It may take a lot of time, but it does ensure that the update will complete. If you continue to have a couple of "problem" packages, ignore them until the very end, then try and determine "why" they are a problem. They could be obsoleted by some package you have not yet installed/upgraded. You might want to delete them if you can determine that you no longer need them.
I hope this is helpful! Good Luck!
Thanks, Alex
On 03/07/2011 03:10 PM, Alex wrote:
Hi,
I think this may be my next effort. I'll see if I can identify which packages may be causing a problem.
Is there a way to find out the full 1240 list of packages it said initially needed to be updated? Couldn't I then use rpm to force them to install?
Not a good idea to force install things, particularly at upgrade. Good way to hose your system.
I think you've got good advice in this thread. I've done upgrades using yum instead of preupgrade, and what they are telling you to do worked for me also. Whenever I hit a package that wouldn't upgrade because it had problems, I cut and pasted the name into a file for later install, and then used yum to remove it. These are usually obscure packages, so they don't tend to pull a lot of dependencies. If they do, and the dependencies aren't critical to system function, I cut and paste their names into the file also, remove them with yum, and make them part of the reinstall. I have yet to run into anything that was critical to system functionality using this method.
When you do your yum upgrade do something like yum upgrade -y a* > yum_output 2> yum_errors
Then the packages that are causing the errors are usually in the yum_errors file. And you can monitor what is happening. You might turn up yum error reporting from 2 to 6 or so in the /etc/yum.conf file to get more feedback about what is going on too.
Don't turn off your system until you have completed the upgrade or you might be left in an unbootable state. e.g. libc not updated, though the kernel is, or something like that.
I've never failed to complete an upgrade using these methods, though lately I just do a separate fresh install on a different partition and migrate over.
Hi,
Start with something like:
yum upgrade rpm yum
When this completes, go on to something else. For the most part, I find myself doing:
yum upgrade a* yum upgrade b* yum upgrade c*
Yes, great advice. I also learned that as an effective way to troubleshoot after going through this. Turned out removing that initial package that was causing trouble was enough to get it going again:
--> Processing Dependency: /usr/bin/update-gdk-pixbuf-loaders for package: libwmf-0.2.8.4-22.fc13.x86_64
After removing it, the box seized again (turned out it was overheating, I think), but I was able to do some combinations of "rpm -e" with "yum --releasever=14 dist-upgrade --skip-broken", and it downloaded nearly all the packages again but eventually installed them all.
I had to then use "package-cleanup --cleandupes" to remove all the old fc13 packages.
Somehow through this process, the grub.conf didn't upgraded with the new kernel and it got screwed up. Had to use dracut to rebuild the initramfs and grub-install to make sure the bootloader was installed.
Now, I have a problem with selinux that I can't figure out. It boots properly in enforcing mode, but won't let anyone login:
[ 25.346263] SELinux: Context system_u:unconfined_r:kernel_t:s0 would be invalid if enforcing
Booting with enforcing=0 enables root to login. How can I fix this?
Thanks, Alex
On Tue, Mar 08, 2011 at 02:27:01 -0500, Alex mysqlstudent@gmail.com wrote:
Now, I have a problem with selinux that I can't figure out. It boots properly in enforcing mode, but won't let anyone login:
[ 25.346263] SELinux: Context system_u:unconfined_r:kernel_t:s0 would be invalid if enforcing
Booting with enforcing=0 enables root to login. How can I fix this?
First step is to try relabelling.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/08/2011 08:07 AM, Bruno Wolff III wrote:
On Tue, Mar 08, 2011 at 02:27:01 -0500, Alex mysqlstudent@gmail.com wrote:
Now, I have a problem with selinux that I can't figure out. It boots properly in enforcing mode, but won't let anyone login:
[ 25.346263] SELinux: Context system_u:unconfined_r:kernel_t:s0 would be invalid if enforcing
Booting with enforcing=0 enables root to login. How can I fix this?
First step is to try relabelling.
Something is reall screwed up. I would do
# yum reinstall selinux-policy-targeted # touch /.autorelabel; reboot
Hi,
Now, I have a problem with selinux that I can't figure out. It boots properly in enforcing mode, but won't let anyone login:
[ 25.346263] SELinux: Context system_u:unconfined_r:kernel_t:s0 would be invalid if enforcing
Booting with enforcing=0 enables root to login. How can I fix this?
First step is to try relabelling.
Something is reall screwed up. I would do
# yum reinstall selinux-policy-targeted # touch /.autorelabel; reboot
I should have mentioned that I did relabel and it didn't make any difference.
I did find this post:
https://bugzilla.redhat.com/show_bug.cgi?id=443569
and it mentioned running "semanage login -m -s unconfined_u __default__". This enabled me to login once again, but there are now other errors:
[ 9.718499] type=1400 audit(1299611791.043:3): avc: denied { mmap_zero } for pid=670 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect [ 14.847056] type=1400 audit(1299611796.172:4): avc: denied { write } for pid=839 comm="system-setup-ke" name="00-system-setup-keyboard.conf" dev=sda1 ino=3414111 scontext=system_u:system_r:keyboardd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file
Suggestions for correcting these errors?
There was also this error that occurred after just installing munin:
Mar 8 14:42:30 gary setroubleshoot: SELinux is preventing /usr/sbin/httpd from search access on the directory /etc/munin. For complete SELinux messages. run sealert -l 7cfb6635-60f5-4f85-9e93-081af231b418
Should that have happened?
Thanks, Alex