Is the kickstart repo directive broken under CentOS 7? Every attempt with a repo directive in the kickstart file fails during the software selection step. Removing the repo directives and the packages from those repos under %packages makes it work.
On console 2, I have verified that the (NFS) repos specified in the kickstart file are mounted and that the repo metadata has been copied over to /tmp/yum.cache. One of the packages from one of the repos that is explicitly listed under the %packages section appears in packaging.log for dependency checking.
The custom repos work fine with yum on a running machine, so there is no problem with the metadata.
Logging is poor and does not log what is actually wrong.
On 2019-10-03, isdtor writes:
Is the kickstart repo directive broken under CentOS 7? Every attempt with a repo directive in the kickstart file fails during the software selection step. Removing the repo directives and the packages from those repos under %packages makes it work.
On console 2, I have verified that the (NFS) repos specified in the kickstart file are mounted and that the repo metadata has been copied over to /tmp/yum.cache. One of the packages from one of the repos that is explicitly listed under the %packages section appears in packaging.log for dependency checking.
The custom repos work fine with yum on a running machine, so there is no problem with the metadata.
Logging is poor and does not log what is actually wrong.
Here is my theory: the installer runs into some hard-coded limit for the list of installation packages, or another hard-coded limit that indirectly affects the list of installation packages.
Basis for the assumption: packages from a "repo" in the %packages section install fine if the installation package set is limited. Installation fails if the effective number of packages in %packages is high, in the thousands. I cannot narrow it down further for the moment, my reference points are 700 or so vs. 6000.
Is anyone aware of bug reports in this area for RHEL or Fedora? I'v looked at the changelog sections of the F22 and F30 anaconda rpms but didn't see anything obvious.
On 2020-02-08 15:22, isdtor wrote:
On 2019-10-03, isdtor writes:
Is the kickstart repo directive broken under CentOS 7? Every attempt with a repo directive in the kickstart file fails during the software selection step. Removing the repo directives and the packages from those repos under %packages makes it work.
On console 2, I have verified that the (NFS) repos specified in the kickstart file are mounted and that the repo metadata has been copied over to /tmp/yum.cache. One of the packages from one of the repos that is explicitly listed under the %packages section appears in packaging.log for dependency checking.
The custom repos work fine with yum on a running machine, so there is no problem with the metadata.
Logging is poor and does not log what is actually wrong.
Here is my theory: the installer runs into some hard-coded limit for the list of installation packages, or another hard-coded limit that indirectly affects the list of installation packages.
Basis for the assumption: packages from a "repo" in the %packages section install fine if the installation package set is limited. Installation fails if the effective number of packages in %packages is high, in the thousands. I cannot narrow it down further for the moment, my reference points are 700 or so vs. 6000.
Is anyone aware of bug reports in this area for RHEL or Fedora? I'v looked at the changelog sections of the F22 and F30 anaconda rpms but didn't see anything obvious.
Hard to imagine something as bone-headed as a hard limit in the package list. Maybe increasing RAM allocation significantly just for the install? If the dependency resolution runs out of memory that might collide with ability to log the problem.
Regarding the logs, may we presume you've checked alternate consoles (ctrl+alt+F1 / ctrl+alt+F4) during the process?
Hopefully relevant: At point in time ~5 years ago, the prevailing opinion in parts of the Internet was that kickstart should be a minimal process, just enough to get a running system, then some more featureful mechanism such as Puppet or Chef (...) would take over to finish configuring the host. You might consider some firstboot-like adjunct script to finish out your build. I'd be tempted to create a package that pulled in the desired packages as dependencies, put that package in my custom repo, then install that. One and done.
-
cpolish＠surewest.net -
isdtor