Coming from a Debian background, upgrading to new releases is second nature. Unfortunately, Fedora doesn’t seem to have it quite as down pat. Nevertheless, it’s possible and works quite well (but there are pitfalls, so read on).
While upgrading via PackageKit is coming, there’s a pretty decent way of doing it with PreUpgrade.
For the impatient, the steps are:
- yum update
- yum install preupgrade
- preupgrade (reboot)
- yum distro-sync
- package-cleanup –orphans (be careful!)
- package-cleanup –leaves (be careful!)
Now the longer version. First, update your current system:
yum install preupgrade
Run the preupgrade tool, and follow the prompts (remote upgrades over VNC also supported):
PreUpgrade will prompt to reboot your computer and will update your system automatically. All of your packages should be updated and your repositories configured for you (I also had RPMFusion, Chromium and yum-rawhide which all updated as expected). On one of my systems, even the NVIDIA driver was automatically updated and configured. Now you’re booted into your new Fedora 14 system.
OK, this is where things get a little tricky. Some packages might be no-longer supported, there might be removed dependencies and the like. So, there are two neat commands that we will use to identify these packages, so that you can remove them.
But wait.. I discovered that there’s a more important step to do first, or you’ll cause yourself a headache!
On my machine, this wanted to remove some pretty important packages, like kdelibs.
[chris@shem ~]$ sudo package-cleanup --orphans
[sudo] password for chris:
Loaded plugins: refresh-packagekit, remove-with-leaves
Fedora (unlike certain other distros I know) provides major updates to the latest versions of packages (like OpenOffice.org, KDE, GNOME, etc). Yay! It’s possible that your new Fedora system is running the same version of, say KDE, as your old one. This was indeed the case with my Fedora 13 to 14 upgrade (both run KDE 4.5.2 at time of F14 release).
Actually, the build of some important packages on Fedora 13 (like kdelibs-4.5.2-8.fc13.x86_64) were actually more recent than on the newer Fedora 14 system (kdelibs-4.5.2-5.fc14.x86_64).
The package-cleanup tool correctly lists kdelibs-4.5.2-8.fc13.x86_64 as being an orphan and if you were to remove this, you’d break your system badly. In fact, if you’re running yum’s brilliant new autoremove deps feature, as I am, you’ll lose most of your system. It makes sense – you are telling yum to remove kdelibs, so it goes and removes everything that relies on it! Yikes.
So first, we need to fix this by running the yum distro-sync command which recognises that we need to downgrade that kdelibs packages (and not remove it!).
[chris@shem ~]$ sudo yum distro-sync
Loaded plugins: refresh-packagekit, remove-with-leaves
Setting up Distribution Synchronization Process
--> Running transaction check
---> Package akonadi.x86_64 0:1.4.0-1.fc14 will be a downgrade
---> Package akonadi.x86_64 0:1.4.0-3.fc13 will be erased
---> Package kdeedu-marble.x86_64 0:4.5.2-1.fc14 will be a downgrade
---> Package kdeedu-marble.x86_64 0:4.5.2-2.fc13 will be erased
---> Package kdeedu-marble-libs.x86_64 0:4.5.2-1.fc14 will be a downgrade
---> Package kdeedu-marble-libs.x86_64 0:4.5.2-2.fc13 will be erased
---> Package kdelibs.x86_64 6:4.5.2-5.fc14 will be a downgrade
---> Package kdelibs.x86_64 6:4.5.2-8.fc13 will be erased
---> Package kdelibs-common.x86_64 6:4.5.2-5.fc14 will be a downgrade
---> Package kdelibs-common.x86_64 6:4.5.2-8.fc13 will be erased
---> Package schroedinger.x86_64 0:1.0.9-2.fc14 will be a downgrade
---> Package schroedinger.x86_64 0:1.0.10-1.fc13 will be erased
---> Package xorg-x11-drv-wacom.x86_64 0:0.10.8-1.20100726.fc14 will be a downgrade
---> Package xorg-x11-drv-wacom.x86_64 0:0.10.8-2.fc13 will be erased
--> Finished Dependency Resolution
--> Finding unneeded leftover dependencies
Found and removing 0 unneeded dependencies
Package Arch Version Repository Size
akonadi x86_64 1.4.0-1.fc14 fedora 677 k
kdeedu-marble x86_64 4.5.2-1.fc14 fedora 14 M
kdeedu-marble-libs x86_64 4.5.2-1.fc14 fedora 902 k
kdelibs x86_64 6:4.5.2-5.fc14 fedora 12 M
kdelibs-common x86_64 6:4.5.2-5.fc14 fedora 1.7 M
schroedinger x86_64 1.0.9-2.fc14 fedora 276 k
xorg-x11-drv-wacom x86_64 0.10.8-1.20100726.fc14 fedora 73 k
Downgrade 7 Package(s)
Total download size: 30 M
Is this ok [y/N]
Once we downgrade these packages, we can then remove any other orphans we might have, with package-cleanup –leaves and package-cleanup –orphans (I didn’t have any). One last thing to note – Fedora will not replace packages from the newer release if they are exactly the same version. For this reason, you will probably have some F13 packages still installed on your computer – don’t worry, that’s correct. They will be upgraded in time (if required).
So, now I think I know how to successfully upgrade the system without breaking it 🙂 If anyone has some other tips or corrections, please let me know! Hope that’s helpful.
What about the third-party repos like rpmfusion? Will the packages installed from them be properly updated?
Yes, that was all handled seamlessly! I even had some other third party ones like Chromium and yum-rawhide, which all worked a treat.
I have a PC with Fedora 13 (x86_64). I want to upgrade to Fedora 14
via preupgrade. after following steps
yum clean all
yum update preupgrade
the process started, it seems did
Download release info
Download installer images
Determine which packages to download
Prepare and test upgrade
but there is no packages from fedora 14 downloaded, except VirtualBox etc from outside of fedora were download.
After reboot, it started upgrade, but boot back to fedora 13. I tried a few times, the results are the same, No fedora 14 packages
downloaded. in fact, I checked /boot/grub/grub.conf is updated as
title Upgrade to Fedora 14 (Laughlin)
kernel /boot/upgrade/vmlinuz preupgrade
content list of /var/cache/yum/preupgrade
sudo ls -lat /var/cache/yum/preupgrade/*/
drwxr-xr-x 2 root root 4096 Dec 13 14:01 .
drwxr-xr-x 4 root root 4096 Dec 13 14:01 ..
-rw-r–r– 1 root root 1827888 Dec 13 14:01
-rw-r–r– 1 root root 416267 Dec 13 14:01
-rw-r–r– 1 root root 588 Dec 13 14:01 filelists.sqlite.bz2
-rw-r–r– 1 root root 1233 Dec 13 14:01 primary.sqlite.bz2
-rw-r–r– 1 root root 3383 Dec 13 14:01 repomd.xml
-rw-r–r– 1 root root 173 Dec 13 14:01 filelists.xml.gz
-rw-r–r– 1 root root 569 Dec 13 14:01 other.sqlite.bz2
-rw-r–r– 1 root root 169 Dec 13 14:01 other.xml.gz
-rw-r–r– 1 root root 182 Dec 13 14:01 primary.xml.gz
drwxr-xr-x 4 root root 4096 Dec 13 14:01 ..
drwxr-xr-x 2 root root 4096 Dec 13 13:39 .
Looks like the upgrade process (which is run after you reboot) is failing, so it’s dropping you out which puts you back to F13. I’m not sure what’s wrong, but check if there’s an anaconda log file, either in /root or in /var/log or something?
You might need to do a backup and fresh install.
I found out how to use preupgrade to upgrade from a local mirror, I blogged about it here: http://oliver.net.au/?p=188
I too have gone through the upgrade several times, without success. I followed your instructions but after my system reboots (after upgrade) I see my old fc13 grub menu, and my system boots to fc13.
Checking the anaconda.log shows some SELinux errors, and it appears evident that nothing was actually written to disk during the upgrade. In fact, when I watched the upgrade progress indicators, I never saw any status whatsoever, and the process advanced to the post-installation phase very quickly – and again, without error during the upgrade.
Here is my anaconda.log from when it starts the graphical installer:
22:54:48,346 INFO anaconda: Display mode = g
22:54:48,346 INFO anaconda: Default encoding = utf-8
22:54:48,347 INFO loader: 3145728 kB (3072 MB) are available
22:54:48,972 DEBUG anaconda: X server has signalled a successful start.
22:54:48,973 INFO anaconda: Starting window manager, pid 795.
22:54:49,022 INFO anaconda.stdout: Starting graphical installation.
22:54:49,491 INFO anaconda: using only installclass _Fedora
22:54:49,497 INFO anaconda: Detected 3024M of memory
22:54:49,497 INFO anaconda: Swap attempt of 1024M to 5072M
22:54:50,795 INFO anaconda: ISCSID is /usr/sbin/iscsid
22:54:50,795 INFO anaconda: no initiator set
22:54:51,485 WARN anaconda: step checkdeps does not exist
22:54:51,485 WARN anaconda: step dependencies does not exist
22:54:51,809 INFO anaconda: moving (1) to step findrootparts
22:54:51,809 DEBUG anaconda: findrootparts is a direct step
22:54:51,818 INFO anaconda: failed to set SELinux context for /mnt/sysimage: [Errno 95] Operation not supported
22:54:51,818 DEBUG anaconda: isys.py:mount()- going to mount /dev/sda3 on /mnt/sysimage as ext4 with options ro
22:54:51,926 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage, removeDir = False
22:54:51,982 INFO anaconda: failed to set SELinux context for /mnt/sysimage: [Errno 95] Operation not supported
22:54:51,983 DEBUG anaconda: isys.py:mount()- going to mount /dev/sda1 on /mnt/sysimage as ext3 with options ro
22:54:51,988 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage, removeDir = False
22:54:52,036 INFO anaconda: leaving (1) step findrootparts
22:54:52,036 INFO anaconda: moving (1) to step upgrademount
22:54:52,036 DEBUG anaconda: upgrademount is a direct step
22:54:52,043 INFO anaconda: failed to set SELinux context for /mnt/sysimage: [Errno 95] Operation not supported
22:54:52,043 DEBUG anaconda: isys.py:mount()- going to mount /dev/sda3 on /mnt/sysimage as ext4 with options defaults
22:54:52,274 DEBUG anaconda: isys.py:mount()- going to mount /dev/sda1 on /mnt/sysimage/boot as ext3 with options defaults
22:54:52,335 DEBUG anaconda: isys.py:mount()- going to mount //dev on /mnt/sysimage/dev as bind with options defaults,bind
22:54:52,341 DEBUG anaconda: isys.py:mount()- going to mount devpts on /mnt/sysimage/dev/pts as devpts with options gid=5,mode=620
22:54:52,348 DEBUG anaconda: isys.py:mount()- going to mount tmpfs on /mnt/sysimage/dev/shm as tmpfs with options defaults
22:54:52,375 INFO anaconda: failed to get default SELinux context for /proc: [Errno 2] No such file or directory
22:54:52,376 DEBUG anaconda: isys.py:mount()- going to mount proc on /mnt/sysimage/proc as proc with options defaults
22:54:52,378 INFO anaconda: failed to get default SELinux context for /proc: [Errno 2] No such file or directory
22:54:52,397 DEBUG anaconda: isys.py:mount()- going to mount sysfs on /mnt/sysimage/sys as sysfs with options defaults
22:54:52,534 INFO anaconda: leaving (1) step upgrademount
22:54:52,534 INFO anaconda: moving (1) to step restoretime
22:54:52,534 DEBUG anaconda: restoretime is a direct step
15:54:53,001 INFO anaconda: leaving (1) step restoretime
15:54:53,001 INFO anaconda: moving (1) to step enablefilesystems
15:54:53,001 DEBUG anaconda: enablefilesystems is a direct step
15:54:53,048 INFO anaconda: leaving (1) step enablefilesystems
15:54:53,048 INFO anaconda: moving (1) to step reposetup
15:54:53,048 DEBUG anaconda: reposetup is a direct step
15:54:53,150 INFO anaconda: transferring install image to install target
15:54:54,976 INFO anaconda: REMOVING stage2 image from /mnt/sysimage /boot/upgrade
15:54:59,290 DEBUG anaconda: Grabbing file:///mnt/sysimage//var/cache/yum/preupgrade/repodata/repomd.xml
15:54:59,306 DEBUG anaconda: Grabbing file:///mnt/sysimage//var/cache/yum/preupgrade/repodata/primary.sqlite.bz2
15:54:59,328 DEBUG anaconda: Grabbing file:///mnt/sysimage//var/cache/yum/preupgrade/repodata/1d46a2073097bdb6b7b6f6fba60e4525ca0bf2d1165026a3e1c87b0b2abaf07f-Fedora-14-comps.xml
15:55:10,757 INFO anaconda: no packages named initscripts
15:55:10,757 INFO anaconda: leaving (1) step reposetup
15:55:10,757 INFO anaconda: moving (1) to step postselection
15:55:10,758 DEBUG anaconda: postselection is a direct step
15:55:10,795 INFO anaconda: leaving (1) step postselection
15:55:10,795 INFO anaconda: moving (1) to step reipl
15:55:10,795 DEBUG anaconda: reipl is a direct step
15:55:10,795 INFO anaconda: leaving (1) step reipl
15:55:10,795 INFO anaconda: moving (1) to step install
15:55:10,823 INFO anaconda: leaving (1) step install
15:55:10,823 INFO anaconda: moving (1) to step preinstallconfig
15:55:10,823 DEBUG anaconda: preinstallconfig is a direct step
15:55:10,886 INFO anaconda: Backend logger started.
15:55:10,896 DEBUG anaconda: isys.py:mount()- going to mount /selinux on /mnt/sysimage/selinux as selinuxfs with options defaults
15:55:10,899 DEBUG anaconda: isys.py:mount()- going to mount /proc/bus/usb on /mnt/sysimage/proc/bus/usb as usbfs with options defaults
15:55:10,904 INFO anaconda: leaving (1) step preinstallconfig
15:55:10,904 INFO anaconda: moving (1) to step installpackages
15:55:10,904 DEBUG anaconda: installpackages is a direct step
15:55:10,905 INFO anaconda: Preparing to install packages
15:55:37,765 INFO anaconda: leaving (1) step installpackages
15:55:37,765 INFO anaconda: moving (1) to step postinstallconfig
15:55:37,765 DEBUG anaconda: postinstallconfig is a direct step
15:55:37,833 INFO anaconda: Expiring yum caches
15:55:41,785 INFO anaconda: Backend logger stopped.
15:55:41,786 INFO anaconda: leaving (1) step postinstallconfig
15:55:41,787 INFO anaconda: moving (1) to step copylogs
15:55:41,787 DEBUG anaconda: copylogs is a direct step
15:55:41,787 INFO anaconda: Copying anaconda logs
Hmm… what happens if you set SELinux to permissive mode? And is your /boot partition at least 500M with lots of free space? If not, clean up some old kernel packages.. Can’t see a specific error there, but certainly SELinux isn’t happy..
/boot is 1GB, and I have cleaned up all the old packages already. I am not sure how to set SELinux to permissive mode? Is it:
# setenforce 0
If so, do I need to do this prior to running preupgrade and toggle it back on after, or is it an option I need to pass as part of preupgrade?
Yep, I think that will do it, although you could also use the GUI, or pass kernel options. Anaconda also has selinux options.
Thanks for the info Chris, I’ll try it out on Monday…
Disabling selinux didn’t work.
I tried it at the command line, and also passed it as a boot option in grub.conf. No joy.
The situation remains the same – everything looks fine; all packages are downloaded, reboots to installer, but when it gets to the actual installation, nothing gets written to disk and the post-installation process starts almost immediately after I see the “starting installation” message. The anaconda.log shows a timer lapse of only 26 seconds for installation:
09:10:21,043 INFO anaconda: moving (1) to step installpackages
09:10:21,044 INFO anaconda: Preparing to install packages
09:10:47,584 INFO anaconda: leaving (1) step installpackages
09:10:47,585 INFO anaconda: moving (1) to step postinstallconfig
09:10:47,652 INFO anaconda: Expiring yum caches
09:10:51,623 INFO anaconda: Backend logger stopped.
09:10:51,624 INFO anaconda: leaving (1) step postinstallconfig
I’m clueless at this point, any ideas?
Hm…. well I’m out of ideas at this point. You’re not “upgrading” to the same version already installed, are you?
I think you’ll need to ask on a Fedora list, I’m not sure why that’s happening, sorry 🙁
Months ago I tried upgrading from 13 to 14 and was unsuccessful. Something to do with the default partition. Like Yuan (above) after reboot I’d be back to 13. I tried again today (thinking maybe this is fixed by now) and preupgrade got me to 14 no sweat. Whoever fixed that, thank you! Now I’m downloading 15 as I write this.
How did you go with 15?
Thanks for this. Got my F14 to F15 flawlessly. I do have an older media server that I can’t get to go F13 to F14 or F15, but it seems to be a problem with the F13 repositories no longer being available. Guess I’ll go the old burn and reboot method on that box. Thanks again.
Hello, does this format the drive before installation?
No, you will have an opportunity to partition during the upgrade I think. However because it’s an upgrade, you normally wouldn’t format your / partition.
Last year I did a preupgrade on my fc14 to 1fc15. After that I could not loogin after restart or boot. My fallback works. It looks just like fc15 except it is not. How can I stop the boot process right at the point of failure. This is going to sound weird, but the boot seems to go so far,not completely and then the screen jumps, clears and restarts the boot process again from the beginning. I think all my log files are wiped out when it restarts and I want to see them.
You could edit your grub entry on the fly when you boot by pressing the e key at the grub menu, then going down to the kernel line using your down arrow, press e to edit again and at the end add “single”. Then hit enter, and b key to boot. This will get you to single user mode where you can turn services on and off, and check your logs from last X.org failed attempt. I think there are also some systemd commands to print out what happened last boot.
You could also set the default runlevel boot target to text, rather than graphical. Then log in and start remaining services one by one, or just try and startx. Make sure you’re not using a proprietary graphics driver, and edit your /etc/X11/xorg.conf if neccessary.