Hmnm, fixing by hand doesn't work - the /etc/yum.repos.d/redhat.repo updates/reverts itself every time?
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:39, Lachlan Musicman <[email protected]> wrote: > 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.
