The repository's publication is missing

Support
1

Problem:
After trying to publish repository to content view and i have an error

The repository’s publication is missing. Please run a ‘complete sync’ on Ubuntu22.The repository’s publication is missing. Please run a ‘complete sync’ on main.The repository’s publication is missing. Please run a ‘complete sync’ on updates.The repository’s publication is missing. Please run a ‘complete sync’ on security.The repository’s publication is missing. Please run a ‘complete sync’ on backports.

I have tried to use foreman-rake katello:regenerate_repo_metadata and it’s regenerate metadate for all repos excdule ubuntu 22. And i cant to update ubuntu22 repos from UI (for example Select Action > Sync Now or delete repo) because its replies error with task where i have an publish error with ubuntu 22

Required lock is already taken by other running tasks. Please inspect their state, fix their errors and resume them. Conflicts with tasks: - here task with error with publication ubuntu22.
So any tips for resolve? Or can i completele remove this repos and just add it one more time

Foreman and Proxy versions:
Foreman 3.16.0-develop
katello 4.18.0.pre.master

1 Like
2

There is likely some previous action that failed; the missing publication can be a symptom of that. Could you look through Dynflow and report any errors besides the missing publication ones? Also, please let us know why you attempted to regenerate the metadata, it might help us understand if something went wrong earlier.

Thanks!

3

Yes i found that i can skip task in Dynflow. So i skip all failed tasks and delete problem repository. Now everything is fine

1 Like
4

I’m now facing the same issue with Foreman 3.16 / Katello 4.18. Except skipping the error tasks in Dynaflow is only a temporary solution until you try to publish a new version.

I’ve removed the repoitories from content products, synced my Smart Proxies, then readded the repositories and still have the same missing publication error.

Just about ready dump what I have, and sart fresh with Katello 4.17, at least it was working.

5

I dont remember clearly how i fixed this, but i remember that i delete all problem repos using hammer cli. And via hummer i found that i really have some bugged repo (in gui i have 1 repo with error but hammer shows that i have like 2-3 repo) so i just delete all simmilar repos and readd it with gui

6

Hi @Jazzer2007 ,

For a sync task that failed (or CV publish task), can you look at each of the individual actions in the Dynflow console? It’s possible that the ‘publication missing’ part is just the last error that is reported. Repositories aren’t connected together in the backend, so deleting a repo and recreating it shouldn’t cause the same error unless there is actually some issue syncing the upstream repo in question.

In the orchestration chain in the Dynflow UI, I’d look at the first red (failure) or yellow (warning) task on the Run tab from top to bottom. The output should have the error. If it just says there’s a Pulp 3 error, you can find a better stack trace in /var/log/messages.

7

I am also dealing with the same sync error of foreman and katello running latest version. Can someone advise. Thnk you

8

Same errors after upgrading to Foreman 3.16 / Katello 4.18,

9

Aside from the details in The repository's publication is missing - #6 by iballou,

Please also post what content type the repo is that is failing to sync, along with any backtraces from Pulp in /var/log/messages, if any. This applies to everyone hitting the issue.

10

I am seeing this same issue after upgrading from 3.16 / 4.18

fmn.log (567.6 KB)

I grepped for pulp in /var/log/messages, see attached. I tried regenerating the repo data, this did not help. Let me know what else I can provide. For now I moved back to 3.15.

11

We are trying to narrow down if this affects all content types or for example just deb or just yum.

Can you tell us what content types you use that were or were not affected?

12

I can assure it affects both deb and yum repositories, I posted a solution for fixing (workaround) the error in another thread here:

13

I only use yum repositories , here is example right after upgrade, no repository changes

# hammer content-view publish --description $(date +%Y%m%d) --name "Foreman - el9" --organization "VVC" 
[........................................................................................................................                                                                                                                                                                                            ] [39%]
Error: The repository's publication is missing. Please run a 'complete sync' on Foreman client 3.15 - el9.

production.log.gz (7.7 KB)

14

Here is information about CV and the repo, for some reason forum refuses attach text file

# hammer content-view  info --name "Foreman - el9"
Id:                     4
Name:                   Foreman - el9
Label:                  Foreman_-_el9
Composite:              no
Rolling:                no
Description:            
Content Host Count:     0
Solve Dependencies:     yes
Organization:           VVC
Yum Repositories:       
 1) Id:    60
    Name:  Foreman client 3.15 - el9
    Label: foreman-client-3_15-el9
Lifecycle Environments: 
 1) Id:   2
    Name: Library
