On Wed, 2005-09-14 at 04:23 +0200, Albert Strasheim wrote: > I have some ideas for improving Anaconda for "not physical hardware" > installations. There's a difference between things like live CDs and stateless vs something like Xen... more later. > Kadischi is currently being built as a shell script that calls Anaconda > from the command line. However, there are already some patches in > Kadischi's CVS to add a command line parameter to Anaconda to enable > Kadischi to skip certain installation steps. Yep -- would be good to actually see those patches here to pick apart a little. > I took apart Anaconda 10.2.1.5's /usr/sbin/anaconda to see what it would > entail to build something like Kadischi on top of the Anaconda code. I > was left with a script containing about 350 lines of code that could > install the Fedora Core 4 RPMS into a directory using Anaconda's > command line, text and graphical modes with or without a kickstart > configuration. The anaconda script definitely has its crufty parts where it's grown somewhat organically over time. At the same time, a lot of it is needed for "real" installs. So I don't think I'd attack this side first... > This goes a long way towards handling installation for Live CDs, Xen > guests and "normal" chroots. For example, I used this script to > "install" Fedora Core 4 to a directory. I copied this directory to a > Rocks Cluster 3.3.0 (based on RHEL 3) system, chrooted, started sshd, > set up yum and added a user. I was able to ssh to this chrooted system > and develop code with GCC 4.0.1 without changing the existing system > (and this on a 2.4.21 kernel!). chroots for builds are really handled far better by a tool like mock, imho. They don't really have the constraints of being full running systems and often-times, don't really want them. Things that you don't need in a chroot that you need on a more "full" system include things like boot loading, network configuration, a fstab, running of init. Anaconda is good for the case where you end up needing the latter types of stuff (Xen, LiveCD, Stateless, real system) > However, the various installations mentioned above all have slightly > different requirements at various stages before and after the packages > are extracted. Some changes to Anaconda will make all these scenarios > easier to implement. So far I've identified the following: > > - There needs to be a flag other than setupFilesystems to tell Anaconda > to run things like authconfig and lokkit inside the chroot. Yep, sounds about right. A lot of it should be keying off of flags.test these days instead of flags.setupFilesystems. Cheerfully accepting patches to do so :-) > - There needs to be a way to add new installation steps. As far as I > can tell, the list is currently hardcoded in BaseInstallClass. This is definitely an area which has (traditionally and forever) been a pain. Adding a step requires changes to: * installclass.py * dispatch.py * gui.py * text.py * kickstart.py I had a patch a few years ago that made all of the steps able to independently describe themselves so that you could add your own more easily. I went a little overboard, but something more constrained would definitely be useful and worth working on. > - Anything else? > This will allow much greater customization of Anaconda. Kadischi can add > a step telling the user the approximate size of the final CD. A USB > flash disk installer can ask whether locales should be excluded to save > some space. A Xen guest installer can prompt for an image filename to > install the files to. All of this should be possible without changing > Anaconda itself by creating new modules that add install steps. > > Is anybody working on this already? If not, is anyone interested in > working on this? No one's working on this in particular. I'd say that working towards the ability to more dynamically handle steps would be quite welcome and we can help you get to where it's in a merge-able state. > Anybody working on Xen guest installs with Anaconda? Something that's very much a problem with Xen that doesn't really apply as much for the other cases (like livecd) is that you need to be able to support all of the features of the guest in the host to do installs. This is often not the case.[1] So you really want to do the installs for Xen inside of a guest. Which makes a lot of your concerns less prevalent for Xen. Things such as the target disk/image filename need to be handled in your external VM control program (which also handles start/stop, etc). Some of the basics of how I'm intending for things to work is at http://fedoraproject.org/wiki/Anaconda/XenInstall. Right now, I'm being held up by some hangs when using full-disk vbds. Jeremy [1] Examples are things like SELinux, enhanced ext3 features, LVM, ... If your dom0 isn't the same OS as your domU, then you have problems.
