On Sun, Nov 6, 2011 at 3:56 PM, Yasha Karant <[log in to unmask]> wrote:
> Rather than hijacking the thread on vlc, I am posing this as a new set of
> questions.
>
> My understanding of the EL upgrade process, when moving from EL N to EL N+1
> (e.g. EL 5.7 to EL 6.1), there are only two ways to protect the information
> on the hard drives that have "systems" directories (e.g., / , /boot , /usr ,
> ... ).

Definen "protect data". A complete backup is usually the safest before
doing *any* such upgrade.

> 1.  Make backups of everything and restore after the EL N+1 installer runs,
> hopefully forgetting nothing of importance.

Common, especially if you plan to be stripping out unnecessary
services and configurations. You get a cleaner installation,
especially of "config" files with RPM updates leave untouched.

> 2.  Keep /home , /opt , /usr/local , and all other non-distribution given
> applications, configurations, and data, on separate partitions that are not
> touched during the EL N+1 installation process by using a manual override
> selection during the EL N+1 installation process.

Yasha, you keep making these strange and incomplete dichotomies. Our
favorite upstream vendor does a good job of following the File System
Hierarchy, and keeps system configurations in well-defined locations
of /usr, *not* /usr/local, and keeping system materials out of /home/

The fun and games occurs when someone's been adding out-of-band
packages, such as customized Apache layouts /home/httpd, or anything
written by Dan Bernstein that insists on its own "special" loations in
/qmail/, /djbdns, or various other inappropriately located base
directories. (It's an old sorepoint for folks who've maintained such
packages.) It also occurs when people decide to install multiple local
versions of core utilities in /usr/local/, such as keeping 4 or 5
different manually installed Java versions in /usr/local/java.

> 2.1  If these are not real partitions but are handled via the Linux LVM
> method, will these be respected or will these be overwritten?

Partition membership is irrelevant. It's a filesystem, and if the
partitions are mounted at installation or update time, they will
potentially be overwritten or even rebuilt from scratch. And if your
setup is complex or clever, mistakes become easy. This is why
separating bulky development areas to separate partitions or disk and
separate backup strategies are so helpful.

> 2.2  Is there any mechanism to force the EL N+1 installer to ignore certain
> directory trees that are not real partitions (e.g., do not touch /usr/local
> if /usr/local actually is on the same partition as /usr -- given that /usr
> in general must be overwritten to install EL N+1)?

Unmount them, and do not let the update procedures mount or
re-partition them. Be aware that if the update of software does seek
to make changes, for example by putting files in /usr/local/ with
software from a File System Hierarchy violating 3rd party repository,
and the partitions are not yet mounted, the changes will be concealed
by the mounting.

> As an aside, when I do this, I keep many things from the EL N installation,
> including many configuration files in /etc so that these can be quickly
> reinstalled.  I personally accomplish this by copying these to a
> subdirectory of a directory for a mount point for a filesystem that will not
> be touched (e.g., /home/prevsys/etc with /home on, say, /dev/sda10), using
> cp -pr to save the required permissions.

I do an rsync based backup of /etc and /home to another host, plus any
relevant config directories from /opt or /usr/local as needed.

> These days, I make certain that each physical partition that will be
> reformatted/overwritten by the EL N+1 installer is large enough to
> accommodate the typical growth (bloat?) of the new major release.

Well, yes. This is where it's helpful to simply have a complete backup
to restore from. In particular, the new SL 6 structure for naming
logical volumes with the hostname included is very helpful in virtual
environments, allowing the mounting of partitions on the hypervisor or
with the disks transferred to a new host to be much simpler and avoid
conflict with existing logical volume names. But if you're upgrading
from SL 5.x to SL 6.x, you won't inherit this. You'll need to
repartition or play serious games to get that kind of feature.

Mind you, it's often much simpler and quite effective to simply use
the "upgrade" features built into the DVD's or kicstart setups. You'll
miss out on a few features like the volume naming, but our favorite
upstream vendor has done a very effective job of preserving
configurations across upgrades without having to do a complete
rebuild, by carefully managing config file updates and providing
update tools for databases.