Tag Archives: yum

Upgrading to Fedora 14 with yum

Posted on by
Reply

Fedora 14 was released two weeks ago.  I normally wait a day or two to install to let the mirrors cool down, but that put the target date right before I left for the LISA conference.  Like any good sysadmin, I’m sufficiently paranoid to not upgrade systems right before I leave, even if said system is only my own desktop.  So now that I’m back, I decided today was a good day to upgrade my home desktop.

As in the past, the recommended method was not for me — I opted to go with the Yum-based upgrade.  For Fedora 14, there’s a new feature that significantly reduces the amount of effort involved in live upgrades.  Using the –releasever argument and distro-sync command, it’s now possible to upgrade without having to manually install the updated version RPMs.  As Chris Siebenmann wrote, it can also be used to downgrade components.

I started the process doing what the instructions said, but as always it didn’t go quite perfectly.  After a little while, I noticed that yum was in an infinite loop of upgrades.

--> Running transaction check
--> Processing Dependency: texlive = 2007-51.fc13 for package: texlive-utils-2007-51.fc13.x86_64
--> Processing Dependency: texlive-dvips = 2007-51.fc13 for package: texlive-utils-2007-51.fc13.x86_6
---> Package xorg-x11-drv-nvidia.x86_64 1:260.19.12-1.fc13 set to be erased
---> Package xorg-x11-drv-nvidia-libs.x86_64 1:260.19.12-1.fc13 set to be erased
--> Processing Dependency: /usr/bin/dvips for package: openoffice.org-ooolatex-4.0.0-0.7.beta2.fc12.1.noarch
--> Processing Dependency: /usr/bin/texconfig-sys for package: linuxdoc-tools-0.9.66-5.fc13.x86_64
--> Finished Dependency Resolution

I noticed that it seemed to be related to either the nvidia drivers or the LaTeX package, so I opted to remove the drivers first:

yum remove xorg-x11-drv-nvidia

That made the loop a bit shorter, but it didn’t quite fix it, so I removed the LaTeX package:

yum remove `rpm -q --whatprovides /usr/bin/latex`

Then yum reported there were a few broken packages it couldn’t fix, so I removed them, too:

yum remove VirtualBox-3.1 perl-MythTV system-config-display python-MythTV

Finally, the upgrade was on its way.  When it finished and grub was installed, I rebooted into a nice, shiny Fedora 14 install.  (Note: to re-install VirtualBox, you’ll need to install the VirtualBox-3.2 package.)

Upgrading to Fedora 12 via yum

Posted on by
Reply

Since Fedora 12 was released yesterday, I decided I should go ahead an upgrade my Linux box at home from Fedora 11 to Fedora 12.  As I’ve done in the past, I used the Fedora Project wiki as reference to upgrade via yum.  Although it is not officially supported, it generally results in a shorter downtime than a standard re-install, and it allows me to do it remotely.

As in the past, I had to remove a few packages to make the dependencies work out.  This time around it was: krbafs-devel tigervnc-server krbafs gnome-bluetooth{,-libs} pulseaudio-module-bluetooth bluez

Then I ran into a different problem.  My /var partition ran out of space for the 1.4 GB that needed to be downloaded.  So I first ran `yum groupupdate Base` to update the basic packages and then `yum upgrade` to update everything else.

That’s when the trouble hit.  In the instructions, after yum has finished, you’re supposed to install grub.  I forgot to do that and rebooted immediately after yum was done.  I was a bit confused when the machine never came back up, so earlier today I burned a CD and went into rescue mode.  Initially, I could not get grub-install to work. I’m not sure what finally fixed it, but after several reboots and much straw-grasping, I got it working.

So now my machine is happy.  I just need to get NetworkManager to stop killing my resolv.conf

Upgrading to Fedora 11

Posted on by
Reply

All of the cool kids know that Fedora 11 was released on Tuesday.  I’d played with the Beta a bit and didn’t notice a whole lot of major differences (certainly not the big changes I found when I previously upgraded) so I figured release day was a good a time as any to upgrade.  I started with my weather data server and the process wasn’t as smooth as I’d hoped.

Before I got started, I removed some packages that I don’t need.  This machine only needs to run NFS, SSH, and LDM, so anything else is a waste of resources.  It turns out I probably wasn’t very careful with my initial install of this machine, because in addition to removing a few packages, I ended up removing several groups: “KDE (K Desktop Environment)”, “MySQL Database”, “Web Server”, “Authoring and Publishing”, “Dial-up Networking Support”, and “Graphical Internet”.

The cleanup completed, it was time to upgrade.  Once again, I followed the rather helpful guidance of the Fedora Project wiki.  The first step is to update the package lists.  For whatever reason, rpm and/or the ftp server didn’t seem happy about the * in the URL, so I had to run them separately:

# rpm -Uvh ftp://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/i386/os/Packages/fedora-release-11-1.noarch.rpm
# rpm -Uvh ftp://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/i386/os/Packages/fedora-release-notes-11.0.0-2.fc11.noarch.rpm

With that done, the next step was to do the upgrade.  Except it didn’t work.  I kept getting “Error: Cannot find a valid baseurl for repo: fedora”.  Afer a bit of Googling, I found the answer.  In /etc/yum.repos.d/fedora*repo, I had to uncomment the baseurl line.  So then I think I’m on my way, but now when I try the upgrade, ntp complains about libcrypto.  So I remove the ntp package (I didn’t really need that either, so long as I keep ntpdate installed).  Okay, now we’re good right?  No!  Now yum complains “YumRepo Error: All mirror URLs are not using ftp, http[s] or file.”

