Bug 902390

Please include some links to an example job and mark the comment private.

Thanks

I don't see a bug here except that you referenced a repo that is invalid.

Both the repo and package are in the kickstart where I would expect them.

What is the problem?

Hello Jakub,

The reason you are having trouble is because beaker doesn't add the repo to rhel5 kickstarts.   I believe there is some problem with the version of anaconda on rhel5 that had us remove it.

I'll let the beaker devs confirm this.

You could install the package in ks_append as a work around.

<ks_appends>
 <ks_append>yum -y install $PACKAGE</ks_append>
</ks_appends>

That is nice workaround.
I believe there is a serious reason not to use "repo" keyword in RHEL5 kickstarts.
But is there any not to create repos in %pre section?
It would be solved and the behaviour would be much more transparent.
The XML job specification is sort of "interface" and it is up to the developer to implement it §;o)

This may turn this issue back to RFE, bud I'll keep this up to You.

For the record, bug 590951 was where this was originally implemented and then reverted. The comments on that bug don't indicate what went wrong with Anaconda, and we can assume Bill doesn't remember otherwise he would have mentioned it here already. :-)

Amit is going to do some testing with the repo command on older Anacondas, to see if we can figure out what does and doesn't work.

(In reply to comment #6)
> But is there any not to create repos in %pre section?
> It would be solved and the behaviour would be much more transparent.

It's an interesting idea, but I am reasonably sure that Anaconda doesn't load repos from /etc/yum.repos.d (although I haven't checked).

Amit, it might be worth also investigating this as a possibility.

(In reply to comment #7)
> For the record, bug 590951 was where this was originally implemented and
> then reverted. The comments on that bug don't indicate what went wrong with
> Anaconda

I'm pretty sure this was the reason we dropped the custom repos from RHEL5: bug 754133.

So, maybe we can add them back but avoid the --cost option on RHEL5.

(In reply to comment #9)
> (In reply to comment #7)
> > For the record, bug 590951 was where this was originally implemented and
> > then reverted. The comments on that bug don't indicate what went wrong with
> > Anaconda
> 
> I'm pretty sure this was the reason we dropped the custom repos from RHEL5:
> bug 754133.
> 
> So, maybe we can add them back but avoid the --cost option on RHEL5.

Hi Dan,

I'm reaching back into the cob webs in my brain on this one..  But I think it was a conflict over the key variable enabling repos and then us adding the same repos again.  And because the rhel5 anaconda doesn't support the --cost variable it gets confused if the same package is available from two different repos.

Amit should verify though..  If so, maybe we can exclude the OS repos but still include any custom ones?

Some experiments and observations so far:

- Reproduced https://bugzilla.redhat.com/show_bug.cgi?id=754133 when an attempt is made to add repositories with the --cost option during install (using the print_anaconda_repos snippet). 

- If I remove the --cost option, the install task passes.

- Now, in addition if I specify a custom repo with an additional package to install available *only* in this repo, the package install also succeeds.


To summarize, the distro repos and the custom repos are both present, without the --cost option and the custom package specified via <package> is installed correctly. This seems like a possible solution. But, as Bill comments regarding a possible issue with this approach, may be we can just add the custom repos to the kickstart file for RHEL 5.

(In reply to comment #12)
> I think, it may just be a good idea to simply print the custom repos without
> the --cost option in the Kickstart file.

Sounds like a good approach. Thanks for doing all this testing, Amit.

On  Gerrit: http://gerrit.beaker-project.org/#/c/1729/

*** Bug 926045 has been marked as a duplicate of this bug. ***

Verified with beaker-0.11.3-1.git.210.bda2c22.

steps:

schedule a job with the following xml elements against RHEL5 distro:
---
<packages>
    <package name="xxx"/>
</packages>
<repos>
    <repo name="blah" url="http://example.com/blah/"/>
</repos>
---

The package 'xxx' with is only available in the 'blah' repo can be installed successfully after provision. And confirmed there is no issue when some packages are available from multiple repos.

Beaker 0.12 has been released.