Tag Archive for 'fedora'

Page 3 of 6

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

Testing yum’s autoremove orphaned deps feature

Yesterday I wrote about yum’s new feature which can automatically remove unused dependencies when a package is uninstalled.

Today I got my hands on a suitable build of yum (add the yum-rawhide repo and set clean_requirements_on_remove=1 under [main] in /etc/yum.conf) and I started to test it out on several packages, all of which introduced dependencies. My initial findings? It’s great.

Single package with dependencies
I started with a single package with several dependencies. When I uninstalled the parent package, yum also removed all of its dependencies which were not needed by any other package (i.e. orphaned dependencies).

Let’s look at an example; installing Ekiga which pulls in 5 dependencies.

yum install ekiga
...
Installed:
ekiga.x86_64 0:3.2.7-4.fc14
Dependency Installed:
evolution-data-server.x86_64 0:2.32.0-3.fc14 libgdata.x86_64 0:0.6.4-4.fc14 libgweather.x86_64 0:2.30.3-1.fc14 opal.x86_64 0:3.6.8-1.fc14
ptlib.x86_64 0:2.6.7-1.fc14

OK, so we have Ekiga, and we have 5 dependencies installed. What happens if I remove Ekiga?

yum erase ekiga
...
Removed:
ekiga.x86_64 0:3.2.7-4.fc14
Dependency Removed:
evolution-data-server.x86_64 0:2.32.0-3.fc14 libgdata.x86_64 0:0.6.4-4.fc14 libgweather.x86_64 0:2.30.3-1.fc14 opal.x86_64 0:3.6.8-1.fc14
ptlib.x86_64 0:2.6.7-1.fc14

As I was hoping, yum removed all 5 dependencies along with Ekiga itself. Ta da!

Result: Tick!

Packages with shared dependencies
I then tested two packages which have shared dependencies. What I would expect is that only the dependencies which are unique to the application being removed, are uninstalled. Other shared dependencies remain, because the other program still requires them and is not being removed.

Let’s look at an example; mplayer and vlc. Both require the libcaca library and installing both packages pulled in this library.
VLC needs libcaca:

yum deplist vlc |grep libcaca
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14

And mplayer needs libcaca:

yum deplist mplayer |grep libcaca
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14

When I want to remove mplayer, yum only removes those mplayer dependencies which vlc does not also require, and leaves the rest (including libcaca).


yum erase mplayer
...
Removed:
mplayer.x86_64 0:1.0-0.119.20100703svn.fc14
Dependency Removed:
libvdpau.x86_64 0:0.4.1-1.fc14.1 lzo.x86_64 0:2.03-3.fc12 mplayer-common.x86_64 0:1.0-0.119.20100703svn.fc14

Note that libcaca was not removed, which is the expected result.

Result: Tick!

Removing a package’s dependency
I then tried to remove a dependency, rather than the parent package. I would expect this to remove all parents which required that package, along with their other dependencies.

Let’s look at an example, gnash-plugin. This package pulls in three dependencies (including the actual gnash package).


yum install gnash-plugin
...
Installed:
gnash-plugin.x86_64 1:0.8.8-4.fc14
Dependency Installed:
agg.x86_64 0:2.5-9.fc13 gnash.x86_64 1:0.8.8-4.fc14 gtkglext-libs.x86_64 0:1.2.0-10.fc12

Now, let’s see what happens if I try and remove one of the dependencies.

yum erase agg
...
Removed:
agg.x86_64 0:2.5-9.fc13
Dependency Removed:
gnash.x86_64 1:0.8.8-4.fc14 gnash-plugin.x86_64 1:0.8.8-4.fc14 gtkglext-libs.x86_64 0:1.2.0-10.fc12

As you can see, it correctly removed the parent package, which could no-longer operate without the dependency.

This is such a great advancement over remove-leaves, where last time I tried to remove gnash-plugin (after testing it out, I didn’t want it) yum wanted to remove Firefox!! Fail.

Result: Tick!

Suggestion – clean up existing system
One thing I would like, is the ability to run a system wide cleanup using this code in yum, rather than other rpm orphan tools. Sort-of like an apt-get autoremove. Theoretically, if you’ve always removed any packages on your system with this new feature then you should be right, but it would be nice to sort-of do a clean up at any point (on any system) and get yum to remove any orphaned deps for you. Maybe this already exists.

If you want to clean up existing orphaned dependencies, then package-cleanup is your friend (from yum-utils).

Take a look at all the packages that are orphaned, and make sure it is sane.

package-cleanup --leaves

If you’re happy with the list, you can just remove them all (after you’ve enabled yum’s new autoremove feature, of course!):


yum erase $(package-cleanup --leaves)

You can instantly see the benefit of this new feature – on my machine this command also removes brand new orphaned dependencies, created by the orphans I’m removing! That’s 59 packages in total.

Without this yum feature, it would only remove 36 packages. You would need to run package-cleanup several times, until you’ve really removed all orphaned packages.

Similarly, this works for package-cleanup –orphans but it would be great it this was built into a single yum cleanup type function – one command to do it all.

Summary
From my initial testing, this works really well, although I’ll continue to test it and see how we go. Hopefully this will find its way into Fedora 12, 13, and 14 rather than just 15.

I’m so grateful for this work – it’s something I’ve been crying out for ever since I made the decision to stick with Fedora. Thank you, thank you, thank you!!

Yum gets autoremove dependency feature

Coming from a Gentoo/Debian background, one thing that has constantly bugged me on RPM based platforms like Fedora is the lack of decent, reliable dependency removal.

It seems so simple (and Debian has done it since the dawn of time) – if I install package x which pulls in dependencies y and z, then when I remove package x, I want to remove dependencies y and z, if they are not required by any other package.

