Feature: Adding Rhel10 Base Support using dnf4 package manager

[yashnap]

Implemented Dnf4PackageManager by extending PackageManager.

Implemented changes:

• DNF5 package manager
• ConfigurePatching operation
• Auto Assessment operation
• Assessment operation
• Installation operation
• UTs
• Disabling Auto OS updates

TESTS

1. On demand Assessment (ConfigurePatching can be validated within Assess or Install Patches run)
   4.core.log

2. On demand Installation, Classification: [Critical, Security, Other]
   "classificationsToInclude": ["Security","Other","Critical"]
   5.core.log

3. Auto assessment, recurring on schedule -
   2.aa.core.log
   2.core.log
   3.json

4. Only Package inclusions installed
   7.core.log
   Included : python3-perf ( Only installed)

5. With package exclusions i.e. excluded packages are not installed
   Exclude list [xxd, openssl ] - Both not installed
   4.core.log

6. With Dependent packages i.e. dependent packages identified and installed
   6.core.log
   Included : coreutils (It installed dependent packages coreutils-common etc)

7. Excluding a package because its dependency needs to be excluded : I
   5.core.log
   Included: fprintd , Excluded : fprintd-pam

8. Auto Patching request with only security and critical updates in request, which should install all classifications
   "classificationsToInclude": ["Security", "Critical"]
   9.core.log

Logs for disabling auto OS (machine default) updates

9. Machine default updates service installed but NOT enabled - 4.core.log

10. Machine default updates service NOT installed -
    autoOS_notInstalled_.log

11. Machine default updates service installed and enabled - ConfigurePatching reads and logs that auto OS updates are installed and enabled and disables them. Auto OS updates are disabled

