On Wed, Sep 18, 2019 at 4:49 AM <jkonecny@xxxxxxxxxx> wrote: > > Hi James, > > On Tue, 2019-09-17 at 09:57 -0400, James Cassell wrote: > > In general, I'd prefer to extend the ks repo command. > > > > My main concern is that the original-ks.cfg or anaconda-ks.cfg might > > no longer provide a complete description of how a particular system > > was installed, so it'd like that info exposed on the installed system > > somehow. > > It's not really related. What we are talking here about is to add repo > files in the installation environment. The output kickstart file will > be the same as before. What will change is the environment used for the > installation. I used to use '%pre' to first build up the file systems, then to pre-install localized configuration files. Mind you, I also threw out most of the rest of the kickstart configuraiton operations and worked from a deployment tarball, much like mock uses local tarballs to build chroot cages, and used chroot cages to build those tarballs for deployment. This was *much, much faster* than doing RPM baed installations on top of a bare filesystem. It's also possible, if you're desperate for leverage, to do the kickstart install with a minimal list of packages and use multiple '%post' stanzas to activate additional repositories and complete installation of other suites of software. It's really too bad that the GUI for reading and building kickstarts has never handled multiple '%pre' or '%post' stanzas, it would have made this much easier. > > As for implementation, perhaps base64 zlib compressed. repo passed as > > a cmdline arg would be useful to avoid having to create updates.img. > > Could also be done as --repofilecontent for the repo command. > > Personally, I'm not really sure what would be the benefit here. Also > you have a limitation on what you can pass in the kernel command line > so I guess having 3 repo files this way is a no-go. > > I think it's already possible to place a .repo file from ks %pre? > > Yes it is. However, you have to do that manually and download gpg keys > and certificates somewhere (which is not secure in general). You also have to pre-build your filesystems to have a place to copy the files into at installation time. If you're going to go to that much work, why are you bothering with yum? Why not just pre-build and install a base operating system, which is much, much faster and notably more network efficient than pulling down and installing RPMs? I've installed roughly..... 20,000 hosts this way in my career, it works really well for clusters. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
