Upgrading To CentOS 7

Home » CentOS » Upgrading To CentOS 7
CentOS 6 Comments

I read in

“Warning: use of this tool is currently not recommended as several system-
critical packages are of a higher version number in CentOS 6.6 than they are in CentOS 7 so those do not get upgraded correctly. This renders yum and several other system tools non-functional.”

Does this still hold?
It seems to me a bit pointless to offer a tool with the warning that it does not work.

6 thoughts on - Upgrading To CentOS 7

  • It is not pointless, some people want to do it.

    I would not use it.

    To each their own.

    The best way to do any major update is to backup your data, install the OS, bring back your data and make all the newer services (if you are moving things like databases or web directories, etc.).

    Some people want to take shortcuts to this procedure, and with enough effort, that tool can work. But to me, there is too much effort and there are too many older packages left around as clutter, so I would never do it.

    It can be done, however.

    Red Hat released this, so we rebuilt it .. that does not mean one should use it.

    Thanks, Johnny Hughes

  • Johnny Hughes wrote:

    First of all, thank you very much, Johnny, for all your work. You are doing a fantastic job.

    However, I find your answer here a little odd. It’s a bit like the surgeon saying, “I wouldn’t have this operation, but if you want it just lie back.”

    If it would take you a lot of time and effort to clean up after the upgrade I can’t imagine how long it would take me.


  • That’s not far from the truth. Upstream, this tool supports a very limited scope, and has a rather substantial pre-upgrade test to determine how feasible it is. Since we don’t differentiate between Server, Workstation, etc it’s a bit more interesting for us to say “yeah sure you can totally run this”. If you add 3rd party packages into the mix, it gets even crazier.

    If you have a good config management environment set up, rolling out a new build to replace older systems is much easier than walking through an update on each system. I really recommend people use ansible, chef, puppet.. whatever they’re comfortable with to do some basic automation.

    It’s a feature people have wanted/demanded for years. It doesn’t make it sane, just popular.

  • Just do lots of testing, first :-) There are sufficient differences between major OS releases (5, 6, 7) that you may need different rules for each type.

    For example, postfix is different version on each so main.cf and master.cf are different and have version specific differences. Apache is sufficiently the same between 5 and 6, but 7 has a totally new way of doing things And, of course, sysvinit vs upstart vs systemd!

    Config managementis a great way of rebuilding a new copy of an existing version, but it’s not a panacea when changing versions.

  • Thank you.

    It is going to take a long time to fix issues in any Major upgrade. Most of your apache config files will not work, many times you need to run an upgrade on database system schemas, maybe new LDAP schema’s etc.

    That in itself is hard.

    Add on top of that, if using the update tool, a bunch of packages that are running using the compat-glibc from the previous release. You not only have to figure out how to do all the updated stuff from above .. you now have to figure out which of the cruft that exists from the previous version (which is still on your system as there was no upgrade for it, etc.) that is needed and what is not.

    This problem is not unique to CentOS or even Linux. Anyone ever upgrade a domain controller from WinNT-4 to Windows Server 2000 .. or Server
    2003 to Server 2008, etc. Stuff never works like it is supposed to on in-place upgrades. You will be, IMHO, fighting problems for the lifetime of that setup after that. Much cleaner to upgrade without cruft from the old OS.

    Not at all .. CentOS is a rebuild of RHEL source code. I do not agree with all the package selections they make. If it were up to me, some things would be newer or older in many releases .. but it is not up to me. If Red Hat releases the Source Code, we build it.

    Thanks, Johnny HUghes

  • It’s a good way to keep track of what makes your system unique though. Kind off a diff between the core installation and the final production system.

    For a lot of people it seems the biggest problem is to identify what they need to migrate to get things running again and adapting that to new versions is actually that that big an issue. Sure you remember to copy /etc/httpd but did you also copy that script you wrote that tweaks some queue settings in /sys or that maintenance script that you stored under /usr/local or /opt or wherever that you haven’t had to use in a year? If you have the discipline to put all that into a configuration management system then you don’t have to search for these things.