[8.core.log](https://github.com/user-attachments/files/29564822/8.core.log)

**Note on Redhat machine not being able to get updates with the below message: **
Unable to read consumer identity This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

• This message shows up on the VM when any command is run. Error message is being thrown so the customer is aware of what is happening.

Add Multi_arch_dependencies:
Evaluated whether DNF4 needs add_arch_dependencies() logic. Verified that DNF4 already expands transactions automatically during dependency resolution.
Could not find any package in RHEL10 repos that exists with:
same package name
same version
different architecture
No evidence found that DNF4 requires manual architecture sibling expansion.

Validation Performed
Ran:
dnf4 update glibc.x86_64 --assumeno
DNF4 automatically added:
glibc-common
glibc-gconv-extra
glibc-langpack-en

Ran:
dnf4 update kernel.x86_64 --assumeno
DNF4 automatically added:
kernel-core
kernel-modules
kernel-modules-core

Checked multilib configuration:
multilib_policy = best

Searched for packages available in multiple architectures.

Found examples:
cockpit-bridge.noarch
cockpit-bridge.x86_64
osbuild.noarch
osbuild.x86_64
clang-analyzer.noarch
clang-analyzer.x86_64

Verified versions of those packages. Architectures existed, but versions were different.

Example:
cockpit-bridge.noarch 356.2-1.el10_2
cockpit-bridge.x86_64 334.1-1.el10_0

Performed repository-wide scan for same package name, same version and multiple architectures but no matches found

Thoughts:
DNF4 already performs dependency/transaction expansion internally.
Could not reproduce the exact scenario that add_arch_dependencies() was designed for
No evidence found that DNF4 requires additional architecture expansion logic at this time.

E2E Scenarios Testing(After code updates) - September 9th, 2026

1. On demand Assessment (ConfigurePatching can be validated within Assess or Install Patches run)
   8.core.on-demand-assess_config.log
   8.status.txt

2. On demand Installation, Classification: [Critical, Security, Other]
   "classificationsToInclude": ["Security","Other","Critical"]
   Install 1 packages: [sos.noarch]
   10.core.install.1package.log
   10.status.txt

3. Auto assessment, recurring on schedule -
   7.aa.core.log
   7.status.txt

4. Only Package inclusions installed
   Included : tzdata.noarch
   Excluded : tiwilink-firmware.noarch
   11.core.include_exclude.log
   11.status.txt

5. With package exclusions i.e. excluded packages are not installed
   Included : tzdata.noarch
   Excluded : tiwilink-firmware.noarch
   11.core.include_exclude.log
   11.status.txt

6. With Dependent packages i.e. dependent packages identified and installed
   Included : insights-core
   Installed both insights-core and insights-core-selinux.noarch
   13.core.insights-core.log
   13.status.txt

7. Excluding a package because its dependency needs to be excluded : I
   Included: fprintd , Excluded : fprintd-pam
   15.core.fpam.working.log
   15.status.txt

Included : selinux-policy, Excluded : selinux-policy-targeted.
17.core.selinuxworking.log
17.status.txt
17.complete.status.txt

8. Auto Patching request with only security and critical updates in request, which should install all classifications
   "classificationsToInclude": ["Security", "Critical"]
   9.core.security.install.log
   9.status.txt

Logs for disabling auto OS (machine default) updates

9. Machine default updates service installed but NOT enabled
   23.core.service.notimer.log
   23.status.txt
   23.complete.status.txt

10. Machine default updates service NOT installed -
    24.core.noservice.log
    24.status.txt
    24.complete.status.txt

11. Machine default updates service installed and enabled - ConfigurePatching reads and logs that auto OS updates are installed and enabled and disables them. Auto OS updates are disabled
    22.core.autoos_enabled_install.log
    22.status.txt
    22.complete.status.txt

ARM : /subscriptions/6acc8a91-e2b0-4041-a069-c2932ab42fd9/resourceGroups/rhel10-yashna-rg/providers/Microsoft.Compute/virtualMachines/yashna-rhel10-vm

Exclude Use-case issue
Problem Statement.pdf

Updated code ( same as YumPackageManager)

17.core.selinuxworking.log
18.core.fprintworking1.log

[codecov]

Codecov Report

❌ Patch coverage is 96.14243% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.98%. Comparing base (cbd9ac9) to head (105cd95).

Files with missing lines	Patch %	Lines
src/core/src/package_managers/DnfPackageManager.py	93.02%	32 Missing ⚠️
src/core/tests/Test_DnfPackageManager.py	98.68%	5 Missing ⚠️
src/core/src/bootstrap/EnvLayer.py	95.23%	1 Missing ⚠️
src/core/tests/Test_EnvLayer.py	96.87%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #359      +/-   ##
==========================================
+ Coverage   94.93%   94.98%   +0.04%     
==========================================
  Files         111      113       +2     
  Lines       20883    21844     +961     
==========================================
+ Hits        19826    20749     +923     
- Misses       1057     1095      +38     

Flag	Coverage Δ
python27	94.96% <96.14%> (+0.04%)	⬆️
python312	94.95% <96.14%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Adds RHEL 10 support to the LinuxPatchExtension by introducing a DNF4-based package manager implementation and wiring it into package-manager detection and configuration, along with test/mocking updates to cover RHEL10 scenarios.

Changes:

• Introduces Dnf4PackageManager with update discovery, dependency parsing, reboot detection, and auto-OS-update disable/revert logic.
• Updates EnvLayer + ConfigurationFactory to detect and instantiate the new DNF4 flow on RHEL 10.
• Adds/updates unit tests and legacy env-layer command mocks to simulate DNF4/RHEL10 behaviors.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
src/tools/references/cmd_output_references/dnf4_ouput_expected_formats	Adds reference examples of DNF4 output formats used by parsers/tests.
src/core/tests/Test_EnvLayer.py	Updates env-layer tests/mocks to reflect RHEL10 detection and DNF version probing.
src/core/tests/Test_Dnf4PackageManager.py	Adds a new test suite for DNF4 behavior (repo refresh, dependency simulation, auto OS update config, etc.).
src/core/tests/Test_CoreMain.py	Adds an autopatching test covering RHEL10 + DNF4 behavior.
src/core/tests/library/LegacyEnvLayerExtensions.py	Extends the legacy command-output mocking to emulate DNF4 outputs and systemctl/rpm behaviors.
src/core/src/package_managers/Dnf4PackageManager.py	New package-manager implementation for DNF4/RHEL10.
src/core/src/bootstrap/EnvLayer.py	Adds RHEL10 path to select DNF4 based on dnf --version.
src/core/src/bootstrap/Constants.py	Adds Constants.DNF4.
src/core/src/bootstrap/ConfigurationFactory.py	Wires DNF4 into DI configurations.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Michelle McDaniel (michellemcdaniel)]

