Tag Archive for 'upgrade'

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

More Karmic FAIL

At work most of our computers run Ubuntu (well, they used to) and the upgrade to Karmic has not been fun. Mike’s machine broke X, Evolution on Justin’s machine segfaults whenever he tried to create a new email and it also booted his old 2.6.28 kernel instead of the new 2.6.31 version. AC’s computer lost all his desktop icons in GNOME, the subtitling editing program he uses broke and needed a re-install, the screensaver also locks up his machine… and so on.

On top of all that, a non-technical user which I put onto Ubuntu tried to upgrade at home and it failed too. Also, my boss tried to upgrade his home computer to Karmic for the second time, but it aborted during the process.

This is all about 6 weeks after the initial release.. *sigh*

Karmic upgrade, broken printing. Workaround.

So on another machine (my Dad’s to be exact) after an upgrade to Karmic, both sound and printing were broken.

I fixed the printing issue last night, which was truly strange. The original printer was still there (as I would expect) and could be seen in the GNOME print manager. The problem was that it just wouldn’t print at all. Taking a closer look, for some reason the driver had been reset to “Alps MD-1000″ even though it’s a Samsung.

Broken printer

Changing the driver to anything else and saving the changes did not actually change the driver – it went straight back to “Alps MD-1000.” Adding a new printer resulted in the same problem.

The fix was to log into the CUPS server directly (http://localhost:631) and from here I was able to select the right driver – and it stuck. It could now print correctly.

Going back to the GNOME print manager still shows the driver as being the “Alps MD-1000″ which is just wrong.

So I’m not sure why GNOME print manager is broken, but if I configure the printer directly with CUPS it works.

Karmic upgrade, broken sound. Workaround.

Upgrading to Karmic on a Dell Optiplex 755 desktop resulted in broken sound.

It’s a very basic and extremely common card:
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)

GNOME has no sound, but opening up the mixer shows the device (analogue stereo output) and indeed when I play a sound I can see it come up on the “applications” section of the mixer.

The problem is that not only does no sound come out, but any application (from Totem to aplay) which tries to play audio hangs.

In Jaunty the sound preferences utility was much more powerful. You could choose between Pulseaudio, Alsa, ESD and OSS for various types of sound, everything was much more configurable. Now in Karmic, that’s replaced entirely and no longer possible – it appears to be Pulseaudio or nothing.

So, the “fix” is to purge pulseaudio and utils, leaving only Alsa. Reboot and magically sound works, but we’re not out of the woods yet!

Problem now is that we have no mixer under GNOME because unlike in Jaunty, it can only talk to Pulseaudio. Starting up the mixer from the command line shows it “waiting for server.” Not only that, but Totem still can’t play sound, presumably because it too is waiting for Pulseaudio.

So, what to do next? Install VLC.

This isn’t even a fix, in fact it’s hardly a decent workaround, but it is sufficient for now. How the average user is supposed to deal with this is beyond me. It’s a pity there is no longer the ability to switch between sound servers..

Update: Looks like this has been an unresolved problem for the last three months.