Yes, there is the remove-leaves plugin for Yum and various RPM orphan checking tools, but in my experience, they are just not reliable.

So, I’m very happy to have discovered that Seth Vidal has merged orphaned dependency cleanup on removal into Yum. Hallelujah!

It’s in rawhide yum-3.2.28-13, and I’ll do some testing soon…

New Fedora website is great

I just noticed that in time for Fedora 14 (which has just gone gold), the project has released a new website.

It’s great. Has lots of useful information about Fedora, especially for new users.

Fedora website

Great work!

Encrypted DVDs and Fedora

The well known RPMFusion repository contains a lot of the useful software which Red Hat doesn’t ship by default (for licensing, patent or legal reasons). It is the amalgamation of several other repositories, including Dribble, Freshrpms, and Livna.

One helpful package that RPMFusion does not package however, is libdvdcss, the free software library which enables Linux to play encrypted DVDs.

Most users keep Livna around for this single purpose, but it is often offline (especially recently). So, here’s another solution – use ATrpms – another third party repository that includes lots of handy software.

The problem is, ATrpms has lots of other software which you might not want to update and which could conflict with the packages from RPMFusion. The solution? Tell yum to only include libdvdcss* packages from that repository. Easy.

To do this, simply add a new repo file (/etc/yum.repos.d/atrpms.repo) for Yum to configure it.
[atrpms]
name=Fedora Core $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/f$releasever-$basearch/atrpms/stable
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
gpgcheck=1
includepkgs=libdvdcss*

Now, just run the following to update the repo and install libdvdcss (you may wish to remove the old package first, if you have it).
sudo yum check-update
sudo yum install libdvdcss

That’s about it!

-c

Samsung R480 laptop LCD brightness

Mendy got a Samsung R480 laptop but screen brightness did not work properly. Using KDE’s brightness slider caused the screen to flicker horribly and once you let go, it’s too dark. GNOME’s just doesn’t work at all.

After a suspend and resume with the Nouveau driver, the slider works properly, but only goes to half brightness at the maximum setting. It was possible to set the brightness manually via:
echo -n 60 > /proc/acpi/video/NVID/LCD/brightness

That was not suitable. So I switched to the NVIDIA driver, but the laptop brightness was immutable until I discovered a post with the solution. Simply adding the following to the Device section in /etc/X11/xorg.conf lets KDE control the brightness correctly, and perfectly. Great!
Section "Device"
Identifier "Videocard0"
Driver "nvidia"
Option "RegistryDwords" "EnableBrightnessControl=1"
Option "UseEdidDpi" "false"
Option "DPI" "96 x 96"
EndSection

I also added the DPI option above to get 96×96 as some text was too large after switching to the NVIDIA driver. Fedora still suspends and resumes and everything is just perfect!

Getting full 32-bit support in 64-bit Fedora

Is as easy as installing the 32bit version of Red Hat’s Linux Standard Base (LSB) package:
yum install redhat-lsb.i686

Fedora minimal install

To get a basic, command line only, base packages install of Fedora, simply add “text” to the installer’s kernel line at boot.

This will then install around 200 base packages and give a small, clean, lean system. From here you can install whatever package or group you like to built it up to something you want.

See here for more options for Anaconda, the Fedora installer.

Update: Alternatively, select “Customize now” during the standard installation process and un-tick everything (yes, ALL package groups even the Base group!). This will then also install the same 200 base packages for a minimal system, but has the added benefit of providing the graphical installer. Use the netinstaller to reduce your initial download.

When Compiz won’t start..

So now that you know how to get Compiz working properly, what do you do if it still refuses to enable itself via the “Desktop Effects” program?

Justin had this exact problem on his machine. It appears that the compiz-gtk script wouldn’t start and my theory was that it’s unable to replace Metacity (for some reason).

So I fixed this by editing his gconf file directly
sed -i 's/metacity/compiz-gtk/' \
.gconf/desktop/gnome/session/required_components/%gconf.xml

This means that Metacity is never loaded to begin with, instead calling compiz-gtk to do its magic.

This is exactly what is set after successfully enabling Compiz via the “Desktop Effects” program, so we’re just bypassing whatever problem was stopping it from being enabled (like I said, I think it was unable to replace Metacity).

If you have the same problem, try this fix. If it can’t start Compiz it will safely revert to Metacity.

-c

Fedora 12 and Compiz (Settings Manager)

Fedora uses the older method of enabling Compiz, via the gconf plugin.

The “Desktop Effects” program under System -> Preferences runs the /usr/bin/compiz-gtk script (part of the compiz-gnome package) to enable Compiz, or fall back to Metacity (GNOME’s window manager).

gconf backend
The compiz-gtk script executes the command:
compiz --ignore-desktop-hints glib gconf gnomecompat

On systems here (with NVIDIA cards at least), the gconf backend package was not installed. This means that even though NVIDIA and 3D is all working, Compiz won’t start. So, installing the required gconf backend package should make it all work.

su -c 'yum -y install compizconfig-backend-gconf'

Now try again.

ccp backend
Upstream however, Compiz has moved away from gconf and is using libcompizconfig (ccp) and the CompizConfig Settings Manager (ccsm) to handle settings.

Installing the ccsm package under Fedora and changing Compiz settings using the graphical manager (CompizConfig Settings Manager) results in none of those taking effect.

This is because the compiz-gtk script is not loading the ccp module. So the workaround is to install ccsm and then modify the script to replace gconf with ccp.

su -c "sed -i 's/gconf/ccp/' /usr/bin/compiz-gtk"

Now try again.

Keep in mind that updated versions of the compiz-gnome package may overwrite this file, so you’ll need to edit it again in future if this happens.