As a general note, you have varying spacing in some of your function descriptions, i.e. sometimes including a space or not after """ at the beginning of the description and before the ending """ and sometimes excluding those spaces. Please go through and standardize one way or the other for consistency. Same with function calls and including spaces after commas or not. In that case, please include the space.

[yashnap]

As a general note, you have varying spacing in some of your function descriptions, i.e. sometimes including a space or not after """ at the beginning of the description and before the ending """ and sometimes excluding those spaces. Please go through and standardize one way or the other for consistency. Same with function calls and including spaces after commas or not. In that case, please include the space.

Michelle McDaniel (@michellemcdaniel) I've updated the function descriptions to remove spacing from the """start as well as the end""" to keep it consistent. Also added space after , that was missing at multiple places. Somehow when I copy paste code in Pycharm it automatically adds new lines and when putting it back on one the spaces are missed. I think its good now

[Rajasi Rane (rane-rajasi)]

Does RHEL10 have dnf4 commands or dnf? If you use 'dnf ' what version does it use and how does it work?

The RHEL doc here does not use dnf4: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/pdf/managing_software_with_the_dnf_tool/Red_Hat_Enterprise_Linux-10-Managing_software_with_the_DNF_tool-en-US.pdf

Using a generic dnf makes is ideal to expand to other distros in future rather than implementing a package manager for each version.

AND regarding multi-arch dependencies, their doc does confirm the existence of multiple architectures but does not explicitly state that a package with multiple architectures would not have the same version. Even if we don't find an example today, it is always better to have a fail-safe code than one that would break in future. We should add multi arch dependencies in this implementation similar to what we have currently.

[yashnap]

Does RHEL10 have dnf4 commands or dnf? If you use 'dnf ' what version does it use and how does it work?

The RHEL doc here does not use dnf4: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/pdf/managing_software_with_the_dnf_tool/Red_Hat_Enterprise_Linux-10-Managing_software_with_the_DNF_tool-en-US.pdf

Using a generic dnf makes is ideal to expand to other distros in future rather than implementing a package manager for each version.

AND regarding multi-arch dependencies, their doc does confirm the existence of multiple architectures but does not explicitly state that a package with multiple architectures would not have the same version. Even if we don't find an example today, it is always better to have a fail-safe code than one that would break in future. We should add multi arch dependencies in this implementation similar to what we have currently.

• Both dnf --version and dnf --version gives the same output. I can rename all commands to use dnf instead of dnf4.

• I'll update the code to have multi-arch depedencies code in.

[Koshy John (kjohn-msft)]

One comment inline

[yashnap]

UT failure is flaky. I am looking into it. Disregard the Test_ExtOutputStatusHandler.py change. I will be removing that once I verify the sleep time

[Rajasi Rane (rane-rajasi)]

What are the differences between DNF4 and DNF5?

I see a lot of code duplicated between these versions. If the commands and outputs are mostly the same, it makes sense to have a single package manager (single source of code) and address any differences between versions as special cases.

I'm not convinced with the design of having version specific package managers. It will likely need us to implement a package manager for every new version along with an increase in the size of code/build that gets installed on a VM.

I'm thinking this could use a structure similar to how TdnfPackageManager and AzL3TdnfPackageManager are implemented. TdnfPkgMgr is the base/parent with all common code to be used for Mariner (i.e. AzL2) and AzL3 distros, while AzL3TdnfPkgMgr only includes the special cases needed for AzL3