Versions:               
 1) Id:        65
    Version:   15.0
    Published: 2025/10/08 17:30:10
 2) Id:        59
    Version:   14.0
    Published: 2025/10/01 00:17:09
 3) Id:        53
    Version:   13.0
    Published: 2025/09/21 11:11:00
 4) Id:        47
    Version:   12.0
    Published: 2025/09/01 00:15:52
 5) Id:        41
    Version:   11.0
    Published: 2025/08/16 19:27:44
 6) Id:        35
    Version:   10.0
    Published: 2025/08/16 19:18:33
 7) Id:        31
    Version:   9.0
    Published: 2025/08/08 22:44:36


# hammer repository info --name "Foreman client 3.15 - el9" --product Foreman
Id:                 60
Name:               Foreman client 3.15 - el9
Label:              foreman-client-3_15-el9
Description:        
Organization:       VVC
Red Hat Repository: no
Content Type:       yum
Content Label:      VVC_Foreman_foreman-client-3_15-el9
Mirroring Policy:   Content Only
Url:                https://yum.theforeman.org/client/3.15/el9/x86_64
Publish Via HTTP:   yes
Published At:       https://foreman.chepkov.lan/pulp/content/VVC/Library/custom/Foreman/foreman-client-3_15-el9/
Relative Path:      VVC/Library/custom/Foreman/foreman-client-3_15-el9
Download Policy:    immediate
Publish Settings:   
    Restrict to architecture: No restriction
    Restrict to OS Version:   No restriction
HTTP Proxy:         
    HTTP Proxy Policy: global_default_http_proxy
Product:            
    Id:   1
    Name: Foreman
GPG Key:            
    Id:           1
    Name:         RPM-GPG-KEY-foreman
    GPG Key Path: https://foreman.chepkov.lan/katello/api/v2/repositories/60/gpg_key_content
Sync:               
    Status:         Success
    Last Sync Date: 8 days
Created:            2025/06/17 13:54:20
Updated:            2025/06/17 13:54:22
Content Counts:     
    Packages:       11
    SRPMs:          0
    Module Streams: 0
    Package Groups: 0
    Errata:         0
15

I think this may be a bug with the orchestration specifically for when dependency solving is turned on. I see a commit that was added that touched on the publishing orchestration in an unexpected manner: Fixes #38494 - Add imported syncable content to import history by qcjames53 · Pull Request #11415 · Katello/katello · GitHub

I generally would recommend not having dependency solving on unless you know you 100% need it - it doesn’t always work anyway and significantly slows down publishes. But, I digress :slight_smile:

Unless it’s 100% necessary - are folks hitting this issue able to test publishing without dependency solving on?

(and thank you for the data!)

16

If the issue is as I expect - we’ll get a 4.18.1 out shortly and share a patch for fixing this before the official release to unstick people.

17

I can’t force cancel the paused publishing task from the previous hummer run, so I modified another CV to disable dependency solving and CV was published successfully, so you hunch seems to be correct.

In general, this option is necessary, especially when you work with RedHat content. RedHat publishes packages that depend on each other in different channels without any transactional integrity, so sync might get newer version of a package in one channel and not get updated version of a related package in another, making a CV broken as a result.

1 Like
18

I have the same issue:
The repository’s publication is missing. Please run a ‘complete sync’ on Rocky 9 BaseOS x86_64. (RuntimeError)
756785d8 | /usr/share/gems/gems/katello-4.18.0/app/services/katello/pulp3/repository.rb:563:in fail_missing_publication' 756785d8 | /usr/share/gems/gems/katello-4.18.0/app/services/katello/pulp3/repository.rb:284:in create_distribution’
756785d8 | /usr/share/gems/gems/katello-4.18.0/app/services/katello/pulp3/repository.rb:267:in refresh_distributions' 756785d8 | /usr/share/gems/gems/katello-4.18.0/app/lib/actions/pulp3/repository/refresh_distribution.rb:26:in invoke_external_task’
I have tried both a complete sync and republish repository metadata, but creating a new Content View version still fails with the same error. Please advise.

19

Hi @elemarek , please see The repository's publication is missing - #15 by iballou

The workaround for now is to go into Dynflow, skip failing tasks and resume until the entire publish finishes, and then delete the resulting content view version. Then, disable dependency solving (if you can) and publish again.

Good feedback - this is not supposed to happen if BaseOS, AppStream, etc are synced together. Is it a particular Enterprise Linux (EL) flavor causing this trouble?

Keep an eye on this thread for a patch soon.

20

RedHat channels proper. And this happens even in one channel as well if dependency solving is not enabled. For example, in recent memory (on satellite though, so it’s a bit older version) gdk-pixbuf2-modules got synced (rhel-8-for-x86_64-baseos-rpms), but gdk-pixbuf2 didn’t. My colleague opened a RedHat case for that, I can find the number if you have access.

1 Like