I recently built a CentOS 6 system as my main machine at home. With a bit of help from members of this list, it is now working better than the machine it replaced (RIP). The new machine works so well, that I would like to convert some CentOS 5 machines to CentOS6.
I did some research on the web and the new install is still considered the proper way to upgrade CentOS. Same as Fedora and RHEL. The question becomes, "What makes the Ubuntu developers so clever that they can do major upgrades through their apt based update system?"
There must be some sort of gotcha or tradeoff involved in allowing this.
Does anyone have any insights on why they can get away with this while CentOS cannot?
On Tue, Feb 25, 2014 at 10:25 AM, Styma, Robert E (Robert) robert.styma@alcatel-lucent.com wrote:
I recently built a CentOS 6 system as my main machine at home. With a bit of help from members of this list, it is now working better than the machine it replaced (RIP). The new machine works so well, that I would like to convert some CentOS 5 machines to CentOS6.
I did some research on the web and the new install is still considered the proper way to upgrade CentOS. Same as Fedora and RHEL. The question becomes, "What makes the Ubuntu developers so clever that they can do major upgrades through their apt based update system?"
There must be some sort of gotcha or tradeoff involved in allowing this.
Does anyone have any insights on why they can get away with this while CentOS cannot?
First, CentOS does exactly what RHEL does, so this is not really a CentOS question.
The tradeoff is that Ubuntu doesn't go to the effort to ensure that for 7+ years you can do updates and not have anything that was previously working break because a change from the update. RHEL/CentOS may not be perfect at this, but breakage is very, very rare because the updates are mostly backported security/bug fixes that don't change behavior. Ubuntu does more frequent updates of the included package versions (even with their LTS version) and if a package changes behavior that is left as your problem. By the time RHEL does it's next major release, you have a many-year jump in the underlying package versions with enough changes that even if you could do an automated update it would probably be a bad idea (there may be things as drastic as new filesytem choices, etc.). A fresh install of CentOS isn't difficult and you should have a plan to backup/restore your own data anyway, so once you get used to the timing it works out pretty well to match up major releases with replacing hardware and/or general cleaning up of your own applications and data.
First, CentOS does exactly what RHEL does, so this is not really a CentOS question.
The tradeoff is that Ubuntu doesn't go to the effort to ensure that for 7+ years you can do updates and not have anything that was previously working break because a change from the update. RHEL/CentOS may not be perfect at this, but breakage is very, very rare because the updates are mostly backported security/bug fixes that don't change behavior. Ubuntu does more frequent updates of the included package versions (even with their LTS version) and if a package changes behavior that is left as your problem. By the time RHEL does it's next major release, you have a many-year jump in the underlying package versions with enough changes that even if you could do an automated update it would probably be a bad idea (there may be things as drastic as new filesytem choices, etc.). A fresh install of CentOS isn't difficult and you should have a plan to backup/restore your own data anyway, so once you get used to the timing it works out pretty well to match up major releases with replacing hardware and/or general cleaning up of your own applications and data.
First, thank you to Les and the others for the information. You answered my questions clearly and concisely.
My replacement of the machine at home went from Fedora Core 6 to CentOS 6. Both 6's right :-). The old box had the power supply smoke (literally) and took out something on the main board so it would no longer see disks. The boot disk failed as well.
I kept Firefox and Thunderbird up to date manually with packages downloaded from the Mozilla site. Right at the end, I got to where they would not load because of shared object incompatibilities.
Why would someone wait that long to upgrade?
The machine at home is very different than the machines at work. At work, new project, new machine, new OS install. Get the latest version of RHEL and that is where that project stays. At home there is a lot more customization. I transferred my CD's to MP3 format and now buy MP3's from Amazon. As you know, I need a third party repo to get MP3 decoders. My machine now ties into my stereo and that is how I listen to music. Same sort of stuff goes for playing movies. Lots of other customizations as well. Projects come and projects go. I could not get xmms (with mp3) running on my CentOS machine. Eventually found "Audacious" which fills in nicely. And on and on.
The priorities yum plug-in does a real nice job of protecting my machine from being mutilated by third party repositories. Cudo's to those guys.
Bottom line, rebuilding a home machine is a lot more trouble than setting up a new machine at work.
Thanks again for the insights into the upgrade process.
Bob S.
On 02/25/2014 10:25 AM, Styma, Robert E (Robert) wrote:
I recently built a CentOS 6 system as my main machine at home. With a bit of help from members of this list, it is now working better than the machine it replaced (RIP). The new machine works so well, that I would like to convert some CentOS 5 machines to CentOS6.
I did some research on the web and the new install is still considered the proper way to upgrade CentOS. Same as Fedora and RHEL. The question becomes, "What makes the Ubuntu developers so clever that they can do major upgrades through their apt based update system?"
There must be some sort of gotcha or tradeoff involved in allowing this.
Does anyone have any insights on why they can get away with this while CentOS cannot?
The reason is this ...
You could work out a procedure to do an in place yum upgrade .. it would involve doing all kinds of stuff with python versions so that yum and the rpm database could live through the update.
Even after you did this, most of your data would not be usable. Because ..
In CentOS-5 to CentOS-6 look at php. You move from php-5.1.6 to php-5.3.3 ... almost none of the php websites would work after an upgrade.
Same for things like mysql in CentOS-4 to CentOS-5, it went from version 4.1.22 to version 5.0.95. Lots of things required to do this upgrade to the actual data.
So, if you upgrade in place, you get finished and you have a broken system until you figure out how to fix all of your data and config files .. and the difference is 3-4 years worth of in version numbers (unlike 6 months at most in a bleeding edge distro). Skip 2 versions (EL4 to EL6) and it is even more change (5-8 years of difference).
Distros that upgrade in place BREAK your one system and it does not work until you figure it out. Also, not every package in the old system exists or has a replacement in the new system, so you have orphaned cruft left on your machines.
If you upgrade onto another machine, you can do an install, move over your data and configs one by one, work out all the problems and get the fixes in, etc. You can move services one at a time, change pointers, never have downtime. If you upgrade i place, BAM .. down until you figure it all out.
I guess other distros that upgrade in place don't care that you are left with a broken system.
If you absolutely insist to upgrade in place ... boot the new DVD for the new version and at the command line do: linux upgradeany
That will let you upgrade in place and end up with broken data/configs with things that do not start, etc .. just like the other distros who do in place upgrades.
When it breaks (it will), then you get to keep all the pieces :)
-
Johnny Hughes -
Les Mikesell -
Styma, Robert E (Robert)