13 thoughts on - Upgrade From CentOS6.6 To CentOS 7

• Given how radically the OS changed, I would strongly advice against it. The move from sysvinit to systemd alone is enough to recommend against an upgrade.

• So it’s not possible under any circumstances?

• I suppose anything is possible with enough time and effort, but I
  strongly recommend against it.

  CentOS is a server OS and as such should be used in a manner that provides maximum reliability. An upgrade in general introduces avoidable risk. An upgrade from 6 to 7 would induce far more risk than usual.

  Much safe to setup CentOS 7 fresh and migrate services over in a controlled fashion.

• Hi Digimer

  I’m aware and appreciative of these risks. However, given the unique situation I need to address, it’s worth spending the time needed to attempt this. If some tweaking, and a moderate amount of head-wall contact is required, that’s ok.

  If there is any method that provides a reasonable approximation of success, I’d be thankful if you could point me to it.

• Traiano Welcome wrote:
  

  Let me offer you one option: *IF* you have enough space on your filesystems, you could:
  mkdir /boot/old /old zsh zmodload zsh/files mv /boot/* /boot/old/
  mv /usr /old/
  mv /lib* /old/
  sync sync And go into the installer. If you have a problem, you can go back….

  mark

• I don’t know what you should do, as I have never and would never attempt this. Given that there are (so far failed) attempts to write an upgrade program, I am not too confident at the chances of success.

  Honestly, just stay on CentOS 6. It will be supported until 2020.

• How would the move from the old to new grub work, particularly in reverse if needed?

• Digimer wrote:

  Actually, I was copying part of our internal instruction checklist for upgrading via rsync. For that, we have one machine that’s been updated to the new release. Then, on the one to be updated, we mkdir /new /boot/new, then rsync -HPavzx –exclude=/old –exclude=/var/log/wtmp $machine:/. /new/. rsync -HPavzx $machine:/boot/. /boot/new/.

  After doing the zsh stuff – that loads it all into memory, and it won’t gag when you do the moves, mv /boot/. /boot/old/, and /. /old, then mv
  /boot/old/new/. /boot/, and /old/new/. /

  Given that, you can always mv /. /old/new, and /boot/. /boot/new, rsync, and you’re back.

  Is that clear as mud? The whole idea is the os and boot is moved into the
  ./old, and the new into the real locations.

  mark

• Digimer wrote:
  Oh, btw, the plan I gave nine or ten years ago, as published in the old SysAdmin Magazine, you can read at
  <http://24.5-cent.us/upgrading_linux.doc>

  mark “damn, I’ve got to convert that to html one of these days”

• https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager?rd=Upgrading_Fedora_using_yum

  Using “yum –releasever=7 distro-sync –downloadonly”, then switching to single-user mode and “yum –releasever=7 distro-sync” you *might* be able to do it. However, you should test this on another system or in a virtual host. I’ve never done it, and it’s highly likely to have problems.

  You should be aware that the purpose of the CentOS upgrade tool is to identify and warn the user about known problems with an upgrade. Because Anaconda installations are highly customizable, it’s impossible for any of us to tell you if an upgrade will work. There are too many things that might not on your system, which we have no way of knowing.

  I don’t know what keeps you from doing a clean install. Anything I can imagine that might convince you that this is a good idea, makes this a really bad idea. If you don’t have backups, this is an extremely bad idea. If you’re trying to minimize down time or work, this is an extremely bad idea.

• *snip*

  I have to echo this. One of the reasons I stopped using Fedora is because clean installs really are the best way, even with Fedora where there was FedUp and related attempts, it always resulted for me in the new install being somewhat dirty and non-optimal.

  With CentOS if you use the most recent version with your initial install, you have at least 5 years before you need to do it again.

  And when you do need to do it again, you have time to learn the new system and then migrate intelligently.

  If there is a version of software you need that is in CentOS 7 and not in CentOS 6, often you can rebuild the src.rpm and upgrade just that package (though sometimes it requires some spec file modifications)

  I even do that with CentOS 7 where I build the latest GStreamer and replace the stock GStreamer1 packages.

  But I wouldn’t try a dist upgrade, that breaks things even on distros that allegedly support it. In my experience.

• Digimer wrote:

  Was just reading Alice’s post, and it struck me a safe way would be for the o/p to do a clean install on a different machine, then do the rsync’s I mention.

  Several gotchas: don’t forget to copy the old /etc/ssh/ssh_host* to the new /etc/ssh/, check the ifcfg-, /etc/udev/rules.d/, and, if the new system is different hardware, rebuild the initrd *before* you reboot. You can also edit /boot/device/grub whatever the damn grub2 thing is, also before reboot.

  Or edit on the boot, get it up, and rerun grub2-install.

  mark

• What “unique situation”? It’s probably not as unique as you think.

  1. Install CentOS 7 clean on a separate machine or VM.

  2. Port your apps and data over testing as you go.

  Peter