From Fedora Project Wiki

No edit summary
(a no to add all information here)
Line 152: Line 152:
--[[User:plautrba|plautrba]] 26 May 2011
--[[User:plautrba|plautrba]] 26 May 2011


== f15-f16 upgrade issues with grub2
== f15-f16 upgrade issues with grub2 ==


Another cautionary note should be added to f16 upgrades. (It seems edit access is restricted so I couldn't do it myself.)  
Another cautionary note should be added to f16 upgrades. (It seems edit access is restricted so I couldn't do it myself.)  
With software raid1 configurations and a partition starting at sector 63, the MBR area is too small to fit core.img created by grub2. The system is becomes unbootable. Falling back to grub1 also has issues (miscompilation etc.) and for me it resulted in an unbootable system. The workaround is to get a rescue CD, resize the first filesystem to make more room and then go on to use grub2. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=737508. A lot of others have also seen similar core.img fitting issues, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=753497.
With software raid1 configurations and a partition starting at sector 63, the MBR area is too small to fit core.img created by grub2. The system is becomes unbootable. Falling back to grub1 also has issues (miscompilation etc.) and for me it resulted in an unbootable system. The workaround is to get a rescue CD, resize the first filesystem to make more room and then go on to use grub2. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=737508. A lot of others have also seen similar core.img fitting issues, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=753497. ''Psavola, 26 November 2011''
 
That is true, but that is a general problem and not in any way special for yum upgrades. This page should not try to duplicate information that is (or should be) available elsewhere. The need to look other places for general upgrade problems is described in https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#2._Read_about_common_problems . --[[User:Kiilerix|Kiilerix]] 10:49, 26 November 2011 (UTC)

Revision as of 10:49, 26 November 2011

Updating grub shoud be done AFTER rebooting?

Mrdave said: I had problems launching grub-install /dev/sda just after the upgrade and before rebooting to the new kernel, it resulted in a unbootable system, I had to use the rescue CD and grub-install again.

This happened in F7 > F8 upgrade, in F8 > F9 I did grub-install after reboot and had no problems.

Kiilerix: Strange. I have never seen that. But I have seen that I had to do a grub-install _before_ rebooting. So I don't think there is general advice here. If others have experience in this area please let us know.

Updating from 8 => 9

Yum was not selecting any updates when doing "yum upgrade". I solved this by doing "yum --noplugins upgrade". I think one of the yum plugins was causing a problem.

issues during yum upgrade from f9 to f10

first:

at section

3. Switch repositories

maybe it's better to first move old fedora*repo* livna* etc (all except rpmfusion, usually) to an 'older' subfolder and only then

rpm -Uvh fedora-release*

also, it may be interesting to suggest using a mirror ....


second, here are my other notes during yum upgrade:


below, whenever i've done yum remove <something> i should have tried yum update <something> first.

move all fedora* livna* dribble* fresh* /old // leave only rpmfusion (clean if necessary)

Transaction Check Error:

 file /usr/bin/rhgb-client from install of plymouth-0.6.0-0.2008.11.17.3.fc10.i386 conflicts with file from package rhgb-1:9.0.0-6.fc9.i386

yum remove rhgb

 Installing     : kernel                                                                                                                               18/45 

The default plymouth plugin (.so) doesn't exist

yum remove gnome-desktop-debuginfo // needs some old libgnome thingy

file /usr/bin/kjots from install of kdepim-6:4.1.2-5.fc10.i386 conflicts with file from package kdeutils-6:4.1.2-3.fc9.i386 yum remove kdeutils

not enough disk space on / :)

Transaction Check Error:

 file /etc/pki/tls/certs/ca-bundle.crt from install of ca-certificates-2008-7.noarch conflicts with file from package openssl-0.9.8g-9.fc9.i686

yum update openssl :)

gui (gdm) does not start, even after full f10 update (and not even with xdriver=vesa)

to fix this, yum install plymouth-plugin\* plymouth-system-plugin\* yumdownloader kernel and rpm -Uvh kernel*i686* --force

also, don't forget to append

vga=0x318

at the end of the kernel line in grub.conf (if your video card is not supported by kernel modesetting ...)

have fun :)

Response to Cpanceac

Cpanceac, Could you please rework your contribution so that it confirms to wiki formatting.

Some responses:

Named external repositories can not be mentioned on this wiki. And perhaps it is a good idea to disable external repos in some cases, but usually it is a bad idea and against the repo maintainers recommendation.

The fedora-release download is so small that using a mirror makes no difference. And AFAIK download.fedora.redhat.com _is_ automatically mirrored to some degree.

The conflicts you report has not been reported by others. "yum update <something>" hints that you try to update one component at a time and thus don't get the automatic resolution you would have got with one big "yum upgrade". I find it hard to believe that you have done the upgrade exactly as recommended.

Booting with vga=xxx is not a good solution. If it was it would have been the default. This is a general discussion and not related to YumUpgradeFaq.

Kiilerix 22:44, 7 December 2008 (UTC)

Recent change to repository location

Minutes ago, the repository location (under 3. Switch Repositories) was changed (diff) from:

ftp://download.fedora.redhat.com/pub/fedora/linux/releases/<ReleaseNumber>/Fedora/<Arch>/os/Packages/fedora-release-*.noarch.rpm

to:

http://download.fedoraproject.org/pub/fedora/linux/releases/<ReleaseNumber>/Fedora/<Arch>/os/Packages/fedora-release-*.noarch.rpm

This seems to break both rpm downloads and wget (at least for me) returing a 404 error. Does anyone else get this?

Since this could be an impediment to downloading the rpms and upgrading, I undid the change until it can be sorted out.

Older releases archived

I was just trying to upgrade an F9 system to F10 (various troubles with Preupgrade and Anaconda) and saw the README file in the location advertised on this page:

ATTENTION
======================================
The contents of this directory have been moved to our archives available at:

http://archives.fedoraproject.org/pub/archive/fedora/

If you are having troubles finding something there please stop by #fedora-admin on irc.freenode.net

This change should be noted on the main wiki page

--Verdurin 15:53, 7 April 2010 (UTC)

remove yum-fastestmirror recommendation?

These days Fedora infrastructure's MirrorManager is very good at choosing the optimal mirror for yum to use, without any plugins needed. See Matt Domsch's description: MirrorManager automatic local mirror selection. The yum-fastestmirror plugin attempts to solve the same problem using a questionable heuristic. It's uncertain whether it does more good than harm. Since the users are expected to use the default metalinks to get their updates, I believe the recommendation to use yum-fastestmirror should be removed from the instructions.

--michich 29 April 2010

Systemd and chkconfig resetpriorities

Due to the change to systemd, probably the command to reset initscripts priorities isn't needed anymore starting from upgrades to F15 onwards.

reboot after update f14 - f15 using yum distro-sync

With updates upstart-1.2-4.fc15 and systemd-26-2.fc15 from https://bugzilla.redhat.com/show_bug.cgi?id=707507 users won't be able to clearly reboot system after yum distro-sync update. Suggested fix is temporary install upstart and initscripts-legacy packages. 'kill 1' is also possible but result of reboot might be unsure.

--plautrba 26 May 2011

f15-f16 upgrade issues with grub2

Another cautionary note should be added to f16 upgrades. (It seems edit access is restricted so I couldn't do it myself.) With software raid1 configurations and a partition starting at sector 63, the MBR area is too small to fit core.img created by grub2. The system is becomes unbootable. Falling back to grub1 also has issues (miscompilation etc.) and for me it resulted in an unbootable system. The workaround is to get a rescue CD, resize the first filesystem to make more room and then go on to use grub2. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=737508. A lot of others have also seen similar core.img fitting issues, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=753497. Psavola, 26 November 2011

That is true, but that is a general problem and not in any way special for yum upgrades. This page should not try to duplicate information that is (or should be) available elsewhere. The need to look other places for general upgrade problems is described in https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#2._Read_about_common_problems . --Kiilerix 10:49, 26 November 2011 (UTC)