Leapp upgrade from centos 7 to alama 8

I have been testing the Elevate script for upgrading in a air gaped environment and i have recently started encountering an issue. where it seems that the Elevate might not respect the proxy settings in /etc/leapp/files/leapp_upgrade_repositories.repo

it is worth noting that I have been able to do this upgrade not that long ago and this seems new.

the preupgrade check fails here.
==> Processing phase TargetTransactionCheck
====> * local_repos_inhibit
Inhibits the upgrade if local repositories were found.
====> * report_set_target_release
Reports information related to the release set in the subscription-manager after the upgrade.
====> * dnf_transaction_check
This actor tries to solve the RPM transaction to verify the all package dependencies can be successfully resolved.
Applying transaction workaround - yum config fix

Extra Packages for Enterprise Linux 8 - x86_64 0.0 B/s | 0 B 00:00
2024-02-26 14:50:45.817 ERROR PID: 28252 leapp.workflow.TargetTransactionCheck.dnf_transaction_check: DNF execution failed:
====> * tmp_actor_to_satisfy_sanity_checks
The actor does NOTHING but satisfy static sanity checks
====> * check_initramfs_tasks
Inhibit the upgrade if conflicting “initramfs” tasks are detected


2024-02-26 14:50:46.007956 [ERROR] Actor: dnf_transaction_check
Message: DNF execution failed with non zero exit code.
Extra Packages for Enterprise Linux 8 - x86_64 0.0 B/s | 0 B 00:00

No matches found for the following disable plugin patterns: subscription-manager
Repository extras is listed more than once in the configuration
Repository extras-source is listed more than once in the configuration
Errors during downloading metadata for repository ‘el8-epel’:

the curl error is seems to be pointing at the Elevate script trying to reach the host directly instead of via a proxy. which I can connect to if I try directly.
curl --proxy “http://x.x.x.x” “https://mirrors.fedoraproject.org/metalink?repo=epel-8&arch=x86_64&infra=stock&content=almalinux

<?xml version="1.0" encoding="utf-8"?> 1708907227 4847 241aae52c73d2a96481cc25df0eb458d a427ffffa23525d9fa1ad5465348cf5abb66edc5 401b7786ae73e454578894921954b267d922da4cd04c3b4f4a1c2bb248d0b1bc 8a0adfe2a5552cbebb58156415f908bf5ab333a717a027f208d019dd6a626f67533ae6a9babe645e551e34c908a2dc4c185acd54768305d9d5d83f6973f096bf

so I found a blog post that offered a work around. but it does not seem like it should be needed. the work around is making a bash script that monitors the following file and injects the proxy every time the file is changed.