From: Ajay ajay@unisoftindia.net
A new hdlist and hdlist2 is sucessfully regenerated in CentOS/base dir with a small reduction in file size of hdlist, but the network install fails at the end of "Preparing RPM transaction" screen with the message "install exited abnormally" and shuts down. Am I missing something?
I've had this happen when there is a conflict between some core packages. It's a PITA to resolve because, as you found out first-hand, you don't know it until you're half-way through an install.
My approach has been to only add packages I know are safe and won't conflict with core FC/RHEL packages, and then install any additional from either an internal APT-RPM or YUM-RPM repository.
I typically do the latter to fetch system updates anyway, including creation of RPMs for key configuration files (and updates). E.g., "CONFIG_BS-2.1.noarch.rpm" (the package name conviniently matching my initials if anyone hasn't noticed that yet ;-).
From: Sean O'Connell oconnell@soe.ucsd.edu
Ajay- It would be far simpler to setup a yum repository for the additional packages, create a custom yum.conf (or repo file for the repo), and then install that yum.conf or repo file in %post and then follow that up with a yum -t -y install foo bar baz
I remember Seth talking awhile back on a Fedora list about the next generation installer (Anaconda-based?) being able to pull from YUM-RPM repositories at install-time for network installs.
Has anyone been tracking that development?
-- Bryan J. Smith mailto:b.j.smith@ieee.org
The easiest scenario is to figure out a yum or apt repository as the other guys have expained. Otherwise do what we used to do in the past: If you are absoluterly sure the xtra rpms of your choice do not need any dependencies {otherwise you must include them as well} do as follows. go to the post section of the kickstart. mkdir /mnt/sysimage/some-nfs-share mount -t nfs ...... rpm -Uvh /mnt/sysimage/some-nfs-share/*.rpm umount /mnt/sysimage/some-nfs-share
This is the simplest but you must always resolve dependencies and make sure the latest version of the needed rpms are there. In the apt or yum scenario, yum or apt will take care of theese. After all that's why they were created
On Wed, 1 Jun 2005, Bryan J. Smith b.j.smith@ieee.org wrote:
I remember Seth talking awhile back on a Fedora list about the next generation installer (Anaconda-based?) being able to pull from YUM-RPM repositories at install-time for network installs.
Has anyone been tracking that development?
this is presently possible with anaconda - I do it all the time. why wait?
- Russ Herrold
On Wednesday 01 June 2005 14:59, R P Herrold wrote:
On Wed, 1 Jun 2005, Bryan J. Smith b.j.smith@ieee.org wrote:
I remember Seth talking awhile back on a Fedora list about the next generation installer (Anaconda-based?) being able to pull from YUM-RPM repositories at install-time for network installs.
this is presently possible with anaconda - I do it all the time. why wait?
Could you point to some documentation about how to do this? Thanks!
On Wed, 1 Jun 2005, Simon Perreault wrote:
On Wednesday 01 June 2005 14:59, R P Herrold wrote:
On Wed, 1 Jun 2005, Bryan J. Smith b.j.smith@ieee.org wrote:
I remember Seth talking awhile back on a Fedora list about the next generation installer (Anaconda-based?) being able to pull from YUM-RPM repositories at install-time for network installs.
this is presently possible with anaconda - I do it all the time. why wait?
Could you point to some documentation about how to do this? Thanks!
Certainly -- take a look at:
http://www.owlriver.com/pub/kickstart/ks.php
which returns demonstration code with such content in its '%post' stanza, with trivial php scripting (sorry about the formatting in a generic graphical web browser --
use 'lynx -source \ http://www.owlriver.com/pub/kickstart/ks.php
and it is easier to read). The relevant part is at the bottom.
I documented a method predecessor of this years ago on the yum mailing list
http://www.owlriver.com/support/yum/ and http://www.owlriver.com/projects/yum/ for a 'look under the hood' for codeing to emit a yum.conf of that type, on the fly. A ks.cfg is the same problemspace. Production code is a bit more complex ;)
- Russ Herrold
-
Bryan J. Smith <b.j.smith＠ieee.org> -
Nikos Zaharioudakis -
R P Herrold -
Simon Perreault