Koshy John (@kjohn-msft), what are your thoughts on this?

[yashnap]

What are the differences between DNF4 and DNF5?

I see a lot of code duplicated between these versions. If the commands and outputs are mostly the same, it makes sense to have a single package manager (single source of code) and address any differences between versions as special cases.

I'm not convinced with the design of having version specific package managers. It will likely need us to implement a package manager for every new version along with an increase in the size of code/build that gets installed on a VM.

I'm thinking this could use a structure similar to how TdnfPackageManager and AzL3TdnfPackageManager are implemented. TdnfPkgMgr is the base/parent with all common code to be used for Mariner (i.e. AzL2) and AzL3 distros, while AzL3TdnfPkgMgr only includes the special cases needed for AzL3

Koshy John (Koshy John (@kjohn-msft)), what are your thoughts on this?

Rajasi Rane (@rane-rajasi) Koshy John (@kjohn-msft)
Agreed — the duplication is a valid concern, and a shared base class (similar to TdnfPackageManager/AzL3TdnfPackageManager) is the right long-term approach.

However, I'd propose doing this refactor as a separate follow-up PR rather than in the current one, for these reasons:

1. Scope — Refactoring requires changes across both package managers and their associated classes
2. Regression risk — It would need full re-testing across both RHEL 10 and Linux 4 distros to ensure nothing breaks
3. Review overhead — A combined feature + refactor PR would be significantly larger and take longer to review, potentially delaying the RHEL 10 feature release

I think it would be safer to land the RHEL 10 support first then take the consolidation as a focused follow-up. I can create a follow-up work item to consolidate DnfPackageManager and Dnf5PackageManager into a shared base class with version-specific overrides.
Let me know your thoughts.

[yashnap]

Failure is related to UT flakines that was introduced in https://github.com/Azure/LinuxPatchExtension/pull/376/changes . I will update the sleep time accordingly.

[Michelle McDaniel (michellemcdaniel)]

What are the differences between DNF4 and DNF5?

I see a lot of code duplicated between these versions. If the commands and outputs are mostly the same, it makes sense to have a single package manager (single source of code) and address any differences between versions as special cases.

I'm not convinced with the design of having version specific package managers. It will likely need us to implement a package manager for every new version along with an increase in the size of code/build that gets installed on a VM.

I'm thinking this could use a structure similar to how TdnfPackageManager and AzL3TdnfPackageManager are implemented. TdnfPkgMgr is the base/parent with all common code to be used for Mariner (i.e. AzL2) and AzL3 distros, while AzL3TdnfPkgMgr only includes the special cases needed for AzL3

Koshy John (Koshy John (@kjohn-msft)), what are your thoughts on this?

Agreed with this. I was also noting a lot of overlap, though it is possible that there is some formatting/other stuff that are quite a bit different? I do think I would rather us have a base DnfPkgMgr, with all the shared code, and then child classes that inherit and override where needed. The less duplicated code we have, the less we have to maintain.

[Koshy John (kjohn-msft)]

What are the differences between DNF4 and DNF5?
I see a lot of code duplicated between these versions. If the commands and outputs are mostly the same, it makes sense to have a single package manager (single source of code) and address any differences between versions as special cases.
I'm not convinced with the design of having version specific package managers. It will likely need us to implement a package manager for every new version along with an increase in the size of code/build that gets installed on a VM.
I'm thinking this could use a structure similar to how TdnfPackageManager and AzL3TdnfPackageManager are implemented. TdnfPkgMgr is the base/parent with all common code to be used for Mariner (i.e. AzL2) and AzL3 distros, while AzL3TdnfPkgMgr only includes the special cases needed for AzL3
Koshy John (Koshy John (Koshy John (@kjohn-msft))), what are your thoughts on this?

Rajasi Rane (Rajasi Rane (@rane-rajasi)) Koshy John (Koshy John (@kjohn-msft)) Agreed — the duplication is a valid concern, and a shared base class (similar to TdnfPackageManager/AzL3TdnfPackageManager) is the right long-term approach.

