feat(kernel): Use CBL-Mariner-Linux-Kernel Source by rlmenge · Pull Request #15961 · microsoft/azurelinux

rlmenge · 2026-02-24T08:07:32Z

Adds a custom Azure Linux kernel based on the Fedora 43 upstream kernel spec, using CBL-Mariner-Linux-Kernel 6.18.5.1 sources. This replaces the previous minimal kernel stub with a fully overlayed component that builds kernel 6.18.5.1 with Azure Linux-specific configs.

Changes
Initial kernel overlay (a8b9e29)

Replaced the minimal kernel.comp.toml stub with a full overlay-based component targeting the Fedora 43 upstream kernel spec
Added CBL-Mariner-Linux-Kernel 6.18.5.1 tarball as an external source with SHA512 verification
Added Azure Linux kernel configs for x86_64 (8,078 lines) and aarch64 (12,555 lines)

Overlays include:

specrpmversion / specversion / tarfile_release / pkgrelease / specrelease set to 6.18.5.1
Source0 repointed to the CBL-Mariner tarball with extraction path fix
Azure Linux config files (not yet used)
kextraversion = ".1" prepended to EXTRAVERSION so uname -r = 6.18.5.1-1.azl4.x86_64 (matches module path)
Redhat patch declaration and application disabled

Testing

Built successfully with azldev comp build -p kernel — produces 13 RPMs including kernel-6.18.5.1-1.azl4.x86_64.rpm
Built VM image with azldev image build vm-base --local-repo ./base/out
Booted in QEMU (vm-base) — uname -r = 6.18.5.1-1.azl4.x86_64 confirmed

[test@azurelinux-vm ~]$ uname -a
Linux azurelinux-vm 6.18.5.1-1.azl4.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Feb 24 18:44:34 UTC 2026 x86_64 GNU/Linux
[test@azurelinux-vm ~]$ cat /etc/os-release
NAME="Azure Linux"
VERSION="4.0 (Evergreen Prerelease)"
RELEASE_TYPE=development
...
[test@azurelinux-vm ~]$

Deployed to Azure VM (Standard_D4s_v3, westus3) — uname -r = 6.18.5.1-1.azl4.x86_64 confirmed via SSH
built in koji taskID=241090

rlmenge · 2026-02-24T21:43:30Z

+defines = { debugbuildsenabled = "0", azl_pkgrelease = "1", kextraversion = ".1" }
+without = ["debug", "configchecks"]
+
+[[components."kernel".source-files]]


This will change to use our copy of the source rather than the GitHub hosted.

Copilot

Pull request overview

This PR introduces a custom Azure Linux kernel component based on Fedora 43's upstream kernel spec, using CBL-Mariner-Linux-Kernel 6.18.5.1 sources. The implementation replaces a minimal kernel stub with a comprehensive overlay-based configuration that includes Azure Linux-specific kernel configs for x86_64 and aarch64 architectures.

Changes:

Adds kernel 6.18.5.1 component with full overlay-based customization of Fedora 43 kernel spec
Includes Azure Linux kernel configurations (8,079 lines for x86_64, 12,556 lines for aarch64)
Configures version macros, source handling, and disables Fedora-specific patches to align with Azure Linux requirements

Reviewed changes

Copilot reviewed 2 out of 4 changed files in this pull request and generated 5 comments.

File	Description
base/comps/kernel/kernel.comp.toml	Main component definition with 13 overlays to customize Fedora kernel spec for Azure Linux 6.18.5.1, including version macros, source declarations, config file installation, and patch handling
base/comps/kernel/sources	SHA512 checksum file for kernel-6.18.5.1.tar.gz tarball verification (Fedora dist-git convention)

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

reubeno · 2026-02-25T15:53:33Z

+replacement = """%define azurelinux_version 3
+%define specrpmversion 6.18.5.1"""
+
+[[components.kernel.overlays]]


Since you have so many overlays, consider whether you'd find it easier to read like this or formatted like we did here.

That's also purely a matter of style and taste for you to decide.

It looks like our current suggestion is not to use the overlay array? https://github.com/microsoft/azurelinux/blob/tomls/base/main/.github/instructions/comp-toml.instructions.md

That was AI generated and not something I'd agree with. I think it's a developer taste preference for readability right now.

reubeno · 2026-02-25T15:54:15Z

