On Thu, Apr 30, 2009 at 06:12:07AM -0700, Mike Cloaked wrote:
A couple of points:
The first reference is really to an "upgrade" of an existing system - what I
do is to do a clean install but leave the /opt partition ( and which
contains a subdirectory home that I bind mount to /home in the root
directory. Before configuring the new system a yum update is done to ensure
any post release fixes are in place for the system as a whole. Also prior
to doing an install of a newer system, I make a backup or /etc and /var and
then run a clean install (which includes reformatting the / partition so it
is really clean) rather than an upgrade.
However I would be interested in hearing how others achieve their change to
newer versions of Fedora?
I've started keeping space for two (sometimes more) separate boot and
root partitions on all my systems. That way I can format and do a
fresh install on one of them for the next Fedora release, while
keeping my current stable release intact in case there are problems.
Disk space is cheap these days, and you only really need about 8-16
gig for each install's / partition--leaning towards 16 gig these days,
but that still beats the 32+ gig that Vista wants to even do a basic
install.
I always share a single 2-4 gig swap between all installs.
In most of the rest of the disk space I keep a separate /home
partition that is shared between the installs, but I backup the
dot-files in each home directory before booting a new release, just in
case the configuration settings aren't forwards- or
backwards-compatible, so I can go back to the old stable release by
restoring the dot-files if necessary. I'm usually the only user, so
this isn't so complicated as it might be with a multiuser system.
I use an LVM setup with an encrypted Physical Volume and keep the /'s
and swaps on there. Sometimes I've kept /home on there as well, and
sometimes I've made a separate LVM Volume Group for /home (although
this slows down boot if encrypted separately, since there needs to be
two luksOpen's instead of just one). In either case, I leave some
free space inside the LVM Volume Groups that aren't allocated to any
Logical Volumes so I can grow either the root partition(s) or /home as
necessary. I've done online filesystem resizing on LVM and LUKS
encrypted PVs or LVs and it works great. Shrinking is harder since it
can't be done online, hence the decision to always leave free space
for growth from the start.
Another strategy I've used in the past is to leave room for a few
/boot partitions at the beginning of the disk, and split the remainder
of the disk into multiple equally sized PV partitions, from 3 all the
way up to 10 in one case. The reason for doing that was to allow for
flexibility in reallocating PV space from one VG to another, in case I
decide that the "system" VG or the "data" VG needs more space. This
method has fallen out of favor with LUKS, though, since you really
want to limit the amount of separate LUKS containers (PVs or LVs) you
have due to the aforementioned slowdown during bootup--at least on
systems that are booted often (laptops).
Finally, I've combined the above strategies with software RAID
mirroring (mdraid RAID1) on two disks for redundancy of my data. It
has already saved my butt several times.