Description of problem: When testing kernels we need to ensure that we have a known good starting point. The way we do this is by installing a known good distro then reboot. Once the system has booted and report the installation is good we then update the kernel. Looking at newer kickstarts I see the following: https://beaker.engineering.redhat.com/kickstart/115316 ----<snip>---- repo --name=beaker-HighAvailability --cost=100 --baseurl=http://download.eng.bos.redhat.com/released/RHEL-6/6.3/Server/i386/os/HighAvailability repo --name=beaker-LoadBalancer --cost=100 --baseurl=http://download.eng.bos.redhat.com/released/RHEL-6/6.3/Server/i386/os/LoadBalancer repo --name=beaker-ResilientStorage --cost=100 --baseurl=http://download.eng.bos.redhat.com/released/RHEL-6/6.3/Server/i386/os/ResilientStorage repo --name=beaker-debuginfo --cost=100 --baseurl=http://download.eng.bos.redhat.com/released/RHEL-6/6.3/Server/i386/debug repo --name=beaker-optional --cost=100 --baseurl=http://download.eng.bos.redhat.com/released/RHEL-6/6.3/Server/optional/i386/os repo --name=beaker-Server --cost=100 --baseurl=http://download.eng.bos.redhat.com/released/RHEL-6/6.3/Server/i386/os/Server repo --name=myrepo_0 --cost=100 --baseurl=http://xavier.bos.redhat.com/~jwilson/dist-cvs-repos/kernel-2.6.32-332.el6 ----</snip>---- ^^^^ This is new ^^^^ This repo was passed into the job and should not be used during the install. Here is an older kickstart with the correct behavior: https://beaker.engineering.redhat.com/kickstart/84001 This will also cause entire jobs to abort if a bad repo happens to be passed in. Version-Release number of selected component (if applicable): Version - 0.9.4
Please revert this change as soon as possible. We are missing important information from the kernelinstall tests. If we hit an issue it we will no know if it is a new kernel issue or a system issue. Thanks, Jeff
jburke - but there are lots of valid use cases for adding repos at install time. I don't know the right answer but I do know that both are valid use cases. Dan, would it make sense to expand the <repo> node to include the following? <repo name="myrepo_0" url="http://xavier.bos.redhat.com/~jwilson/dist-cvs-repos/kernel-2.6.32-332.el6" available="post"/> attribute available could be "install" or "post" and if its left out it would be both like we have right now. install would only make the repo available at install time. post would only make it available from %post onward. Not sure how to best represent this in the command workflow though. We only have --repo. We could add --install-repo and --post-repo or hack --repo to support --repo=install+http://full/url.
I guess this is both a feature and a regression... For the record, the RFE for this was bug 633369. (In reply to comment #2) I think <repo ... available="post" /> and --post-repo makes sense. I am tempted to say that if the repo is not needed at install time, it should just be added after the installation by a task or ks_appends, but obviously that would not be convenient for Jeff's use case.
Bill, I think you said you proposed a patch for workflow-kernel to add the desired repo in ks_appends, is that right? Can we go with that approach as the fix for this bug?
Dan, I opened another bug for the kernel-workflow workaround: https://bugzilla.redhat.com/show_bug.cgi?id=867967 I think taking what I did for the kernel-workflow and adding it to the base options as --repo-post may be useful for others. I'll leave it up to you to decide.
Bug 867967 fixes this for the kernel team, but I agree with comment 5 that it might be a more generally useful feature to have --repo-post for workflows. So converting this to an RFE.
Initial patch at http://gerrit.beaker-project.org/#/c/2319
On Gerrit: http://gerrit.beaker-project.org/#/c/2450