Skip to content
Snippets Groups Projects
Commit 71f54417 authored by Martyn Welch's avatar Martyn Welch
Browse files

Update referenced kernel guide 


The building, patching and maintaining the Apertis kernel guide that we
reference in the image building guide is marked as requiring update. Run
through and update where required to make it more relevant for current
releases.

Signed-off-by: default avatarMartyn Welch <martyn.welch@collabora.com>
parent 41add2a5
No related branches found
No related tags found
1 merge request!600Improve documentation, adding guide on how to build an image for currently unsupported hardware
Hide whitespace changes
Inline Side-by-side
content/guides/buildingpatchingandmaintainingtheapertiskernel.md
+ 168
− 173
View file @ 71f54417
......@@ -2,15 +2,13 @@
date = "2019-11-27"
weight = 100
toc = true
lastmod = "2023-06-26"
title = "Building, Patching and Maintaining the Apertis Kernel"
aliases = [
"/old-wiki/Guidelines/BuildingPatchingAndMaintainingTheApertisKernel"
]
status = "Requires Update"
statusDescription = "This document is only valid for releases from v2019 up to v2021."
+++
This guide will explore a number of workflows for retrieving, patching,
......@@ -48,26 +46,21 @@ using Debian packaging. We want to use this version of the kernel as a
starting point for our modifications. As with most Debian packages, the
upstream source is stored separately from any distribution specific
modifications, scripting and metadata. In the case of the Apertis
kernel, all the required components are stored in a [single git
repository](https://gitlab.apertis.org/pkg/linux), however on
kernel, all the required components are stored in a
[single git repository](https://gitlab.apertis.org/pkg/linux), however on
different branches. To retrieve the git repository run the following git
command:
$ git clone https://gitlab.apertis.org/pkg/linux
$ cd linux
Ensure that you have the branch you're interested in checked out (in
this case, we're interested in the v2019: Apertis release):
$ git checkout apertis/v2019
Before continuing, we will create a fresh branch into which we will
We will create a fresh branch, based on the branch of interested (in
this case, we're interested in the v2023: Apertis release) into which we will
create any changes - that way we have the original branch available
which will help with updating later. We will assume we have a project
called "foo" for the sake of this guide.
$ git branch apertis/v2019-foo
$ git switch apertis/v2019-foo
$ git checkout -b foo/v2023 origin/apertis/v2023
### Option 1: Apertis tools
......@@ -94,12 +87,19 @@ commands:
$ git quiltimport --patches debian/patches --author "Unknown <unknown@example.com>"
<b>Note</b>: We provide a default author to git-quiltimport via the
\`--author "Unknown \<unknown@example.com\>"\` command line argument. We
do this because git-quiltimport is unable to parse the author from some
of the patches and providing a default on the command line avoids the
patching process from being blocked with a request for the author to be
specified.
{{% notice note %}}
We provide a default author to git-quiltimport via the \`--author "Unknown
\<unknown@example.com\>"\` command line argument. We do this because
git-quiltimport is unable to parse the author from some of the patches and
providing a default on the command line avoids the patching process from being
blocked with a request for the author to be specified.
{{% /notice %}}
{{% notice warning %}}
Whilst a kernel can be patched and built without the Apertis tooling installed,
it will not be possible to perform packaging of the modified kernel. If you
are looking for a packaged kernel, take option 1.
{{% /notice %}}
## Adding modifications
......@@ -107,8 +107,8 @@ The extracted and patched kernel source can be used as a baseline for
porting or developing additional features. Existing patches can be
imported using git am, which will import each patch as a separate
commit. If developing additional drivers/board support it is advisable
to break down this work into well explained [atomic
commits](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention).
to break down this work into well explained
[atomic commits](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention).
As a developer you will need to build and test your modifications during
development prior to packaging. There is no single recommended way to
......@@ -151,9 +151,9 @@ in `drivers/misc/Kconfig` (This needs to be added somewhere between the
``` make numberLines
config TRIVIAL
tristate "Trivial driver"
---help---
Trivial example driver to show how to integrate code into the kernel.
tristate "Trivial driver"
help
Trivial example driver to show how to integrate code into the kernel.
```
Finally we need to add the following to the makefile
......@@ -168,9 +168,11 @@ Add and commit these changes to git:
$ git add -f drivers/misc/trivial.c drivers/misc/Kconfig drivers/misc/Makefile
$ git commit -m "Add trivial driver"
Note: Depending on the entries in your `.gitignore` file (such as some
of those present in the packaging repository) may require the use of the
`-f` option when adding files such as `trivial.c` above.
{{% notice note %}}
Depending on the entries in your `.gitignore` file (such as some of those
present in the packaging repository) may require the use of the `-f` option
when adding files such as `trivial.c` above.
{{% /notice %}}
## Building
......@@ -194,12 +196,13 @@ source tree clean:
$ yes "" | make O=../test-build oldconfig
$ make -j $(nproc) O=../test-build
**Note**: Depending on the changes made, modifying the configuration may
not be necessary and/or using the default x86 config may not be
appropriate. It may require a specific configuration to be utilised and
to compile for a specific architecture. This will need to be considered
on a case-by-case basis and your preferred config substituted for
`debian/config/amd64/config`.
{{% notice note %}}
Depending on the changes made, modifying the configuration may not be necessary
and/or using the default x86 config may not be appropriate. It may require a
specific configuration to be utilised and to compile for a specific
architecture. This will need to be considered on a case-by-case basis and your
preferred config substituted for `debian/config/amd64/config`.
{{% /notice %}}
If cross-compilation is needed for your tests, ensure the required
cross-compiler is installed and pass both the desired architecture and
......@@ -217,7 +220,7 @@ boot with a pre-built NFS root. The Apertis provides rootfs for various
architectures, for example the x86_64 (amd64) Apertis v2021.0 nfs
root can be found here:
<https://images.apertis.org/release/v2021/v2021.0/amd64/nfs/>
<https://images.apertis.org/release/v2023/v2023.1/amd64/nfs/>
# Packaging
......@@ -225,9 +228,13 @@ Once local changes have been made, they can be added to the Apertis
packaging so that the modifications can be provided in a packaged
kernel.
**All further discussion covers packaging that requires the
Apertis/Debian tooling. If you do not have a suitable environment and/or
haven't been using the Apertis tooling, stop here.**
{{% notice warning %}}
All further discussion covers packaging that requires the Apertis/Debian
tooling. If you do not have a suitable environment and/or haven't been using
the Apertis tooling, stop here or consider following this guide and installing
the Apertis tools when
[generating the patched kernel source]( {{< ref "#generating-patched-kernel-source" >}}).
{{% /notice %}}
## Updating patch series
......@@ -289,31 +296,30 @@ combined depending on the architecture and even specific board for which
we are building (this is the reason we needed the `make -f debian/rules
setup` command in the building section).
For our custom kernel we are going to build a "standard", non-realtime,
kernel. Create a directory `debian/patches/apertis/`<project_name>
(where <project_name> is the name of the project. The patch names and
paths (relative to the `debian/patches/` directory) should be appended
to the `debian/patches/series` file in the order in which they need to
be applied.
For our custom kernel we are going to build a "standard", non-realtime, kernel.
Create a directory `debian/patches/<project_name>` (where `<project_name>` is
the name of the project). The patch names and paths (relative to the
`debian/patches/` directory) should be appended to the `debian/patches/series`
file in the order in which they need to be applied.
For the above example, make the directory
`debian/patches/apertis/example` and move the generated patch:
For the above example, assuming the project name is `foo`, make the directory
`debian/patches/foo` and move the generated patch:
$ mkdir -p debian/patches/apertis/example
$ mv debian/patches/Add-trivial-driver.patch debian/patches/apertis/example/
$ mkdir -p debian/patches/foo
$ mv debian/patches/Add-trivial-driver.patch debian/patches/foo/
Add the following to the end of `debian/patches/series`:
# Trivial driver example
apertis/example/Add-trivial-driver.patch
foo/Add-trivial-driver.patch
These changes need to be committed into the git repository:
$ git add -f debian/patches/apertis/ debian/patches/series
$ git add -f debian/patches/foo/ debian/patches/series
$ git commit -m "Add trivial driver kernel patch"
[apertis/v2019 1c66c033e] Add trivial driver kernel patch
2 files changed, 65 insertions(+)
create mode 100644 debian/patches/apertis/example/Add-trivial-driver.patch
[foo/v2023 d246c910d5] Add trivial driver kernel patch
2 files changed, 68 insertions(+), 1 deletion(-)
create mode 100644 debian/patches/foo/Add-trivial-driver.patch
## Updating kernel package configuration
......@@ -349,9 +355,9 @@ end of `debian/config/config`:
This change will need committing:
$ git add debian/config/config
$ git add -f debian/config/config
$ git commit -m "Enable trivial driver for all builds"
[apertis/v2019 47ad258fe] Enable trivial driver for all builds
[foo/v2023 1e913d77ee] Enable trivial driver for all builds
1 file changed, 1 insertion(+)
## Update changelog
......@@ -366,48 +372,67 @@ We can use git-buildpackage to automate much of this process. First
though we want to ensure that git is configured with the correct user
name and email:
$ git config --local user.name="User Name"
$ git config --local user.email="user@example.com"
$ git config --local user.name "User Name"
$ git config --local user.email "user@example.com"
Once these are set we can run the following:
$ gbp dch --git-author
$ gbp dch --git-author -l foo -R
We pass `-l foo` so that the local suffix `foo` is added to the version number
rather than incrementing the Apertis version number it's self. Incrementing the
Apertis version number should only be done by the Apertis developers as
incrementing it would collide with the version numbering used by the next
Apertis change.
We also pass `-R` which marks the changes as released. If we don't do this, the
first line of the changelog entry would list as "UNRELEASED" rather than
"apertis". This might be done if mulitple changes are expected to be added to
the next release, with the changelog entry being updated each time and only
marked as released once all changes are applied.
The changelog (`debian/changelog`) will be updated with an entries based
on the subject of the added commits:
$ git diff
diff --git a/debian/changelog b/debian/changelog
index ae9563fe8..0ba50cc86 100644
index 08ea067978..630a2fc3be 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+linux (4.19.67-2co4) UNRELEASED; urgency=medium
@@ -1,3 +1,11 @@
+linux (6.1.20-1+apertis4~v2023foo1) apertis; urgency=medium
+
+ [ User ]
+ * Add trivial driver kernel patch
+ * Enable trivial driver for all builds
+
+ -- User Name <user@example.com> Fri, 20 Sep 2019 17:18:33 +0100
+ -- User Name <user@example.com> Mon, 26 Jun 2023 13:28:19 +0100
+
linux (6.1.20-1+apertis4~v2023) apertis; urgency=medium
* Merge apertis v2024dev1
Now that we have a new version, we also need to update a number of kernel
configuration files to reflect this change in version number. This can be done
with the following command:
Unfortunately we can see that `gbp dch` has incrememted the `co` portion
of the version, from `4.19.67-2co3` to `4.19.67-2co4`. The `co4` portion
of the version number signifies the revisions of the Apertis additions
(as done by Collabora). Incrementing this value would show that the
Apertis package has been updated, which is not the case here (and if we
leave this as it is, it will collide with the version numbering used by
the next Apertis change. To avoid this, we add another element to the
version number, for example here, well use `foo`, so the version number
should be updated to `4.19.67-2co3foo1` to indicate the first `foo`
change on top of `4.19.67-2co3`.
$ debian/apertis/update-metadata
If this is the last of the changes that we plan to make before releasing
the kernel, we should change the `UNRELEASED` tag to `apertis`.
The scope of the changes that this will introduce will depend a little on what
changes have been made to the debian metadata. In this instance it's relatively
minor, changing the following files:
This should now be committed to git:
- `debian/build/version-info`
- `debian/config.defines.dump`
- `debian/control.md5sum`
- `debian/rules.gen`
$ git add debian/changelog
$ git commit -s -m "Release 4.19.67-2co3foo1"
These need to be committed to git, along with the changelog change:
$ git add -f debian/changelog debian/build/version-info debian/config.defines.dump debian/control.md5sum debian/rules.gen
$ DEBIAN_PACKAGE=$(dpkg-parsechangelog -S Source)
$ DEBIAN_VERSION=$(dpkg-parsechangelog -S Version)
$ git commit -s -m "Release ${DEBIAN_PACKAGE} version ${DEBIAN_VERSION}"
## Building package
......@@ -415,7 +440,7 @@ First we need to ensure that the packages required for the build
installed:
$ sudo apt update
$ sudo apt install kernel-wedge quilt bc
$ sudo apt build-dep linux
The following script can be used to perform the build (save as
`build-debian-kernel` one directory above the kernel source):
......@@ -435,7 +460,7 @@ The following script can be used to perform the build (save as
fi
gbp buildpackage \
--git-debian-branch=apertis/v2019-foo \
--git-debian-branch=foo/v2023 \
--git-ignore-new \
--git-prebuild='debian/rules debian/control || true' \
--git-builder='debuild -eDEBIAN_KERNEL_USE_CCACHE=1 -i -I' \
......@@ -454,8 +479,8 @@ recommended.
The script uses git build package (`gbp`) to generate the binary kernel
packages. As mentioned before `gbp` needs to be able to find a original
source archive. We use `--git-debian-branch=apertis/v2019-foo` to tell
`gbp` to use the branch `apertis/v2019-foo` to generate an upstream
source archive. We use `--git-debian-branch=foo/v2023` to tell
`gbp` to use the branch `foo/v2023` to generate an upstream
tarball.
We also specify a build area via the `--git-export-dir` option. As we
......@@ -463,15 +488,14 @@ have specified this as `~/build`, which causes the build and the build
processes artifacts to be extracted/stored in a directory called `build`
in the users home directory.
Note: Such options can also be specified in a file `~/.gbp.conf`. We are
not using that here for simplicity, but this is commonly used by
developers.
{{% notice note %}}
Such options can also be specified in a file `~/.gbp.conf`. We are not using
that here for simplicity, but this is commonly used by developers.
{{% /notice %}}
Let's build the example for amd64 (substitute `amd64` for the desired
architecture if your requirements differ):
$ sudo apt update
$ sudo apt install libelf-dev libssl-dev
$ mkdir ~/build
$ ../build-debian-kernel amd64
......@@ -479,73 +503,37 @@ The built kernel packages will be available in `~/build`.
## Installing package and testing
To test we are going to boot the a minimal image on the Minnowboard. Download
the image and write to an SD Card using bmaptool:
$ wget https://images.apertis.org/release/v2019/v2019.0rc4/amd64/minimal/apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.bmap
--2019-09-26 18:14:45-- https://images.apertis.org/release/v2019/v2019.0rc4/amd64/minimal/apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.bmap
Resolving images.apertis.org (images.apertis.org)... 2a00:1098:0:82:1000:25:2eeb:e3bc, 46.235.227.188
Connecting to images.apertis.org (images.apertis.org)|2a00:1098:0:82:1000:25:2eeb:e3bc|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15513 (15K) [application/octet-stream]
Saving to: ‘apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.bmap’
apertis_v2019-minim 100%[===================>] 15.15K --.-KB/s in 0s
2019-09-26 18:14:45 (238 MB/s) - ‘apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.bmap’ saved [15513/15513]
$ wget https://images.apertis.org/release/v2019/v2019.0rc4/amd64/minimal/apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.gz
--2019-09-26 18:14:56-- https://images.apertis.org/release/v2019/v2019.0rc4/amd64/minimal/apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.gz
Resolving images.apertis.org (images.apertis.org)... 2a00:1098:0:82:1000:25:2eeb:e3bc, 46.235.227.188
Connecting to images.apertis.org (images.apertis.org)|2a00:1098:0:82:1000:25:2eeb:e3bc|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 398529744 (380M) [application/octet-stream]
Saving to: ‘apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.gz’
apertis_v2019-minim 100%[===================>] 380.07M 5.70MB/s in 67s
2019-09-26 18:16:03 (5.65 MB/s) - ‘apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.gz’ saved [398529744/398529744]
$ sudo bmaptool copy apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.gz /dev/sdi
bmaptool: info: discovered bmap file 'apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 1708985 blocks of size 4096 (6.5 GiB), mapped 229302 blocks (895.7 MiB or 13.4%)
bmaptool: info: copying image 'apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.gz' to block device '/dev/sdi' using bmap file 'apertis_v2019-minimal-amd64-uefi_v2019.0rc4.img.bmap'
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdi'
bmaptool: info: copying time: 1m 22.2s, copying speed 10.9 MiB/sec
$
Insert the SD card into the minnowboard and boot. We can see that it's
running a 4.19 kernel:
$ uname -a
Linux apertis 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2co3 (2019-09-24) x86_64 GNU/Linux
Copy the new kernel deb file to the minnowboard (this can be done via
ssh) and install it:
$ sudo mount -o remount,rw /
$ sudo dpkg -i linux-image-4.19.0-6-amd64_4.19.67-2co3foo1_amd64.deb
(Reading database ... 19817 files and directories currently installed.)
Preparing to unpack linux-image-4.19.0-6-amd64_4.19.67-2co3foo1_amd64.deb ...
Unpacking linux-image-4.19.0-6-amd64 (4.19.67-2co3foo1) over (4.19.67-2co3bv2019.0b1) ...
Setting up linux-image-4.19.0-6-amd64 (4.19.67-2co3foo1) ...
To test [download the v2023 SDK]( {{< ref "download.md" >}} ) and
[boot it in virtualbox]( {{< ref "virtualbox.md" >}} ).
We can see that it's running a 6.1 kernel:
user@apertis:~$ uname -a
Linux apertis 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-1+apertis4~v2023 (2023-04-2 x86_64 GNU/Linux
Copy the new kernel deb file to the SDK (this can be done via ssh) and install
it:
user@apertis:~$ sudo dpkg -i linux-image-6.1.0-7-amd64_6.1.20-1+apertis4~v2023foo1_amd64.deb
(Reading database ... 113774 files and directories currently installed.)
Preparing to unpack linux-image-6.1.0-7-amd64_6.1.20-1+apertis4~v2023foo1_amd64.deb ...
Unpacking linux-image-6.1.0-7-amd64 (6.1.20-1+apertis4~v2023foo1) over (6.1.20-1+apertis4~v2023bv2023.0db1) ...
/etc/kernel/postrm.d/zz_removekernel:
/boot/efi is a mountpoint
Setting up linux-image-6.1.0-7-amd64 (6.1.20-1+apertis4~v2023foo1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.19.0-6-amd64
W: Possible missing firmware /lib/firmware/i915/bxt_dmc_ver1_07.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_dmc_ver1_27.bin for module i915
update-initramfs: Generating /boot/initrd.img-6.1.0-7-amd64
...
Reboot and we boot with the new kernel:
$ uname -a
Linux apertis 4.19.0-6-amd64 #1 SMP Apertis 4.19.67-2co3foo1 (2019-09-26) x86_64 GNU/Linux
user@apertis:~$ uname -a
Linux apertis 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Apertis 6.1.20-1+apertis4~v2023foo1 (2023 x86_64 GNU/Linux
We now have the `trivial` driver available:
$ sudo modinfo trivial
filename: /lib/modules/4.19.0-6-amd64/kernel/drivers/misc/trivial.ko
user@apertis:~$ sudo modinfo trivial
filename: /lib/modules/6.1.0-7-amd64/kernel/drivers/misc/trivial.ko
license: GPL
description: Trivial Driver
author: Martyn Welch <martyn.welch@collabora.co.uk
......@@ -553,16 +541,20 @@ We now have the `trivial` driver available:
retpoline: Y
intree: Y
name: trivial
vermagic: 4.19.0-6-amd64 SMP mod_unload modversions
vermagic: 6.1.0-7-amd64 SMP preempt mod_unload modversions
Which we can load and unload, receiving the log messages when we do (we
need to increase the log level seen on the console to get the messages):
$ sudo dmesg -n 7
$ sudo modprobe trivial
[ 379.639027] Trivial module init
$ sudo rmmod trivial
[ 386.541440] Trivial module exit
user@apertis:~$ sudo dmesg -WH &
[1] 987
user@apertis:~$ sudo modprobe trivial
[Jun28 15:50] Trivial module init
user@apertis:~$ sudo rmmod trivial
[ +7.967435] Trivial module exit
user@apertis:~$ fg
sudo dmesg -WH
^C
# Maintenance
......@@ -577,12 +569,12 @@ It may be viable for some or all of the changes made to be upstreamed to
the Apertis kernel. For any change to be considered for this approach
it's likely that (at least) the following criteria would need to be met:
- Changes must be [signed
off](https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=signed%20off#sign-your-work-the-developer-s-certificate-of-origin)
- Changes follow the [kernel coding
style](https://www.kernel.org/doc/html/latest/process/coding-style.html)
- Changes need to be provided as a set of well [formatted
patches](https://www.kernel.org/doc/html/latest/process/submitting-patches.html)
- Changes must be
[signed off](https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=signed%20off#sign-your-work-the-developer-s-certificate-of-origin)
- Changes follow the
[kernel coding style](https://www.kernel.org/doc/html/latest/process/coding-style.html)
- Changes need to be provided as a set of well
[formatted patches](https://www.kernel.org/doc/html/latest/process/submitting-patches.html)
- The changes are either:
- A generic bugfix
- Controlled via kernel configuration options so as to be easily
......@@ -596,16 +588,15 @@ the Apertis team.
## Local maintenance of modified Apertis kernel
It is likely that some Apertis users will make changes to the kernel
that are either inappropriate to be pushed into the upstream Apertis
kernel or for which they are unable or willing to make available in the
upstream kernel. Such changes will need to be managed by the team
responsible for them. The Apertis kernel, as with other Apertis
packages, will be updated over time both to fix bugs and to stay
up-to-date with changes to the Linux kernel. In order for those who are
using a locally modified kernel will need to port their changes over to
the updated kernel. It is expected that these modifications will be
stored in a fork of the Apertis kernel packaging repository.
It is likely that some Apertis users will make changes to the kernel that are
either inappropriate to be pushed into the upstream Apertis kernel or for which
they are unable or willing to make available in the upstream kernel. Such
changes will need to be managed by the team responsible for them. The Apertis
kernel, as with other Apertis packages, will be updated over time both to fix
bugs and to stay up-to-date with changes to the Linux kernel. Those who are
using a locally modified kernel will need to port their changes over to the
updated kernel. It is expected that these modifications will be stored in a
fork of the Apertis kernel packaging repository.
The following guidelines will help minimise the effort required to
successfully achieve this:
......@@ -626,8 +617,8 @@ successfully achieve this:
down bugs.
We will consider 2 cases, a minor Apertis update (for example
`4.19.37-5co4` to `4.19.37-5co5`) and a major update (for example
`4.19.37-5co4` to `4.19.52-1co1`).
`4.19.37-5apertis4` to `4.19.37-5apertis5`) and a major update (for example
`4.19.37-5apertis4` to `4.19.52-1apertis1`).
### Updating after minor upstream changes
......@@ -642,7 +633,7 @@ all that is required.
Major updates represent a change in the upstream source. There is a
greater chance that such changes will require changes to the patches in
the series. So changes may also be applied upstream (should they have
the series. Some changes may also be applied upstream (should they have
been back-ports or previously submitted upstream for inclusion). These
need to be left out and the remainder ported to the new kernel.
......@@ -665,10 +656,14 @@ The [Apertis release flow]( {{< ref "release-flow.md#apertis-release-flow" >}})
stipulates that each Apertis release should include the latest mainline kernel
LTS release. Due to Debian's release cadence being approximately half that of
Apertis', there are 2 Apertis releases for each Debian stable release and the
latest LTS is not always packaged by Debian. As a result it is expected that
Apertis will need to pull from the mainline kernel LTS tree to satisfy it's
requirements. For example, Apertis v2020 ships with a newer version of the
Linux kernel (5.4.x) than Debian Buster (4.9.x) on which it is based.
latest LTS is not always packaged by Debian. As a result the Apertis
development team expected that they will need to pull from the mainline kernel
LTS tree to satisfy it's requirements. For example, Apertis v2024 is tracking a
newer version of the Linux kernel (6.6.x) than Debian Bookworm (6.1.x) on which
it is based.
This process may be necessary if you need to maintain a kernel from a revision
other than one provided by Apertis.
In such cases, special care needs to be taken to update packages from their
respective upstreams:
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
Apertis Website Terms of Use Privacy Policy