Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1523790 - satellite-clone expects root to be 75 GB in size
Summary: satellite-clone expects root to be 75 GB in size
Keywords:
Status: CLOSED DUPLICATE of bug 1519535
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Satellite Clone
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: John Mitsch
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-08 18:03 UTC by Glenn Snead
Modified: 2018-01-02 16:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-02 16:49:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Output from satelite-clone utility with df -h and mount command output. (9.99 KB, text/plain)
2017-12-08 18:03 UTC, Glenn Snead 		no flags Details
View All

Description Glenn Snead 2017-12-08 18:03:45 UTC 
Created attachment 1364966 [details]
Output from satelite-clone utility with df -h and mount command output.

Description of problem:


Version-Release number of selected component (if applicable):
satellite-clone 1.1.4-1.el7sat

How reproducible:
Build a satellite server with the following partition layout:
Filesystem                  Size  Used Avail Use% Mounted on
/dev/vdb1                    10G  5.2G  4.8G  52% /
devtmpfs                    7.8G     0  7.8G   0% /dev
tmpfs                       7.8G     0  7.8G   0% /dev/shm
tmpfs                       7.8G   17M  7.8G   1% /run
tmpfs                       7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/mapper/vg_sat-iso       10G  6.3G  3.8G  63% /srv
/dev/loop0                  3.8G  3.8G     0 100% /media/rhel-7-server
/dev/loop1                  2.5G  2.5G     0 100% /media/sat6
/dev/mapper/vg_sat-pulp     100G   33M  100G   1% /var/lib/pulp
/dev/mapper/vg_sat-cache     10G   33M   10G   1% /var/cache/pulp
/dev/mapper/vg_sat-mongodb   50G   33M   50G   1% /var/lib/mongodb
/dev/mapper/vg_sat-pgsql     10G   33M   10G   1% /var/lib/pgsql
tmpfs                       1.6G     0  1.6G   0% /run/user/0



Steps to Reproduce:
1. Register with rhn
2. Add the required repositories
3. Copy the Satellite backup files from the source Satellite server
4. Configure /etc/satellite-clone/satellite-clone-vars.yml.  Set the default organization and the backup_dir path.

Actual results:
See attached file.
I have included the above volume layout in the file, and the output of the mount command.

Most installations won't have a 75GB (or larger) root partition.  Red Hat's own recommended practice is to segreate /var, /usr, /home, etc into separate partitions, and Satellite's installation documentation moves most Satellite data into separate partitions.


Expected results:
Unknown, as the command fails.


Additional info:
Comment 1 jcallaha 2017-12-15 16:43:53 UTC 
You can lower the required disk space to any value you want by modifying the required_root_free_space value in satellite-clone-vars.yml.
Comment 2 Glenn Snead 2017-12-15 17:07:20 UTC 
Three questions:

Where is the satellite-clone-vars.yml file?  I didn't see it discussed in the documentation.

What kind of space should the system administrator set aside for Satellite cloning?

Can the clone files reside on a separate partition, or must they reside on the root partition?

All of this must go into the documentation.  I can help with that, but I need the information.
Comment 3 jcallaha 2017-12-15 19:20:26 UTC 
Glenn, Suresh can answer most, if not all of these, questions.
Comment 4 John Mitsch 2017-12-15 19:30:41 UTC 
Glenn,

(In reply to Glenn SNead from comment #2)
> Three questions:
> 
> Where is the satellite-clone-vars.yml file?  I didn't see it discussed in
> the documentation.
> 

/etc/satellite-clone/satellite-clone-vars.yml. Is this not in the official Satellite documentation? If not, we need to add it there.

> What kind of space should the system administrator set aside for Satellite
> cloning?
> 

You need to have the same amount of space as your original satellite. For example /var/lib/pulp will be the same size as your original Satellite since that is being restored (assuming your backup has pulp_data.tar)

> Can the clone files reside on a separate partition, or must they reside on
> the root partition?
> 
They can be anywhere that is accessible to ansible and postgres. You can put it in a mounted partition if space is a concern. There are checks to check for access in the beginning of the playbook run

> All of this must go into the documentation.  I can help with that, but I
> need the information.

Currently the size check is incorrect for mounted partitions, we are looking into it, Jake's workaround is correct.

Let me know if you have any  more questions.
Comment 5 sthirugn@redhat.com 2018-01-02 16:49:05 UTC 
As John mentioned in Comment 4, this is a known issue and is being tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1519535. The workaround is documented there as well.

*** This bug has been marked as a duplicate of bug 1519535 ***
Note You need to log in before you can comment on or make changes to this bug.