On Mon, Oct 25, 2010 at 5:53 PM, David Cantrell <dcantr...@redhat.com> wrote: > On Wed, 20 Oct 2010, Nico Kadel-Garcia wrote:
>> It's non-standard for RHEL installations, but it's a lot faster and >> uses a lot less bandwidth for cluster installations. I've been using >> it to redeploy clusters and have fully defined test environments, >> without having to rewrite kickstart operations, for years. Unwrap the >> tarball, chroot to it, make changes, exit the chroot, then bundle the >> new tarball. Voila, new date stamped OS image. > > You say you've been doing this for years, so I'm curious as to what > particular > configuration settings and interactions are troublesome for you in anaconda. > The decisions that anaconda makes are not arbitrary, but rather done to make > sure we have a consistent experience for all users across all platforms. > Certain ways of doing things are simply not supported in the installer, > because we want to make it clear what the intended installation path should > be. I gave David a much longer private note with a list of outstanding Anaconda issues. In short, many of the "intended installation paths" have been unfortunately curtailed. Others go the long way around. I'll give one example of each here. * Curtailed. Anaconda does not store the actual ks.cfg file used in a kickstart installation, it stores what it derives to somewhat resemble the structure it has worked out with you. The result is that for systems that have multiple '%pre' or '%post' scripts, those are discarded and the host has no record of what what was actually used. This is an *old* bug, and one I've complained about, in service tickets, for years. * The long way around: the overall package selection system. The base install is *way* too big, and includes numerous unnecessary packages. (How many *different* ways to we need to allow RedHat to dynamically commit updates from RHN? Seriously?) This mandates going back and yanking out unnecessary daemons and components in a %post script. _______________________________________________ rhelv6-beta-list mailing list rhelv6-beta-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv6-beta-list
