How to upgrade Fedora (using PreUpgrade)

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 update

Install preupgrade:
yum install preupgrade

Run the preupgrade tool, and follow the prompts (remote upgrades over VNC also supported):
preupgrade

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.

package-cleanup --orphans
package-cleanup --leaves

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
akonadi-1.4.0-3.fc13.x86_64
kdeedu-marble-4.5.2-2.fc13.x86_64
kdeedu-marble-libs-4.5.2-2.fc13.x86_64
kdelibs-4.5.2-8.fc13.x86_64
kdelibs-common-4.5.2-8.fc13.x86_64
schroedinger-1.0.10-1.fc13.x86_64
xorg-x11-drv-wacom-0.10.8-2.fc13.x86_64

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
Resolving Dependencies
--> 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
----
Dependencies Resolved
=================================================
Package Arch Version Repository Size
=================================================
Downgrading:
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
---
Transaction Summary
=============================================================================================================================================
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.

-c

20 thoughts on “How to upgrade Fedora (using PreUpgrade)

  1. What about the third-party repos like rpmfusion? Will the packages installed from them be properly updated?

  2. Hi Jayesh,

    Yes, that was all handled seamlessly! I even had some other third party ones like Chromium and yum-rawhide, which all worked a treat.

    -c

  3. Hi
    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
    yum update preupgrade

    preupgrade

    the process started, it seems did

    Download release info
    Download installer images
    Determine which packages to download
    Download packages
    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

    default=1
    timeout=5
    splashimage=(hd0,0)/boot/grub/splash.xpm.gz
    hiddenmenu
    title Upgrade to Fedora 14 (Laughlin)
    kernel /boot/upgrade/vmlinuz preupgrade
    repo=hd::/var/cache/yum/preupgrade
    ks=hd:UUID=3680f081-fa85-44d9-9d34-a7915f0f976c:/boot/upgrade/ks.cfg
    stage2=hd:UUID=3680f081-fa85-44d9-9d34-a7915f0f976c:/boot/upgrade/install.img
    initrd /boot/upgrade/initrd.img

    content list of /var/cache/yum/preupgrade

    sudo ls -lat /var/cache/yum/preupgrade/*/
    /var/cache/yum/preupgrade/repodata/:
    total 2240
    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
    1d46a2073097bdb6b7b6f6fba60e4525ca0bf2d1165026a3e1c87b0b2abaf07f-Fedora-14-comps.xml
    -rw-r–r– 1 root root 416267 Dec 13 14:01
    1d46a2073097bdb6b7b6f6fba60e4525ca0bf2d1165026a3e1c87b0b2abaf07f-Fedora-14-comps.xml.gz
    -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

    /var/cache/yum/preupgrade/packages/:
    total 8
    drwxr-xr-x 4 root root 4096 Dec 13 14:01 ..
    drwxr-xr-x 2 root root 4096 Dec 13 13:39 .

  4. Hi Yuan,

    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.

    -c

  5. Chris,

    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

    Any thoughts?

    Thanks,

    -k

  6. 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..

    -c

  7. /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?

    Thanks,

    -k

  8. 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?

    Thanks,

    -k

  9. 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 🙁

    -c

  10. 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.

  11. 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.

  12. Hi Forrest,

    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.

    Cheers,
    Chris

  13. 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.

    wil

  14. 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.

    -c

Leave a Reply

Your email address will not be published. Required fields are marked *