I was waiting on what solution worked for you, from the various recommendations, before commenting further. I am glad you found something that worked for you in the end.
I used to do deployments for years as you did, create a new, updated repo which I would install from directly. I especially did this for the pre-Red Hat Linux days, and before Anaconda was YUM integrated. Back then, one had to use the tools in the package anaconda-runtime to update the installer for the new packages. Today, YUM-integrated Anaconda (it's all Python after all) removes such a requirement. Just creating a YUM repo, with the required comps.xml for groupings, will do. I've also customized the comps.xml to add groups at various organizations. But also today, in the Enterprise Linux era, I typically still install the "GA" Update kernel (e.g., 2.6.18-x for EL5, 2.6.18-x for EL6), and then update afterwards with the errata kernel (e.g., 2.6.18-x.y.z and 2.6.32-x.y.z). I can think of many reasons for this. But one, big reason is for kmods that may not directly resolve and/or load on an errata kernel. Having the original, "GA" kernel works well one when one has 3rd party kmods, and automation (e.g., weak-modules from module-init-tools) loads them on errata kernels. kABI compatible kmods should load without symbol issues, especially under the same update. This is especially the case when I have moved on, and a customer (or, more often yet, ISV) introduces kmods after I'm gone. In fact, I typically educate the customer that even when updating a system, they should consider loading both the "GA" kernel for the update and the latest errata kernel. So even if you spin your own repo with updates, to save installation time, consider installing both the "GA" and latest "errata" kernel. Just food for final thought. ----- Original Message ----- From: "Musayev, Ilya" <imusa...@webmd.net> To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list <rhelv5-list@redhat.com> Cc: Sent: Wednesday, October 26, 2011 2:14 PM Subject: Re: [rhelv5-list] Kernel update via kickstart on rhel5.7 I've tried several methods of using latest packages in kickstart. That is, I specifically defined the repo like this: repo --name=Updates --baseurl=nfs://my-nfs-server:/media/linux/RHEL5U7_x86_64/Updates I ran createrepo in Updates dir first without using group file and second with defining comps.xml group file (-g option). In both instances, anaconda said it will ignore non-base repo or cannot find repomd.xml. I confirmed it was accessible. My solution was to replace the Server directory (from iso) with my Updates directory (that was created with -g option). Needless to say, my kickstart server uses RHEL5.5 kernel/stage2 to deploy RHEL5.7 OS, if it is ananconda bug, it was probably addressed in later release. Either way, missing accomplished, I'm able to deploy the OS with all recent packages as intended - without the need of the upgrade - which would double the time of OS deployment. Regards ilya -----Original Message----- From: rhelv5-list-boun...@redhat.com [mailto:rhelv5-list-boun...@redhat.com] On Behalf Of Jason Edgecombe Sent: Monday, October 17, 2011 6:21 PM To: rhelv5-list@redhat.com Subject: Re: [rhelv5-list] Kernel update via kickstart on rhel5.7 On 10/17/2011 09:43 AM, Greg Swift wrote: > On Mon, Oct 17, 2011 at 07:29,<vinc...@cojot.name> wrote: > >> On Sun, 16 Oct 2011, Musayev, Ilya wrote: >> >> I would agree with you if this would be an existing OS, but since it's a >>> fresh install and we burn tested the kernel, why keep both? >>> >> I tend to agree and most of *my* recent experience on RHEL5 and RHEL6 has >> proven this true to some extend, especially if it's a fresh install. >> >> That being said, since it's a kickstart install and if you own the >> kickstart server, why wouldn't you simply -replace- kernel-2.6.18-274 rpms >> with kernel-2.6.18-274.3.1 rpms in the tree (along with its dependencies, if >> any and rebuilding the comps and friends ). I used to re-base distribution >> trees this way since at least RHL 6.1 (not RHEL). :). >> > if you provide your custom built kernel in a repository that is enabled in > the kickstart wouldn't that mean the installer would automatically use the > latest (which yours hopefully is always numbered to be) and not require > extra work (and scripts) to handle? yes, that's correct. > repo --name=my-rhel5-kernels --baseurl= > http://kickstartserver/repo/myrhel5kernel > > I guess if you aren't keeping your custom build newer than the install > source it would be better another way, this just seems like it would be more > efficient since it seems to solve most of the discussion without worrying > about a post script or whether to have both kernels installed. > If your custom kernel RPM isn't newer, then you can still explicitly use the full kernel+version name (i.e. kernel-2.6.18-192.8.1.x86_64) in the %packages section of the kickstart file. I don't recall if the newer version will be installed in addition to the specified version. If both are installed, just remove the newer one in %post. Jason _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
