Plans for anaconda LVM/RAID support

[Vratislav Podzimek]

On Thu, 2012-10-25 at 12:04 -0700, John Reiser wrote:
> On 10/25/2012 09:55 AM, Ken Dreyer wrote:
> > On Thu, Oct 25, 2012 at 10:53 AM, Matthew Miller
>    [snip]
> >> It is often useful in enterprise settings to do non-kickstart installs while
> >> prototyping. *And*, people running Fedora in those settings probably *are*
> >> prototyping. So, this seems like an important use case to me.
> > 
> > I agree with this. It's also quite a simplification to say that
> > kickstart only involves writing a single text file :)
> 
> I see a couple other things here.  Anaconda doesn't inter-operate well.
> The interactive graphical part has no provision for writing "the kickstart
> file so far", so that is cumbersome to adapt: I need multiple passes.
> (How do I invoke anaconda with a partial kickstart file, use interactive
> features, then write the revised kickstart state, and stop?
> There should be a syntax-and-semantics-aware "kickstart editor".)
> And, if what I want is guided generation of a kickstart file,
> then that should be an ordinary app (with root privileges to
> discover any existing configuration, but inhibiting all partition creating
> and formatting), not a stand-alone installer.
The best thing (from my point of view) of the Anaconda rewrite is that
this is finally possible and will be available. Anaconda itself now
stores almost nothing in "non-kickstart" structures and from the
configuration screens to the progress one basically kickstart is passed
(as an in-memory structure, not in textual form). Checking if argv[0] is
"system-config-kickstart" (or whichever name) and exporting kickstart
instead of actual installation is an easy step.
So you will be able to pass Anaconda a partial kickstart add some stuff
interactively in the GUI (and in a bit farer future also in the TUI) and
quit it generating new, partial or complete, kickstart.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic