CentOS - Sep 2011 - questions about upgrading

I'm pretty new to the task of upgrading CentOS or RedHat o.s.'s. 
I'm more familiar with upgrading Debian based o.s.'s.  Here are my
questions:

1) will yum ever upgrade the major version?  I understand that there is no
upgrade path from v5.x to v6.x, but is that always the case?  e.g. was there an
upgrade path from v4.x -> v5.x?  If yum is capable of doing so, what are the
command-line arguments necessary?

2) can I upgrade a minor version to any other greater minor number, or only to
the greatest?  E.g. if i have a v5.4 box, can i upgrade to v5.5 or v5.6, or only
to v5.7 (currently the latest)?

3) if an upgrade delivers a new kernel, am I obligated to run it (i.e. will the
old kernel remain installed, or will the upgrade remove the old kernel)?  If
not, does the upgrade automatically update grub such that the new kernel becomes
the default?  Will the upgraded box function properly without running the new
kernel?

4) aside from when an upgrade includes a new kernel, how can I tell when a
reboot is necessary?  I gather that a new glibc may require services to be
restarted, but is a reboot strictly necessary?

5) is there a way to apply only the updates that were made for the given minor
version you're currently at?  E.g. if I'm at v5.5, how can I only apply
updates that were made prior to v5.6's availability?

Thanks,

Jon

Jon Detert wrote:
> I'm pretty new to the task of upgrading CentOS or RedHat o.s.'s. 
I'm more
> familiar with upgrading Debian based o.s.'s.  Here are my questions:
>
> 1) will yum ever upgrade the major version?  I understand that there is no
> upgrade path from v5.x to v6.x, but is that always the case?  e.g. was
> there an upgrade path from v4.x -> v5.x?  If yum is capable of doing so,
> what are the command-line arguments necessary?
Never has been a full release upgrade path - that's a bad idea, too much
cruft.
>
> 2) can I upgrade a minor version to any other greater minor number, or
> only to the greatest?  E.g. if i have a v5.4 box, can i upgrade to v5.5 or
> v5.6, or only to v5.7 (currently the latest)?
Yum update *will* do that without a problem.
>
> 3) if an upgrade delivers a new kernel, am I obligated to run it (i.e.
> will the old kernel remain installed, or will the upgrade remove the old
> kernel)?  If not, does the upgrade automatically update grub such that the
> new kernel becomes the default?  Will the upgraded box function properly
> without running the new kernel?
No, you're not. It will update /etc/grub.conf (a link to
/boot/grub/grub.conf), and the next time you reboot, it will default to
the new kernel. It does remove the oldest kernel, but leave (I believe) at
least three (current, and the last two).
>
> 4) aside from when an upgrade includes a new kernel, how can I tell when a
> reboot is necessary?  I gather that a new glibc may require services to be
> restarted, but is a reboot strictly necessary?
New kernel.
>
> 5) is there a way to apply only the updates that were made for the given
> minor version you're currently at?  E.g. if I'm at v5.5, how can I
only
> apply updates that were made prior to v5.6's availability?
Tune /etc/yum.repos.d to point to explicity subreleases is, I think, the
answer.

           mark

> 2) can I upgrade a minor version to any other greater minor number, or only
to the greatest? ?E.g. if i have a v5.4 box, can i upgrade to v5.5 or v5.6, or
only to v5.7 (currently the latest)?
Yes if you configure the repositories in /etc/yum.repos.d accordingly
(i.e. use the vault).
> 3) if an upgrade delivers a new kernel, am I obligated to run it (i.e. will
the old kernel remain installed, or will the upgrade remove the old kernel)? ?If
not, does the upgrade automatically update grub such that the new kernel becomes
the default? ?Will the upgraded box function properly without running the new
kernel?
Kernels are installed side by side. For the second question, see
/etc/sysconfig/kernel.

In theory you should be able to mix and match any components from the
same CentOS major release without problems, unless any of the release
notes say otherwise. Whether it's a good idea is a different matter.
> 4) aside from when an upgrade includes a new kernel, how can I tell when a
reboot is necessary? ?I gather that a new glibc may require services to be
restarted, but is a reboot strictly necessary?
New glibc requires a reboot. Upgrading other system libraries does
too, but I can't give a definite answer on the how to tell. ldd
/sbin/init indicates the libselinux and libsepol packages are other
candidates, but that's just one example.
> 5) is there a way to apply only the updates that were made for the given
minor version you're currently at? ?E.g. if I'm at v5.5, how can I only
apply updates that were made prior to v5.6's availability?
See the answer to 2).

Other people will give you some flak for these questions as it's
generally recommended to run the latest version.