I couldn’t find much help in a Google search, so I started poking around.  The .repo file in /etc/yum.repos.d/ has a mirrorlist setting, which tells yum what the mirrors are.  I copied and pasted the URL into my web browser to verify that I could get it.  I could, and it is just a plain text listing of mirrors.  That’s when I noticed that the mirrorlist.txt in /var/cache/yum/{fedora,updates}/ was not in plain text but in XML.  So I removed the two mirrorlist files and replaced them with what I had grabbed off the web.

Finally, yum was happy to perform the upgrade.  It took a while because of all the packages that needed to be downloaded.  I actually had to run `yum upgrade` a few times because some of the packages couldn’t be downloaded.  I presume it’s because there were a lot of other people pounding on the servers.  After a reboot, everything came back happy and it was time to move on to my main desktop.

Having done this once before, I was armed with the knowledge of what to do when things didn’t go well.  And things went about as not-well as they had on the first machine.  I was able to get myself to the upgrade stage very quickly this time around, but that’s where I started having problems.  Because this machine is used as a desktop, it has a lot more stuff installed.  Doing a straight `yum upgrade` ended up requiring more space in /var than I had available.  Of course, I didn’t think to check first and it was about 90% of the way through downloading packages before it ran out of space.  So after cleaning up the last attempt, I ran `yum groupupdate Base` to get the core packages, and when that was done `yum upgrade` was small enough to work within the limits of my disk space.

So I’ve done this a few times now, and it’s never worked perfectly, but it’s always been quite manageable.  Considering that upgrading via yum is not officially supported, it works fairly reliably.  The advantages are that there’s little downtime required, and you don’t need to waste a DVD.  Upgrading via yum will continue to be my preferred method, and I’ll dink around after the rush of downloads have settled down and see if that fixes some of the issues.  If not, that’s what Bugzilla is for.

So what do I think of Fedora 11?  It’s hard to say so far.  My desktop is old enough that it can be a bit sluggish to use, and since I haven’t had much spare time lately, I’ve opted to use my MacBook Pro when I need to accomplish things.  If nothing else, KDE 4 has grown on me to the point where I actually like it.

Upgrading through yum, and how I feel about KDE 4

Posted on by
2

The Fedora Project wiki says that it’s possible to update to a new release using the Yum package manager, but that it isn’t recommended.  Normally, I’d heed the advice of those wiser than me and do an upgrade from DVD media.  Unfortunately, when I set up my desktop/server at home, I didn’t think my partitions through very well, so I figured a live upgrade was my best shot at not nuking /home.  My first step was to do a full backup of everything onto an external drive.  Protip: 28GB tarballs are awful — find a better way to do your backups.

After a few deep breaths, I started following the instructions at http://fedoraproject.org/wiki/YumUpgradeFaq.  The instructions are well-written, and I was able to follow them with nearly no problem.  When I got to the actual upgrade part, I got a few dependency errors, related to the redhat-artwork package.  Seriously?  Artwork is the holdup?  Well redhat-artwork refused to be anything but what was currently installed, so I figured I’d just un-install it and see what happened.  Normally, dependency hell prevents you from installing software; this time it prevented me from un-installing the package.  Well that’s just plain unacceptable.  After trying a few different combinations of packages to uninstall, I finally surrendered with `rpm -e –nodeps redhat-artwork`.  From there on out, the upgrade went smoothly.

So what’s so great about going from Fedora 7 to Fedora 9?  Well the main driving force was the fact that Fedora 7 was no longer getting new software, so if I wanted yum to automagically get Firefox 3 and Wine 1.0, then I needed a newer release.  I considered going to 8 and then to 9, but that seemed like a whole lot of extra work.  As it turns out, it didn’t really matter (although that may have helped my redhat-artwork issue, but maybe not).  Apart from that, there are two things I noticed right off the bat.  First, sudo now gives a more verbose prompt:

[1016 bcotton@boone /var/log ]$ sudo echo "wow Check out that informative prompt."
[sudo] password for bcotton:
wow Check out that informative prompt.

Have you ever been typing along and then you go to sudo and you forget what you need to do?  Now you get a friendly reminder.  It’s the little things like that, you know?

Of course, there’s also the second thing I noticed:  KDE 4.  When KDE 4 was released a few months ago, it was rather loudly touted on the internets.  I was interested to try it, but not interested enough to install it by hand, so I was initially rather excited to see KDE 4 when I logged in. The excitement didn’t last very long.  I am not a fan.

KDE 4 represents a significant change from KDE 3, including a much more eye-candyish look.  It is certainly a snazzy desktop, but the default UI settings aren’t all that great.  The default K-menu requires several more clicks to get to the application you want.  Toolbar widgets can’t be dragged into place, you have to right-click, select “Start Move of $widget”, lead it where you want it to go with the mouse, and then right-click and select “Stop Move of $widget”.  There are also fewer widgets (which will probably change as more people start using and developing for KDE 4), but it does support OS X widgets (at least the HTML ones).  It also seems to be less configurable than KDE 3.  This is apparently on purpose, since the code base isn’t as mature, so hopefully future releases will improve things.  I’m not displeased enough to switch to Gnome, but this will take some getting used to.