[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Hacking anaconda

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


-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 redhat com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]