From Fedora Project Wiki
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 that can be passed to liveinst via --updates= (will need to modify liveinst to check its own command line in addition to /proc/cmdline) to skip applying partitioning, doing package installation, and doing post-install config.
- 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)
- If we do care about some of these pages, it should be easy to whip up extra iw/ and glade files, include them in the updates image, and add their steps. Then they'll be seamlessly included in anaconda. (clumens)
- 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)
- I'm going to have to subclass things in anaconda and use an updates image anyway. Given that, this might be as simple as resetting the dispatcher's step list to not skip everything after the kickstart file is processed. I could also use an installclass to make resetting easier. This class could either live in anaconda or in s-c-ks - the latter may make more sense given the above. (clumens)
- 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 course 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