From Fedora Project Wiki
(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,...')
 
No edit summary
Line 10: Line 10:


* How do we prompt for method?  That screen is in loader, which would not show up in the image install path.
* How do we prompt for method?  That screen is in loader, which would not show up in the image install path.
** The wizard as described above could collect that info and then fire up anaconda with the correct --method parameter? (dcantrell)
* The authconfig, firewall, and selinux parts would be lost.  anaconda doesn't have UI for those.  On the other hand, we gain LVM support.
* The authconfig, firewall, and selinux parts would be lost.  anaconda doesn't have UI for those.  On the other hand, we gain LVM support.
** I don't think that's a big loss.  My thought for kickstart generation is something that can give people a kickstart to further customize, such as what they already get from things like s-c-kickstart or simply running anaconda and then using /root/anaconda-ks.cfg. (dcantrell)
* 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.
* 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.
** The wizard as described above could be part of s-c-kickstart.  Users could use it to fire up anaconda in kickstart generation mode and then on exit, it returns them to s-c-kickstart with the data loaded for editing.  Make some changes and then fire off another test run or something like that.  An edit/execute mode, so to speak.  (dcantrell)
* 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?
* 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?
** In addition to resizing, I think there would be a lot of other things that would still have to happen before we could just execute one giant transaction.  It seems like a good idea and if storage technology were not so complicated, I think it would be doable.  (dcantrell)


-- Chris
-- Chris

Revision as of 17:22, 15 December 2010

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 wizard as described above could collect that info and then fire up anaconda with the correct --method parameter? (dcantrell)
  • The authconfig, firewall, and selinux parts would be lost. anaconda doesn't have UI for those. On the other hand, we gain LVM support.
    • I don't think that's a big loss. My thought for kickstart generation is something that can give people a kickstart to further customize, such as what they already get from things like s-c-kickstart or simply running anaconda and then using /root/anaconda-ks.cfg. (dcantrell)
  • 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.
    • The wizard as described above could be part of s-c-kickstart. Users could use it to fire up anaconda in kickstart generation mode and then on exit, it returns them to s-c-kickstart with the data loaded for editing. Make some changes and then fire off another test run or something like that. An edit/execute mode, so to speak. (dcantrell)
  • 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?
    • In addition to resizing, I think there would be a lot of other things that would still have to happen before we could just execute one giant transaction. It seems like a good idea and if storage technology were not so complicated, I think it would be doable. (dcantrell)

-- Chris