From Fedora Project Wiki

< Talk:Anaconda

Revision as of 21:14, 13 December 2010 by Clumens (talk | contribs) (Created page with 'I did a little bit of thinking about this today, and here's what I came up with: * I think we want to run this through data/liveinst/liveinst like the image install method does,...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

I did a little bit of thinking about this today, and here's what I came up with:

  • I think we want to run this through data/liveinst/liveinst like the image install method does, instead of as a VM. Requiring a VM (and therefore, kernel and initrd) seems like a lot to require of the user.
  • You'll need to define what disks are attached up front, before starting anaconda. This will require some small piece of UI that we can perhaps share with the image install method.
  • We will need some custom anaconda parts to skip applying partitioning, doing package installation, and doing post-install config.
  • Requiring custom anaconda parts means liveinst needs to grow --updates= support.
  • I see this working best as a wizard - define your disks, then say we're going to fire up anaconda, then do it, then present the finished kickstart file.

And then there are some problems:

  • How do we prompt for method? That screen is in loader, which would not show up in the image install path.
  • The authconfig, firewall, and selinux parts would be lost. anaconda doesn't have UI for those. On the other hand, we gain LVM support.
  • How do we allow for loading and editing an existing kickstart file? This seems like a perfect application of the interactive command, which no longer exists.
  • Perhaps this would be best done if we convert anaconda to run through all the information gathering steps first, and then apply everything. Then kickstart generation mode is just running the first bit and quitting before application. Of couse if we do this, what do we do about resizing?

-- Chris