However, I'd propose doing this refactor as a separate follow-up PR rather than in the current one, for these reasons:

1. Scope — Refactoring requires changes across both package managers and their associated classes
2. Regression risk — It would need full re-testing across both RHEL 10 and Linux 4 distros to ensure nothing breaks
3. Review overhead — A combined feature + refactor PR would be significantly larger and take longer to review, potentially delaying the RHEL 10 feature release

I think it would be safer to land the RHEL 10 support first then take the consolidation as a focused follow-up. I can create a follow-up work item to consolidate DnfPackageManager and Dnf5PackageManager into a shared base class with version-specific overrides. Let me know your thoughts.

Ok to keep it out of this PR.

[Rajasi Rane (rane-rajasi)]

Comments inline and some responses in previous iterations reviews

[Rajasi Rane (rane-rajasi)]

Minor comments inline.

Re-run all the validation tests against the latest code as there have been functional changes since they were run last.

I will approve once the validations are re-run and successful

[Rajasi Rane (rane-rajasi)]

Implemented Dnf4PackageManager by extending PackageManager.

Implemented changes:

• DNF5 package manager
• ConfigurePatching operation
• Auto Assessment operation
• Assessment operation
• Installation operation
• UTs
• Disabling Auto OS updates

TESTS

1. On demand Assessment (ConfigurePatching can be validated within Assess or Install Patches run)
   4.core.log
2. On demand Installation, Classification: [Critical, Security, Other]
   "classificationsToInclude": ["Security","Other","Critical"]
   5.core.log
3. Auto assessment, recurring on schedule -
   2.aa.core.log
   2.core.log
   3.json
4. Only Package inclusions installed
   7.core.log
   Included : python3-perf ( Only installed)
5. With package exclusions i.e. excluded packages are not installed
   Exclude list [xxd, openssl ] - Both not installed
   4.core.log
6. With Dependent packages i.e. dependent packages identified and installed
   6.core.log
   Included : coreutils (It installed dependent packages coreutils-common etc)
7. Excluding a package because its dependency needs to be excluded : I
   5.core.log
   Included: fprintd , Excluded : fprintd-pam
8. Auto Patching request with only security and critical updates in request, which should install all classifications
   "classificationsToInclude": ["Security", "Critical"]
   9.core.log

Logs for disabling auto OS (machine default) updates

9. Machine default updates service installed but NOT enabled - 4.core.log
10. Machine default updates service NOT installed -
    autoOS_notInstalled_.log
11. Machine default updates service installed and enabled - ConfigurePatching reads and logs that auto OS updates are installed and enabled and disables them. Auto OS updates are disabled

