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. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