+replacement = 'EXTRAVERSION = %{kextraversion}-${ShortRel}'
+
+[[components.kernel.overlays]]
+description = "Disable redhat patch declaration"


There's a patch-remove overlay that we added based on @ddstreet's feedback; you should consider whether that will work for you.

Looks like patch-remove doesn't work for the kernel's redhat patch.

AI summary from my tests:

Macro form (file = "patch-%{patchversion}-redhat.patch") — patch-remove doesn't match because it parses the Patch1: tag structurally rather than matching raw text, and fails to handle %{patchversion} as a literal string.

Resolved form (file = "patch-6.18-redhat.patch") — also fails, suggesting the parser doesn't fully resolve RPM macros either.

Neither form finds a match. Sticking with replace for now but also trying to update the patch remove to handle macros

reubeno · 2026-02-25T15:58:06Z

+[[components.kernel.overlays]]
+description = "Add Azure Linux x86_64 config file"
+type = "file-add"
+file = "6.18-x86_64-azl.config"


This is going to be a complicated one, necessarily. Please do give us feedback on maintainability.

For example, we haven't thought about variable setting/replacement in TOML files but I see that you need to replicate 6.18 or 6.18.5.1 or similar in a number of places. The ideal would be to refer to spec macros for that and %define that in one place, but some of the references here are TOML-specific ones that don't get RPM spec macro-expanded. We could consider allowing something like:

[components.kernel.variables] kernel-minor = "6.18" [[components.kernel.overlays]] type = "spec-search-replace" ... replacement = "something something something {kernel-minor} something" expand-vars = true

...but we'll definitely want to make sure it's worth the complexity to add it before we jump to doing something like that. Your feedback will help 😄

ddstreetmicrosoft · 2026-02-27T19:11:59Z

The kernel is uniquely complicated; I think maintaining a full patched spec and corresponding build files should be seriously considered. Will that be easier to understand and maintain than the toml?

rlmenge · 2026-02-27T20:15:44Z

The kernel is uniquely complicated; I think maintaining a full patched spec and corresponding build files should be seriously considered. Will that be easier to understand and maintain than the toml?

Agreed. I have a seperate workstream where I am evaluating making a simplified version of the kernel.spec. This will likely be presented as a new PR but in the effort of getting something I am moving with Fedora's kernel (as well as giving myself time to stumble upon all the side effects of how Fedora formats their modules, uname etc)

ddstreetmicrosoft

The kernel is uniquely complicated; I think maintaining a full patched spec and corresponding build files should be seriously considered. Will that be easier to understand and maintain than the toml?

Agreed. I have a seperate workstream where I am evaluating making a simplified version of the kernel.spec. This will likely be presented as a new PR but in the effort of getting something I am moving with Fedora's kernel (as well as giving myself time to stumble upon all the side effects of how Fedora formats their modules, uname etc)

I'm good with that, but I think this patchset is complex enough that it needs a logical rebase to be able to properly review it.

…ernel This change introduces the source tar from the following link but does not use it https://github.com/microsoft/CBL-Mariner-Linux-Kernel/archive/rolling-lts/mariner-3/6.18.5.1.tar.gz

RedHat includes a patch which modfies the kernel source to RHEL specifications. Disable to not impact our source. May be useful in future to include some of the relevant toggles.

To use the kernel source, we needed to update a few defines in the spec. specrpmversion: Used to populate kernel version for other defines specversion: Used to make the KVERREL variable used other places patchversion: Ignored and therefore not overwritten in toml pkgrelease: Used for dir for documentation specrelease: Used for RPM release tag Additionally, remove the rhel Makefile.

rlmenge · 2026-02-28T02:19:58Z

The kernel is uniquely complicated; I think maintaining a full patched spec and corresponding build files should be seriously considered. Will that be easier to understand and maintain than the toml?

Agreed. I have a seperate workstream where I am evaluating making a simplified version of the kernel.spec. This will likely be presented as a new PR but in the effort of getting something I am moving with Fedora's kernel (as well as giving myself time to stumble upon all the side effects of how Fedora formats their modules, uname etc)

I'm good with that, but I think this patchset is complex enough that it needs a logical rebase to be able to properly review it.

I have rebased and restructred the commits to be a more logical flow. The last commit (584177f) is still large due to many defines for the kernel version within the spec. They are all needed to ensure a proper build.

ddstreetmicrosoft

A couple minor comments for your future consideration, in general LGTM

ddstreetmicrosoft · 2026-02-28T02:31:21Z

