From Fedora Project Wiki

< Anaconda

Revision as of 09:52, 18 March 2009 by Jgranado (talk | contribs)

Testing dmraid in fedora installer:

What we are testing

I think the easiest way is to list the tools that we are to test/use:

  • pyblock : This is the package responsible of handling dmraid and mpath in the installer. This is our main target for the test day.
  • dmraid : pyblock uses dmraid libs heavily. In light of this fact, this package is also included in the tests.
  • device-mapper : dmriad and pyblock use heavily this package, so its also included. Although I don't expect any trouble from this one :)
  • mkinitrd : if the installation does not correctly reboot, its usually mkinitrd

What we are NOT testing

  • mdraid is handled differently then dmraid and mpath in the installer. This is NOT our target for the test day.
  • installation paths that do not include dmriad.
  • F10 related issues. (code wise, F10 is ancient history :)

Stuff that you need for the test day

  • A machine that is capable of having raid {0,1,5,10} setup from BIOS
  • Lots of disks would be nice. (this way we can get more raid types tested)
  • Access to latest rawhide installation trees. It is very (VERY) important that you have the latest rawhide. I know that latest is relative to your prefered mirror, but if everybody is in a range of a couple of days, it will be enough, I guess.

State of things in Anacondsa

We are rewriting the partitioning code, so tests that where done in f10 and down are not relevant. Moreover, anything that is not as current as git HEAD for anaconda-storage-branch (;a=summary) is not relevant. Me (jgranados) and Hans de Goede have been rewriting the dmraid stuff for new storage anaconda code. We got to a point where we could both complete the install. We are looking to iron out issues that we missed. ATM, anaconda is not 100% finished, so not all the installation paths will work. We are working hard on getting this in for f11 and this test day is part of that effort. So be prepared to encounter lots and lots of tracebacks.


Since we are dealing with stage2 code ( everything can be managed with updates images (


1. provide an initial updates image.
2. Identify issues in behavior with current update image
3. propose patches fixes
4. create new update image.
* repeat 2-4 until we are satisfied.

Updates images

There will be two update images. One for x86_64 and another for i586.

x86_64 :
i586 :

these images will have the latest stuff being worked on. It contains pyblock stuff and most of the anaconda files that are being touched for the storage rewrite. Every time the images are updated we will inform on irc channel (#anaconda).

Extra info

  • Date : 18-Mar-2009
  • Time : 0900 UTC - 1700 UTC
  • place : #anaconda (Freenode)
  • People:, and