Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
for some reason, I clicked on some key and it submitted the bug just when I added the subject so you can see all the details below: Description of problem: Yum install of glusterfs failed because of broken repo link Version-Release number of selected component (if applicable): ovirt-release-master-4.3.0-0.1.master.20181223000309.git8a07269.el7.noarch How reproducible: 100% Steps to Reproduce: 1. re-provision clean rhel7.6 2. yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm 3. try to run the command: yum install glusterfs Actual results: [root@dell-r210ii-01 yum.repos.d]# yum install glusterfs Failed to set locale, defaulting to C Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager This system is not registered with an entitlement server. You can use subscription-manager to register. centos-opstools-release | 2.9 kB 00:00:00 centos-ovirt-common-testing | 3.4 kB 00:00:00 centos-ovirt43-testing | 3.4 kB 00:00:00 centos-qemu-ev-release | 3.4 kB 00:00:00 centos-sclo-rh-release | 3.0 kB 00:00:00 opstools7-common-testing | 3.4 kB 00:00:00 opstools7-fluentd-012-testing | 3.4 kB 00:00:00 opstools7-perfmon-common-testing | 3.4 kB 00:00:00 One of the configured repositories failed (Unknown), 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=<repoid> ... 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 <repoid> or subscription-manager repos --disable=<repoid> 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: yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true Cannot find a valid baseurl for repo: ovirt-master-centos-gluster5/7Server/x86_64 [root@dell-r210ii-01 yum.repos.d]# Expected results: install it without any issue :) Additional info: the URL is not RHEL compatible the CentOS mirrors expect the $releasever to be '7' while on RHEL its 7Server W/A: 1. curl 'http://mirrorlist.centos.org?arch=x86_64&release=7&repo=storage-gluster-5' 2. take one of the URLs you get as results. 3. open the repo file: ovirt-master-dependencies.repo for editing. 4. in section ovirt-master-centos-gluster5 put the url from step 2 in the baseurl manually 5. just don't forget to un-comment it and comment the mirrorlist line 6. now you can run the yum command again!! Thanks for bkorren!!
probably its related to the following patch: https://gerrit.ovirt.org/#/c/95833/
Hi, is the release RPM going to be recreated tomorrow? I see https://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm has 2019-01-07 01:53 timestamp, so I guess it doesn't contains the change yet or it does? Thanks
(In reply to Petr Balogh from comment #3) > Hi, is the release RPM going to be recreated tomorrow? > > I see https://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm has > 2019-01-07 01:53 timestamp, so I guess it doesn't contains the change yet or > it does? > > Thanks Yes the build is timed, going to happen once a day.
Anything blocking this bugfix verification?
AFAIK we didn't hit this issue in our U/S deployment on RHEL anymore after fix of release RPM mentioned in Comment 3. So I think it can be considered as verified.
Moving to verified as per comment #6
Package including the fix has been released with oVirt 4.3.0 GA.