+[[components.kernel.overlays]]
+description = "Fix tarball extraction path for AzureLinux"
+type = "spec-search-replace"
+regex = "linux-%{tarfile_release}"


be careful here, the regex linux-%{tarfile_release} actually matches twice in the spec:

Source0: linux-%{tarfile_release}.tar.xz
mv linux-%{tarfile_release} linux-%{KVERREL}
I think this is safe because the previous overlay updated the Source0: line, but still I'm a bit concerned about all this regex-replace.

ddstreetmicrosoft · 2026-02-28T02:47:24Z

+description = "Disable copy of Makefile.rhelver (Source1) — not applicable to AzureLinux"
+type = "spec-search-replace"
+regex = "cp -a %{SOURCE1} ."
+replacement = "# cp -a %{SOURCE1} . (disabled for AzureLinux — Makefile.rhelver is Red Hat-specific)"


Is this really needed? I don't see anywhere in the spec that actually refers to any Makefile.rhelver (besides dropping it into the build dir), so I assume the only place that references it is inside fedora's kernel source, which looks like only here. So it should be safe to just leave this unchanged right?

Originally tried this route but I had to add extra Extraversion logic. It was unhappy with the LSG extraversion otherwise

rlmenge marked this pull request as ready for review February 24, 2026 21:41

rlmenge requested review from christopherco, ddstreetmicrosoft and reubeno as code owners February 24, 2026 21:41

Copilot AI review requested due to automatic review settings February 24, 2026 21:41

Copilot started reviewing on behalf of rlmenge February 24, 2026 21:41 View session

rlmenge commented Feb 24, 2026

View reviewed changes

Comment thread base/comps/kernel/kernel.comp.toml Outdated

Copilot AI reviewed Feb 24, 2026

View reviewed changes

Comment thread base/comps/kernel/kernel.comp.toml Outdated

Comment thread base/comps/kernel/kernel.comp.toml

Comment thread base/comps/kernel/kernel.comp.toml

Comment thread base/comps/kernel/kernel.comp.toml Outdated

Comment thread base/comps/kernel/kernel.comp.toml Outdated

rlmenge commented Feb 24, 2026

View reviewed changes

Comment thread base/comps/kernel/kernel.comp.toml Outdated

rlmenge marked this pull request as draft February 24, 2026 22:08

reubeno reviewed Feb 25, 2026

View reviewed changes

rlmenge force-pushed the rlmenge/tomls/kernel-6.18 branch from f312c13 to ded90ff Compare February 27, 2026 17:57

rlmenge marked this pull request as ready for review February 27, 2026 18:46

ddstreetmicrosoft requested changes Feb 27, 2026

View reviewed changes

rlmenge added 2 commits February 27, 2026 22:54

feat(kernel): Include the kernel 6.18 source from CBL-Mariner-Linux-K…

a2c99b0

…ernel This change introduces the source tar from the following link but does not use it https://github.com/microsoft/CBL-Mariner-Linux-Kernel/archive/rolling-lts/mariner-3/6.18.5.1.tar.gz

feat(kernel): Remove rhel related patch

fc305be

RedHat includes a patch which modfies the kernel source to RHEL specifications. Disable to not impact our source. May be useful in future to include some of the relevant toggles.

rlmenge force-pushed the rlmenge/tomls/kernel-6.18 branch from ded90ff to 8de2781 Compare February 28, 2026 01:35

rlmenge force-pushed the rlmenge/tomls/kernel-6.18 branch from 8de2781 to 584177f Compare February 28, 2026 01:42

ddstreetmicrosoft approved these changes Feb 28, 2026

View reviewed changes

ddstreetmicrosoft merged commit 90b418b into tomls/base/main Feb 28, 2026
5 checks passed

ddstreetmicrosoft deleted the rlmenge/tomls/kernel-6.18 branch February 28, 2026 02:50

Conversation

rlmenge commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rlmenge Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ddstreetmicrosoft commented Feb 27, 2026

Uh oh!

rlmenge commented Feb 27, 2026

Uh oh!

ddstreetmicrosoft left a comment

Choose a reason for hiding this comment

Uh oh!

rlmenge commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ddstreetmicrosoft left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

rlmenge commented Feb 24, 2026 •

edited

Loading

rlmenge Feb 27, 2026 •

edited

Loading

rlmenge commented Feb 28, 2026 •

edited

Loading