On Sun, Nov 6, 2011 at 6:42 PM, Yasha Karant <[log in to unmask]> wrote:

> I have been informed that "update" will not work from EL N to EL N+1 for
> major releases, only for minor sub-releases (EL 6.0 to EL 6.1, etc.). Major

That's odd. I've done it successfully for.... about at least 500 Linux
servers in the last 4 years my career. It does take installation media
or a good PXE/kickstart setup, because the changes in glibc and RPM
itself can wedge things awkwardly without special handling. There are
very real risks, which is why you need the backups or good
configuration management.

> releases require a full install, as though one were using a completely new
> hardware system.  My personal backup technique these days is simply to buy a
> new disk, clone it from a working one using dd, and then if I must install
> to overwrite, bring up the backup disk on an unused disk controller
> interface connection, and copy (cp -pr, cpio, tar, etc.) files and/or
> hierarchies from the archived backup to the production disk.  This is
> feasible today because of the relatively low price of the bare harddrives,
> and necessary in my case from my workstation or laptop because I do not have
> access to a high throughput channel to a disk farm server (e.g., a NAS).  At
> low throughput, the task simply takes too much real time -- what will work
> for a few Gbytes in terms of real time is not feasible for a Tbyte or more.

Consider using "cp -a" or "rync -avH". Both copy hardlinks as well as
file contents very effieiently and are easy to update. It's also handy
to use something like "rsnapshot" to a secondary repository, which can
be incrementally and efficiently updated before and after the
migration. There's nothing quite like accidentally deleting an old
file you needed, and being able to hit your snapshot backups for the
copy you used to use.

> Moreover, during the major release upgrades, my understanding is that / ,
> /usr, and other systems directories that are the mount points for the
> underlying partitions containing file systems are automatically reformatted
> (erased) or the upgrade will fail.  I believe that I have email from Connie
> Sieh on this very point.

No, it's an *option* to preserve the old material and update in place.
Did this a few days with SL 6.1, quite effectively, from SL 5.4,
testing out a kickstart setup.

> Do I understand you correctly that LVM works the same as physical
> partitions, and that particular logical entities (e.g., the LVM analogue of
> physical partitions) can be exempted during the full install of a new major
> release?

It gets awkward if you do an upgrade: you might have to declare the
logical volumes "inactive" to protect them from an "upgrade"
operation. If you do an "install", you can select your partitioning
manually with arbitrary cunning. Unfortunately, 4096 byte block
alignment remains an adventure. The GUI's don't support block-specific
partition settings that might benefit performance if the
virtualization server hardware is 4096 byte block aligned, and the
emulated hardware is not. But bring that up sometime if you need it.

Manual partitioning setups are easy to screw up, which is a very
powerful reason to do a good backup first.