Bug 124369 - Need ability to specify partition that is created iif the partion does not already exist.
Summary: Need ability to specify partition that is created iif the partion does not al...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-26 00:48 UTC by James Olin Oden
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-08 19:44:49 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description James Olin Oden 2004-05-26 00:48:32 UTC
Description of problem:
Presently, you can specify that a partition be created, or that it 
should already be created.  It would be very helpful to have the 
ability to specify that it should be created iif it does not already 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
A particular use I have for this (and I would imagine others could 
use this strategy), is to have an application partition created 
that if you re-install the system will not be removed.  System 
partitions are wiped clean but this application partition that has 
databases or other application data persists.  We do this already, but
in a very hackish way, involving creating all partitions in a %pre 
scriptlet, but never re-creating ones designated as application 
partitions.  We then tell anaconda only about the system partitions, 
and handle creating the volume group and logical voluems that go on 
the application partition after boot.  Providing the mechanism 
described would make this process much more straight forward, and I 
think be usefull for others (having a persistent data partition on a 
home machine is not a bad thing).

Comment 1 Jeremy Katz 2004-05-26 14:47:29 UTC
Like I said in my reply to your mail on this, I'm not clear on a) the
semantics of this or b) how generally useful it is.  I might be
missing something, though.  Could you attach the bits of your %pre
that do it -- that might make things more clear.

Comment 2 James Olin Oden 2004-05-27 13:51:09 UTC
First here is a possible syntax:

   part /home --onpart=$dev --persist

Where if you used the persist flag, it would creat the partition iif
it did not exist already.  If it did exist then it would use the one
that was already there.  Maybe --persist isn't the best verbage.  
Conceivabley cleartpart would interact with this in one of two ways:

   a) If you have --persist on any of your partition definitions it
      and specify clearpart this would be considered a fatal error, 
      and the install would fail to start.
   b) clearpart would only clear partitions that were not marked 
      with --persist (which is kind of what our %pre script does).

I would think that this would be very usefull because you could 
completely reinstall the OS, but not have to restore backups of 
application/non-os data (does not mean someone should assume they 
should not backup their data though (-;).   For example, at Tekelec,
we create several OS/Platform partitions.  On a re-install these are
all removed and recreated.  We allocate the remaining portion of the
disk for one volume group we call VGApp.  This volume group actually
lives on a md device that is raid 1.   Our %pre script knows where the
platform partitions end, and thus on a re-install (unless we override 
this through command line optioins at the boot prompt) we do not 
touch the application raid partition.  Such that if there application
is designed correctly, we can re-install the app, but not have to 
restore a backup.  This is potentially might helpful in a major 
upgrade where, really the best thing to do is completely re-install.  
It also saves much time thus allow us more to time to completely
backout the changes if necessary (we get about 4 hours typically to 
upgrade and if necessary backout an upgrade of a set of machines).

As for the code snippets, I'll have to talk to my boss.  Our %pre 
script is very simple, in that it calls another script that we have
stuffed into the initrd.  That script is the one you want to see, and
its a bit lengthy, as its written bash (oh, that we knew python 
better, or you guys switched to perl (-;).  If I can send it to you, 
I will to your email account if that is OK with you.


Comment 3 Jeremy Katz 2004-06-08 19:44:49 UTC
One problem with this is that I don't do any guarantees about
partition naming (ie, I can't say that you'll definitely get hda3 --
parted doesn't provide that functionality since the numbering is
basically irrelevant).  

I also don't really like how this sort of has to interact with
clearpart  -- if you're wanting to wipe other partitions, then
clearpart really needs to wipe all but the --persist partitions and it
just gets to be fairly ugly fast.

I think this is going to be relegated to the realm of %pre + %include
exist for a reason :)

Note You need to log in before you can comment on or make changes to this bug.