Last weekend I went through a somewhat lengthy process of upgrading one of my servers from Fedora 6 to Fedora 12. The server is vital for a company that uses it, there is more than 2 TBytes of data on that machine, and I only had a weekend to go through the upgrade.
Fedora is a very dynamic distribution, with new releases coming out roughly every 6 month. An upgrade backward compatibility is maintained only for the last 2 releases. So, I had to first upgrade from Fedora 6 to Fedora 8, then from Fedora 8 to Fedora 10, and then finally from Fedora 10 to Fedora 12.
Of course such a long path would pretty much guarantee that things would break. But gladly I didn’t have to fix them for every upgrade, only once, after Fedora 12 upgrade was complete. So the actual upgrade routine was rather simple: insert DVD with the new version, reboot, upgrade, remove DVD, reboot. I was attempting to boot the system at least once into each new version to see how much stuff would break and if I notice anything going horribly wrong. Everything was going smooth, except for once machine refused to boot into the new version (Fedora 8, if I remember correctly). That didn’t stop me though. Just upgrade to the next one, and then to the next one, etc.
After the upgrade was finished, I installed the updates for Fedora 12 and started fixing things. The thing that I was worried for the most was Request Tracker (aka RT3) installation, which is a Perl application. As any proper Perl application, RT3 utilizes a whole lot of Perl modules from CPAN and every time Perl version is changed signifficantly, these modules should be downloaded and installed. Before, it was a rather slow, boring, and time consuming task. Now however things are much simpler. Before any perl upgrade just create an autobundle using the command “perl -MCPAN -e autobundle“. This will create a bundle with all your current Perl modules. After the upgrade is done, run “perl -MCPAN -e ‘install Bundle::Snapshot_2010_01_27_00‘” (where 2010_01_27_00 is the bundle version, as given to you by autobundle). Now Perl will download all modules and their requirements from CPAN and install them automatically. Pure magic.
Apart from RT3 only one thing broke. One that I would expect to break because I don’t follow the development of it that close. It was Samba. After the upgrade to Fedora 12 none of the users could connect to any of the file shares. “Access denied” was given no matter which username and password was used and what was the access level to the share. A quick Google search revealed the fix. Apparently, somewhere in between Fedora 6 and Fedora 12, Samba changed default back-end for storing credentials. A fix was as simple as adding a single line (“passdb backend = smbpasswd) to the configuration file, that switched Samba back to the old backend.
And that’s it! That’s all that broke and had to be fixed after an upgrade between 6 versions of a rather dynamic Linux distribution. Once again, I am really amazed by how well things are managed in Fedora. Kudos and congrats!
I, unfortunately was not that lucky. Maybe its the ppc architecture but my upgrade from Fedora 10 to 12 went disastrous. for some reason, despite choosing to upgrade, the installer delete the entire harddisk and tries to install, which later on fails for some reason.
I ended up installing ubuntu. Now I don’t mean to start a distro-quarrel or anything, just that rpm/yum should support seamless upgrade. On other pc’s that I have debian based Linux, all I need to do is change the release name in the sources.list file. minor breakage is expected, not a total loss of filesystem.
ridzuan,
I suspect that indeed it might be related to your ppc architecture. I’ve upgraded both Red Hat and Fedora a billion times and never had any truly disastrous results. Not all applications handle the upgrades nicely – that’s true, but as overall, nothing that I’d blame on yum. Even those couple of times when I got to a non-bootable system the solution was to overwrite the MBR.
Sad to hear that you had such an experience.