[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: F11 Preview - test with usbkey - upgrade partitions

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 

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]