Hola,
I am seeing a lot of errors because one repository seems to be off kilter.
The directory that it is publishing as being where the various rpms can be
found doesn't exist on the file system.
The symptoms I see on the content hosts are failures to update
https://katello.petermac.org.au/pulp/repos/PMCC/Worker/Node/custom/ELRepo_org_Community_Enterprise_Linux_Repository_for_el7/elrepo-mainline-kernel/kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm:
[Errno 14] HTTPS Error 404 - Not Found
https://access.redhat.com/articles/1320623
which ends with an "error downloading packages" error.
The repo exists and is syncing correctly.
On the server, in the messages, I'm seeing:
Feb 22 11:21:42 katello pulp_streamer: [-] 127.0.0.1 - -
[22/Feb/2017:00:21:41 +0000] "GET
/var/lib/pulp/content/units/rpm/43/697e454f4bd11a054a035a756afee9405c3f84882b7bdb3594ee9414e008c5/kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm
HTTP/1.1" 404 - "-" "urlgrabber/3.10 yum/3.4.3"
In this case the long string directory doesn't exist.
/var/lib/pulp/content/units/rpm/43 is there
697e454f4bd11a054a035a756afee9405c3f84882b7bdb3594ee9414e008c5 is not.
kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm is available in a couple of places,
but not
/var/lib/pulp/content/
only
/var/lib/pulp/published/
What has gone wrong and how can it be fixed?
cheers
L.
···
------
The most dangerous phrase in the language is, "We've always done it this
way."
I seem to have solved this problem. While reading
https://bugzilla.redhat.com/show_bug.cgi?id=1330042
I found what I was looking for in
https://bugzilla.redhat.com/show_bug.cgi?id=1330042#c17 ("
Use case I would think of:
- The repository is corrupt - we don't trust it
All we want is a full (brute force) sync to rebuild it.")
Then I saw that someone else mentioned the Download policy. For some reason
it was set to "On Demand".
Changing it to Immediate and performing a resync worked.
cheers
L.
···
------
The most dangerous phrase in the language is, "We've always done it this
way."
On 22 February 2017 at 11:35, Lachlan Musicman datakid@gmail.com wrote:
Hola,
I am seeing a lot of errors because one repository seems to be off kilter.
The directory that it is publishing as being where the various rpms can
be found doesn’t exist on the file system.
The symptoms I see on the content hosts are failures to update
https://katello.petermac.org.au/pulp/repos/PMCC/Worker/Node/custom/ELRepo_org_Community_Enterprise_Linux_Repository_for_el7/elrepo-mainline-kernel/kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm:
[Errno 14] HTTPS Error 404 - Not Found
[Errno 14] yum fails with HTTP/HTTPS Error 404 - Red Hat Customer Portal
which ends with an “error downloading packages” error.
The repo exists and is syncing correctly.
On the server, in the messages, I’m seeing:
Feb 22 11:21:42 katello pulp_streamer: [-] 127.0.0.1 - -
[22/Feb/2017:00:21:41 +0000] “GET
/var/lib/pulp/content/units/rpm/43/697e454f4bd11a054a035a756afee9405c3f84882b7bdb3594ee9414e008c5/kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm
HTTP/1.1” 404 - “-” “urlgrabber/3.10 yum/3.4.3”
In this case the long string directory doesn’t exist.
/var/lib/pulp/content/units/rpm/43 is there
697e454f4bd11a054a035a756afee9405c3f84882b7bdb3594ee9414e008c5 is not.
kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm is available in a couple of
places, but not
/var/lib/pulp/content/
only
/var/lib/pulp/published/
What has gone wrong and how can it be fixed?
cheers
L.
The most dangerous phrase in the language is, “We’ve always done it this
way.”
I was wondering if perhaps you were running into this:
But it is a bit tricky to track down…
j
···
From: "Lachlan Musicman"
To: "Foreman Users"
Sent: Wednesday, February 22, 2017 4:32:00 PM
Subject: [foreman-users] Re: Pulp streamer is looking for non directory
I seem to have solved this problem. While reading
[ https://bugzilla.redhat.com/show_bug.cgi?id=1330042 | https://bugzilla.redhat.com/show_bug.cgi?id=1330042 ]
I found what I was looking for in [ https://bugzilla.redhat.com/show_bug.cgi?id=1330042#c17 | https://bugzilla.redhat.com/show_bug.cgi?id=1330042#c17 ] ("
Use case I would think of:
- The repository is corrupt - we don’t trust it
All we want is a full (brute force) sync to rebuild it.")
Then I saw that someone else mentioned the Download policy. For some reason it was set to “On Demand”.
Changing it to Immediate and performing a resync worked.
cheers
L.
The most dangerous phrase in the language is, “We’ve always done it this way.”
On 22 February 2017 at 11:35, Lachlan Musicman < [ mailto:datakid@gmail.com | datakid@gmail.com ] > wrote:
Hola,
I am seeing a lot of errors because one repository seems to be off kilter.
The directory that it is publishing as being where the various rpms can be found doesn’t exist on the file system.
The symptoms I see on the content hosts are failures to update
[ https://katello.petermac.org.au/pulp/repos/PMCC/Worker/Node/custom/ELRepo_org_Community_Enterprise_Linux_Repository_for_el7/elrepo-mainline-kernel/kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm | https://katello.petermac.org.au/pulp/repos/PMCC/Worker/Node/custom/ELRepo_org_Community_Enterprise_Linux_Repository_for_el7/elrepo-mainline-kernel/kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm ] : [Errno 14] HTTPS Error 404 - Not Found
[ [Errno 14] yum fails with HTTP/HTTPS Error 404 - Red Hat Customer Portal | [Errno 14] yum fails with HTTP/HTTPS Error 404 - Red Hat Customer Portal ]
which ends with an “error downloading packages” error.
The repo exists and is syncing correctly.
On the server, in the messages, I’m seeing:
Feb 22 11:21:42 katello pulp_streamer: [-] 127.0.0.1 - - [22/Feb/2017:00:21:41 +0000] “GET /var/lib/pulp/content/units/rpm/43/697e454f4bd11a054a035a756afee9405c3f84882b7bdb3594ee9414e008c5/kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm HTTP/1.1” 404 - “-” “urlgrabber/3.10 yum/3.4.3”
In this case the long string directory doesn’t exist.
/var/lib/pulp/content/units/rpm/43 is there
697e454f4bd11a054a035a756afee9405c3f84882b7bdb3594ee9414e008c5 is not.
kernel-ml-4.9.8-1.el7.elrepo.x86_64.rpm is available in a couple of places, but not
/var/lib/pulp/content/
only
/var/lib/pulp/published/
What has gone wrong and how can it be fixed?
cheers
L.
The most dangerous phrase in the language is, “We’ve always done it this way.”
–
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 [ mailto:foreman-users+unsubscribe@googlegroups.com | foreman-users+unsubscribe@googlegroups.com ] .
To post to this group, send email to [ mailto:foreman-users@googlegroups.com | foreman-users@googlegroups.com ] .
Visit this group at [ https://groups.google.com/group/foreman-users | https://groups.google.com/group/foreman-users ] .
For more options, visit [ https://groups.google.com/d/optout | https://groups.google.com/d/optout ] .
