If your modifications are fairly limited in scope I recommend using the updates.img method. Basically you stuff the .py files you have modified into the updates.img file and it is searched before other sources when python goes to import a file. Place it on your network and add the line updates=http://path.to/updates.img to the kernel command line. Its a nice, elegant method to test your hacks and I have had good results with it. http://fedoraproject.org/wiki/Anaconda/Updates -Micah Parrish On Fri, 2008-07-18 at 18:32 +0000, Glenn Bailey wrote: > Hello all, > > I'm gonna be looking to modify Anaconda to allow it to fit more snugly in > the current environment I work in and had a couple of questions where to > start. I browsed through the Wiki the best I could, but couldn't really find > the best place to start. So I'll just start listing ;-) > > 1) In my current environment we do not track machines by MAC addresses, but rather > by chassis serial #. I'm wanting to modify Anaconda to be able to pull this serial > # via dmidecode, and then use that # as the kickstart file name. Can this be done > in the stage 2, or does it have to know what KS file to use in stage 1? In either > case, can I be pointed in the right direction for making such modifications? > > 1) If I roll my own Anaconda from the latest source provided can I use the same > source tree for RHEL 3, 5, and 5 as long as I create the proper stage1 boot? Or > would it be easier to just modify the existing source trees for each distro? Lookin > to do this RHEL distros only (RHEL and CentOS). > > Any pointers will be greatly appreciated .. ! > > Glenn > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
