Description of problem:

A customer hits constantly a failure when trying to convert his CentOS7 system:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Traceback: Traceback (most recent call
    last):
  File "/usr/lib/python2.7/site-packages/convert2rhel/actions/__init__.py", line 393, in run
    action.run()
  File
    "/usr/lib/python2.7/site-packages/convert2rhel/actions/system_checks/rhel_compatible_kernel.py", line 49, in run
    _bad_kernel_package_signature(system_info.booted_kernel),
  File "/usr/lib/python2.7/site-
    packages/convert2rhel/actions/system_checks/rhel_compatible_kernel.py", line 119, in _bad_kernel_package_signature
    kernel_pkg_obj = get_installed_pkg_objects(name, version, release, arch)[0]
IndexError: list index out of range
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The reason for the failure is no kernel matching name/version/release/arch was found.
To check the installed kernel (which is used to populate name/version/release/arch), the following command is executed:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
103     kernel_pkg, return_code = run_subprocess(
104         ["rpm", "-qf", "--qf", "%{VERSION}&%{RELEASE}&%{ARCH}&%{NAME}", vmlinuz_path], print_output=False
105     )
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Then output split:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
116     version, release, arch, name = tuple(kernel_pkg.split("&"))
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Finally "kernel_pkg_obj" extracted:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
119     kernel_pkg_obj = get_installed_pkg_objects(name, version, release, arch)[0]
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

If, on line 104, the rpm command returns something on stderr, then the "version" will be corrupted, causing the issue.
For some reason, this always happens on the customer system, as shown below through adding some instrumentation on line 119 below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
119     logger.warning("name='%s', version='%s', release='%s', arch='%s'" % (name, version, release, arch))
120     kernel_pkg_obj = get_installed_pkg_objects(name, version, release, arch)[0]
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Resulting output ("version" field corrupted by stderr):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
WARNING - name='kernel', version='BDB2053 Freeing read locks for locker 0x3f9: 129310/139621967034176
BDB2053 Freeing read locks for locker 0x3fb: 129310/139621967034176
3.10.0', release='1160.95.1.el7', arch='x86_64'
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Version-Release number of selected component (if applicable):

convert2rhel-1.3.2-1.el7.noarch

How reproducible:

Always on customer system, didn't manage to force getting a warning for now

Additional info:

A quick and dirty solution is to discard stderr when executing "rpm -qf" command on line 104, which requires wrapping in a shell, as shown below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
104         ["sh", "-c", "rpm -qf --qf \"%%{VERSION}&%%{RELEASE}&%%{ARCH}&%%{NAME}\" %s 2>/dev/null" % vmlinuz_path], print_output=False
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Ideally, utils.run_subprocess() should be reimplemented to not merge stdout and stderr and make the merge be optional.
Currently it is implementing automatic merging:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
 345 def run_subprocess(cmd, print_cmd=True, print_output=True):
 :
 362     process = subprocess.Popen(
 363         cmd,
 364         stdout=subprocess.PIPE,
 365         stderr=subprocess.STDOUT,
 366         bufsize=1,
 367     )
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

It's very possible many other calls to utils.run_process() may fail similarly.
Probably a robust implementation would be to add some more function parameters:
- "expect_stderr" parameter which will make run_subprocess() DIE if some stderr is found when "expect_stderr=False"
- "discard_stderr" parameter which will redirect stderr to /dev/null when "discard_stderr=True"