Anaconda Wiki

Greg Morgan drkludge at
Fri Jul 29 09:04:50 UTC 2005

Hash: SHA1


I decided to copy the anaconda ks list after I finished writing the
notes below.

Klaus Steden wrote:
> Hello,
> I would like to contribute something to the Anaconda Wiki.

That's great news.
> I have developed an approach for inserting code (not just '%pre' stuff) into
> the kickstart procedure, and a number of people on the kickstart list have
> asked me for more info. I thought it would be easier and more helpful if I
> were to make this info available through the official Anaconda channels,
> rather than emailing a bunch of people and having the info get lost in the
> ether.

That sounds very interesting.

> I understand that you maintain this section of the Fedora Wiki; what is the
> best way to get this info online (if you think it's a bad idea, feel free to
> tell me to go lump it :>).

Go here

Do this....
Welcome to the [WWW] Fedora Project Wiki. The purpose of this wiki is to
provide an external resource for Fedora Developers and Users inside and
outside of Red Hat to share information and work together on plans. In
order to help in the editing you must first setup an account by going to
UserPreferences. After that, inform someone within the EditGroup, so
that they can add you.
...please let me know when you are done so that I can add you.  MoinMoin
 likes "CamelCase" wiki names and user names i.e. KlausSteden, if you
are not familiar with wiki links made this way.

Klaus..It would be great to have you contribute what you'd like.  The
Anaconda page is located here I
started converting the rau wiki with notes here  Then I decided half way
through that Mr Rau was in process of revising the wiki and I was trying
to convert two pages per page in some cases.  I also realized that the
Rau wiki covered just part of what anaconda needed in the way of
documentation.  I have been trying to get this wiki, ,
 to a place that I can switch back to the Anaconda wiki.  I am Dr kludge
on that wiki. ( is having mysql database resource issues
right now so the wiki paints slow.  You may have to click the links twice.)

Anyhow, It looks like Jeremy Katz has recently reorganized the anaconda
focus along similar lines to what I have been thinking

1.) A Basic CD install was needed. Stuart Ellis and Paul W. Frields have
created an updated CD installation guide here Docbook drives me
crazy at this point but that's where the doc project would like to take
all the documentation in the wiki too, if you didn't know.

2.) A linux prompt cmdline boot guide.  New users don't always know how
to combine the basic encyclopedic list of parms into something useful.
The section needs to be "cookbook oriented".  One of these topics would
include creating an install tree and show new users how to install from
that or how to use the iso directory method.

3.) The install tree topic could then be a segue into remastering the
Fedora distribution.  There are a whole bunch of small skills a user
needs to learn to know how to remaster the four CD Fedora set into one
CD, for example.  Remastering may be the place to talk about creating
install classes.

4.) There needs to be a demo section on how to create a kickstart file.
 There's pieces all over the net on how to create the kickstrt file.
 One problem is that people don't understand that they have a live
machine that they can script at two points during the installation.  So
I thought of taking (they just released 4.5) or as an example project.  You
see if you create an install tree, or remaster the CDs you can put all
the files you need on the last CD and script the rest of the install of
the application on the new Fedora box.  Although I have not tried it
yet, I believe yum can be used in the kickstart %post section.  That may
be another way to handle this in the having additional files available
in the post section.  The demo would show a person how to collect all
the pieces to create a kickstart file.  This guide would
also then refer back to the command line section of part two.  It looks
like you have some interesting ideas for this area too....go for it.

5.) Part three is also a segue into the last part that is
required for exposing all of Anaconda.  This is the section on how to
obtain the sources and modify both the phase one C boot code and phase
two python installation code.  I think presenting the ideas in the order
above would help make mastering the programming learning curve easier to
handle.  I started using MoinMoin wiki at the beginning of the year.  We
ran into space problems on  I created my very own
denial of service with the MoinMoin wiki on SourceForge.  It saves a
whole copy of each document that is changed for diffs. There's a 100 meg
limit on SF's web server. :P  Anyhow we had to switch to MediaWiki.
MediaWiki is the wiki engine behind and all of
its sister projects.  I have come across some interesting tools that may
help document the data structures used in Anaconda. In the link earlier,
msg00064, Jeremy mentions the comps file documentation  I am thinking of some
key pictures of the comps file using graphviz code would help the
documentation.  I have been playing with this idea here
and here
Many new users get mixed up on the document root of a web server and
this picture may help me revise the document once again. As noted in the
Graphviz_Code page MediaWiki has extensions that takes graphviz code and
generates both the web image map and graphic on the fly.  Then anyone
can edit the graphic without having to have gimp or dia tools.  The
packages for graphviz and ploticus are in extras, by the way.  Anyhow,
key pictures can be generated with the CLI tools and put in the web
pages.  I am not yet sure where to upload graphics to the fedora wiki so
that they can be included in the wiki pages, yet.  I think the graphics
would be a nice touch for both the install tree and comps documentation.
 I used the pl code from the LJ article below to generated the initial
images and then revised the file.

6.) Finally, The last section is to create a wiki FAQ.  So if you look
at this page you
can see how I am using actual questions from forum posts to create the
question.  Then if you click on the link, it will take you to the
answer.  The answer is then in the context of the other surrounding
documentation.  You only have to maintain the answer in one spot and not
two as with other FAQs. I believe MoinMoin can do something similar.

I did not understand wiki's until around November 2004.  Now I wonder
why I haven't used them before now.

Here's a link to a new page that I am writing on a new wiki module for
phpWebSite that Blindman1344 has authored.  It sums up my thoughts on
wiki use for the last six months that I have used 'em.

* Use the release early and release often creed.  Unfortunately, the
page may look like a mess at first but eventually it all pulls together.

* Take the good parts of emails like this to begin a document.

* Wiki's make it easy to revise and reorganize.

* Don't be afraid to help revise other people's work.  That's the whole
point of a wiki is that it is a team effort.

* Don't be upset if other people edit your work.  It's a team effort.

* Wiki's have diff engines and history pages so you can see how you or
other writers have made.

* Try to find a way to build a community around the wiki.  This email is
an attempt to draw more people into the Anaconda wiki.

Here's some links that may be helpful.


Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the Kickstart-list mailing list