|Line 151:||Line 151:|
--[[User:plautrba|plautrba]] 26 May 2011
--[[User:plautrba|plautrba]] 26 May 2011
Revision as of 09:53, 26 November 2011
- 1 Updating grub shoud be done AFTER rebooting?
- 2 Updating from 8 => 9
- 3 issues during yum upgrade from f9 to f10
- 4 Response to Cpanceac
- 5 Recent change to repository location
- 6 Older releases archived
- 7 remove yum-fastestmirror recommendation?
- 8 Systemd and chkconfig resetpriorities
- 9 reboot after update f14 - f15 using yum distro-sync
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
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
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.
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:
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.