Problem:
When attempting to sync the Debian buster repo from Index of /debian
Upstream URL: http:/ftp.us.debian.org/debian/
Components: main
Architecture: currently blank however, I’ve tried it set to binary-amd64 and the behavior is the same.
Job never gets past 41%. Job doesn’t die, it’ll just run indefinitely
Dynflow step is at:
6: Actions::Pulp3::Repository::Sync (waiting for Pulp to finish the task synchronize (ID: b28a4990696e)) [15156.46s/83.05s]
The Dynflow step cancels w/out any errors yet when restarting the sync progress goes to 41% and just sits at the same step.
Expected outcome:
Debian buster repo syncs
Foreman and Proxy versions:
Foreman 3.13
Foreman and Proxy plugin versions:
Katello 4.15.0
Distribution and version:
Foreman/Katello installed on Rocky9.5
Other relevant data:
This is probably/hopefully a simple operator error as this is my first time trying to work with Debian repositories.
thanks,
-Greg
Well, I did successfully get the Debian 10 updates repo synced just fine. That repo is much smaller so I don’t know if that’s part of my prob or not however, I’m not running out of diskspace when the regular Debian 10 repo sync is trying to occur…
@atix do you guys have any suggestions?
1 Like
One other question that’s tangentially related. Is there an easy way to look in /var/lib/wherever Pulp stores the repos via the filesystem to see each repo and determine how much space it’s using. I ask is that upon my last attempt at syncing the Debian buster main amd64 repo I let it run for many hours and while the job didn’t die it did increase my diskspace usage by ~20+ GB. I was able to successfully stop the task via Dynflow w/no issues and delete that repo, I still have the ~20GB of space that’s showing as used via cli “df -f”. So my question is there an easy way to look directly at the filesystem whereever Pulp stores the repo data and determine what directories were used for that, see how much space they’re taking and then ideally simply delete those directories/files directly. I apologize if this is something widely know but it’s new to me. 
thanks,
-Greg
I’m guessing the answer is a no given this is how the repo data is stored…
[root@4man-1 ~]# ls -la /var/lib/pulp/media/artifact |more
total 7932
drwxr-xr-x. 258 pulp pulp 8192 Mar 5 12:14 .
drwxr-x—. 3 pulp pulp 22 Mar 5 12:09 …
drwxr-xr-x. 2 pulp pulp 28672 Mar 13 13:58 00
drwxr-xr-x. 2 pulp pulp 24576 Mar 13 13:58 01
drwxr-xr-x. 2 pulp pulp 28672 Mar 13 14:41 02
drwxr-xr-x. 2 pulp pulp 28672 Mar 13 13:58 03
drwxr-xr-x. 2 pulp pulp 28672 Mar 13 14:55 04
drwxr-xr-x. 2 pulp pulp 28672 Mar 13 13:58 05
drwxr-xr-x. 2 pulp pulp 28672 Mar 13 14:41 06
No biggie. In reading thru this (pulpcore/docs/installation/storage.rst at 753fa3d62fe8d1ec2e5cd2e2ccf6649d06ced15b · pulp/pulpcore · GitHub) I am thinking that for my environment I may be better served by just creating an NFS mount to an external NAS and let Pulp store all repo data there…
thanks,
-Greg
Got this working. Followed the advice from my other thread ( Pulp MEDIA_ROOT setting modification - Support - TheForeman) about Pulp’s MEDIA_ROOT configuration option which was to actually not mess with that or any other variables but rather to just to use an nfs mount for /var/lib/pulp. The Debian 10 repo took 3hrs to sync but it completed successfully.
Repo Details:
Name: Debian 10 buster
Upstream URL: Index of /debian
Releases/Distributions: buster
Components: main
Architectures: amd64
Verify SSL: no
Here’s a nice list for Debian 10 (Buster) sources:
Debian 10 (Buster) – Full sources.list
-Greg