[8.core.log](https://github.com/user-attachments/files/29564822/8.core.log)

**Note on Redhat machine not being able to get updates with the below message: ** Unable to read consumer identity This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

• This message shows up on the VM when any command is run. Error message is being thrown so the customer is aware of what is happening.

**Add Multi_arch_dependencies:** Evaluated whether DNF4 needs add_arch_dependencies() logic. Verified that DNF4 already expands transactions automatically during dependency resolution. Could not find any package in RHEL10 repos that exists with: same package name same version different architecture No evidence found that DNF4 requires manual architecture sibling expansion.

Validation Performed Ran: dnf4 update glibc.x86_64 --assumeno DNF4 automatically added: glibc-common glibc-gconv-extra glibc-langpack-en

Ran: dnf4 update kernel.x86_64 --assumeno DNF4 automatically added: kernel-core kernel-modules kernel-modules-core

Checked multilib configuration: multilib_policy = best

Searched for packages available in multiple architectures.

Found examples:
cockpit-bridge.noarch
cockpit-bridge.x86_64
osbuild.noarch
osbuild.x86_64
clang-analyzer.noarch
clang-analyzer.x86_64

Verified versions of those packages. Architectures existed, but versions were different.

Example: cockpit-bridge.noarch 356.2-1.el10_2 cockpit-bridge.x86_64 334.1-1.el10_0

Performed repository-wide scan for same package name, same version and multiple architectures but no matches found

Thoughts: DNF4 already performs dependency/transaction expansion internally. Could not reproduce the exact scenario that add_arch_dependencies() was designed for No evidence found that DNF4 requires additional architecture expansion logic at this time.

E2E Scenarios Testing(After code updates) - September 9th, 2026

1. On demand Assessment (ConfigurePatching can be validated within Assess or Install Patches run)
   8.core.on-demand-assess_config.log
   8.status.txt
2. On demand Installation, Classification: [Critical, Security, Other]
   "classificationsToInclude": ["Security","Other","Critical"]
   Install 1 packages: [sos.noarch]
   10.core.install.1package.log
   10.status.txt
3. Auto assessment, recurring on schedule -
   7.aa.core.log
   7.status.txt
4. Only Package inclusions installed
   Included : tzdata.noarch
   Excluded : tiwilink-firmware.noarch
   11.core.include_exclude.log
   11.status.txt
5. With package exclusions i.e. excluded packages are not installed
   Included : tzdata.noarch
   Excluded : tiwilink-firmware.noarch
   11.core.include_exclude.log
   11.status.txt
6. With Dependent packages i.e. dependent packages identified and installed
   Included : insights-core
   Installed both insights-core and insights-core-selinux.noarch
   13.core.insights-core.log
   13.status.txt
7. Excluding a package because its dependency needs to be excluded : I
   Included: fprintd , Excluded : fprintd-pam
   15.core.fpam.working.log
   15.status.txt

Included : selinux-policy, Excluded : selinux-policy-targeted. 17.core.selinuxworking.log 17.status.txt 17.complete.status.txt

8. Auto Patching request with only security and critical updates in request, which should install all classifications
   "classificationsToInclude": ["Security", "Critical"]
   9.core.security.install.log
   9.status.txt

Logs for disabling auto OS (machine default) updates

9. Machine default updates service installed but NOT enabled
   23.core.service.notimer.log
   23.status.txt
   23.complete.status.txt
10. Machine default updates service NOT installed -
    24.core.noservice.log
    24.status.txt
    24.complete.status.txt
11. Machine default updates service installed and enabled - ConfigurePatching reads and logs that auto OS updates are installed and enabled and disables them. Auto OS updates are disabled
    22.core.autoos_enabled_install.log
    22.status.txt
    22.complete.status.txt

ARM : /subscriptions/6acc8a91-e2b0-4041-a069-c2932ab42fd9/resourceGroups/rhel10-yashna-rg/providers/Microsoft.Compute/virtualMachines/yashna-rhel10-vm

Exclude Use-case issue Problem Statement.pdf

Updated code ( same as YumPackageManager)

17.core.selinuxworking.log 18.core.fprintworking1.log

Most tests look good, some comments on a few:

• 5: With package exclusions i.e. excluded packages are not installed --> To truly test exclusions, do not use inclusions in the same test. What is happening here is, any package not in the inclusion list is not selected. The code does not go upto exclusions list at all
• 8: Auto Patching request with only security and critical updates in request, which should install all classifications -> This is not truly an Auto Patching test but one where only Security and Critical classifications are selected. A true Auto Patching test would be one where patchMode is set to AutoByPlatform and the patch operation is auto triggered during the usual patching window
• I see you have fixed the the exclude use case, for which a problem statement is attached. Maybe word the note a little different to state the problem is now fixed. My first impression of it was that this is an existing issue with the code in PR.

[Rajasi Rane (rane-rajasi)]

My previous comment raised some fallacies in the tests, please review them for future PRs. Approving this one, since the issues raised in there were address in other tests. For eg: exclusion is tested in test case: 7 and all aspects of auto patching (i.e. installation + disabling machine default os updates, enabling auto assessment, if needed, etc) are validated in other separate tests.