I think I can see what the error is: we used to have a repo called Katello/client/ which held the client repo.
Then, when I decided to upgrade to 3.2, I renamed the repo to Katello/client-3.1 and added Katello/client-3.2 This might be the first time that this content host/LCE/Activation key has been associated with the newly named client repo. But I don't understand how the .repo file is made nor why the renaming wouldn't click with any updates - is this a bug? Note: I'm pretty sure this is exactly what happened as the listed repo in the error def doesn't work (browser gives 404) https://vmpr-res-utils.our.domain/pulp/repos/PMCC/Utility_Prod/Utility_Server/custom/Katello/client but this definitely does show up in a browser (package list in browser) https://vmpr-res-utils.our.domain/pulp/repos/PMCC/Utility_Prod/Utility_Server/custom/Katello/client-3_2 So - I can fix this by hand, but that is less than ideal. How do I fix it more permanently? cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 13 February 2017 at 09:25, Lachlan Musicman <[email protected]> wrote: > Hola, > > I promoted a LCE and when I tried updating the content host attached to > it, I get the error > > [Errno 14] HTTPS Error 404 - Not Found > Trying other mirror. > To address this issue please refer to the below knowledge base article > > https://access.redhat.com/articles/1320623 > > If above article doesn't help to resolve this issue please create a bug on > https://bugs.centos.org/ > > > > One of the configured repositories failed (client), > and yum doesn't have enough cached data to continue. At this point the > only > safe thing yum can do is fail. There are a few ways to work "fix" this: > > 1. Contact the upstream for the repository and get them to fix the > problem. > > 2. Reconfigure the baseurl/etc. for the repository, to point to a > working > upstream. This is most often useful if you are using a newer > distribution release than is supported by the repository (and the > packages for the previous distribution release still work). > > 3. Run the command with the repository temporarily disabled > yum --disablerepo=PMCC_Katello_client ... > > 4. Disable the repository permanently, so yum won't use it by > default. Yum > will then just ignore the repository until you permanently enable > it > again or use --enablerepo for temporary usage: > > yum-config-manager --disable PMCC_Katello_client > or > subscription-manager repos --disable=PMCC_Katello_client > > 5. Configure the failing repository to be skipped, if it is > unavailable. > Note that yum will try to contact the repo. when it runs most > commands, > so will have to try and fail each time (and thus. yum will be be > much > slower). If it is a very temporary problem though, this is often a > nice > compromise: > > > > Unfortunately, the page listed: > https://access.redhat.com/articles/1320623 > > is only available to RH subscribers. Is there a non subscriber version of > this page? > > Alternatively, how do I fix the problem. > > cheers > L. > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
