Creating a trimmed set of Rocky linux repos for upgrade

Rocky Linux Help & Support
1

Good day,
I’m trying to develop an upgrade plan for quite a few Centos 7 (virtual) machines to Rocky Linux 9.
I’ve read through the various guides on the procedure using Elevate/leapp.

The part that is unique/challenging for my use case is that the VMs are likely air gapped, so won’t have access to the internet.
I’ve had some partial success with this guide and cloning Rocky linux repos.

The next thing I would like to do trim the repos to only contain the packages that I need.
Is there a guide to doing this somewhere?
What I tried so far that seems pretty hacky, was to host the full repos (BaseOS, AppStream, PowerTools) on an nginx server, do an upgrade from a test machine pointing at this server.
I then parse the access log to get the required packages and copy them info for example BaseOS/Packages.
I then used createrepo from a Centos 7 machine to create a new BaseOS repo.

When I serve this new repo, the upgrade gets past the preupgrade check but then fails the leap upgrade with

Warning: Package marked by Leapp to upgrade not found in repositories metadata: gpg-pubkey
No available modular metadata for modular package 'python2-babel-2.5.1-10.module+el8.9.0+1531+a18208f5.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-jinja2-2.10-10.module+el8.10.0+1813+4b021305.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-markupsafe-0.23-19.module+el8.9.0+1531+a18208f5.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'python2-pysocks-1.6.8-6.module+el8.9.0+1531+a18208f5.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-requests-2.20.0-4.module+el8.10.0+1817+0b01df83.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-setuptools-39.0.1-14.module+el8.10.0+1813+4b021305.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-six-1.11.0-6.module+el8.9.0+1531+a18208f5.noarch', it cannot be installed on the system
No available modular metadata for modular package 'libslirp-4.4.0-2.module+el8.10.0+1825+623b0c20.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'perl-IO-Socket-SSL-2.066-4.module+el8.9.0+1517+e71a7a62.noarch', it cannot be installed on the system
No available modular metadata for modular package 'perl-Mozilla-CA-20160104-7.module+el8.9.0+1521+0101edce.noarch', it cannot be installed on the system
No available modular metadata for modular package 'perl-Net-SSLeay-1.88-2.module+el8.9.0+1517+e71a7a62.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'python2-2.7.18-17.module+el8.10.0+1813+4b021305.rocky.0.2.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'python2-backports-ssl_match_hostname-3.5.0.1-12.module+el8.9.0+1531+a18208f5.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-libs-2.7.18-17.module+el8.10.0+1813+4b021305.rocky.0.2.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'python2-pip-wheel-9.0.3-19.module+el8.9.0+1531+a18208f5.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-pytz-2017.2-13.module+el8.10.0+1817+0b01df83.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-pyyaml-3.12-16.module+el8.9.0+1531+a18208f5.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'python2-setuptools-wheel-39.0.1-14.module+el8.10.0+1813+4b021305.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python36-3.6.8-39.module+el8.10.0+1592+61442852.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'container-selinux-2:2.229.0-2.module+el8.10.0+1825+623b0c20.noarch', it cannot be installed on the system
No available modular metadata for modular package 'fuse-overlayfs-1.13-1.module+el8.10.0+1825+623b0c20.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'mariadb-common-3:10.3.39-1.module+el8.8.0+1452+2a7eab68.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'python2-backports-1.0-16.module+el8.9.0+1531+a18208f5.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'python2-chardet-3.0.4-10.module+el8.9.0+1531+a18208f5.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-idna-2.5-7.module+el8.9.0+1531+a18208f5.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-ipaddress-1.0.18-6.module+el8.9.0+1531+a18208f5.noarch', it cannot be installed on the system
No available modular metadata for modular package 'python2-urllib3-1.24.2-4.module+el8.10.0+1813+4b021305.noarch', it cannot be installed on the system
No available modular metadata for modular package 'slirp4netns-1.2.3-1.module+el8.10.0+1825+623b0c20.x86_64', it cannot be installed on the system
Error: No available modular metadata for modular package

I will try create the repo with createrepo from Rocky LInux 8 but just wanted to see if someone had some pointers on the right way to do this before I carry on stumbling in the dark :slight_smile:

Thanks,
Pico

2

Upgrades with Rocky Linux are not supported.

I highly recommend against doing this in any way. You should keep the repositories and their metadata intact.

And that’s why you should not try to “trim” or use createrepo on an already established repository. It does not matter if you do it on Rocky Linux 8 or 9. Doing so destroys group information and modular metadata. Even if you used the right options (createrepo -g, see man createrepo_c) and added back modular data (man modifyrepo_c), you are further increasing your risk of failure.

You are much better off just keeping the repositories completely synced as-is with zero changes, instead of trying to go through and trim things down.

1 Like
3

Thanks for the advice.
I don’t think keeping the repos at their full size is an option for me.
Those 3 repos in there full size are roughly 29GB, where as the trimmed repos would be less then 1GB.
I’ll dig into the man pages you suggested and compare the risk to other options.
Thanks again,

4

The install images are about 2.5G and 14G for “minimal” and “dvd”, respectively. Even the larger does fit into 16G USB stick.
I do usually choose the minimal install of packages whether I do use either of them.
(Then again, I do have the luxury of network, so I can later install whatever is missing.)

So thightly gapped that … how do you reach them at all?

5

I see the minimal ISO does only contain BaseOS which does explain the smaller size.
I’m not sure if an upgrade requires packages from AppStream and PowerTools by default or if it’s due to packages I have on my system.

I said air gapped but probably not the strict definition, I more mean they are offline and don’t have access to the internet.
Ideally I would be able to include all the repos in a tarball and then have a script to kick off the upgrade process.
Although upgrading from a local repo also seems like it’s not supported.

I hoping I can at least provide the administrator a very simple procedure to host the repo on their local network.

6

What do you mean by that? A repo is a repo (as long as it has proper metadata).

7

You might want to look at something like ‘satellite’, where you can have local repos on the isolated network, only satellite can talk to the online repos. The local machines talk to satellite, and they don’t need huge local copies, so if you install only one package, the local machine would stay small (except for the dnf cache).

1 Like
8

I would have expected exactly that as well, but when I try to use a local repo with file:// URI, one of the elevate inhibitors fails with:

Risk Factor: high (inhibitor)
Title: Local repository detected
Summary: Local repository found (baseurl starts with file:///). Currently leapp does not support this option.
Remediation: [hint] By using Apache HTTP Server you can expose your local repository via http. See the linked article for details.
Key: 3450b32bfad8e1837b73b18e56c556d1052d5e4b

I believe the code is here:

I’m not sure why that restriction is there.

9

I’ve found a temporary workaround that lets me prune the repos easily and to host them on the local filesystem, though it’s not pretty.

If you delete packages from the repo structure, without recreating the repo (createrepo), the repo seems to continue to function for this limited use case.
I also hacked around the restriction that the repo can not be hosted on the local filesystem, by simply serving the repo with a statically built http server.
I would love to know why that restriction is there if everything is just stored locally before the reboot.

Once I have time, I may play around with trying to recreate the repo with the correct modules again, even if only to understand it better.

Thanks all for the assistance.

10

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.