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):
Steps to Reproduce:
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).
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.
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.
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
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 :)