Hi, I remember that in the past there was a guide to build custom kernels and package them the manjaro way, so that they could be installed side to side to the official manjaro kernels.
If I remember correctly, this was at some post in https://archived.forum.manjaro.org/t/how-to-compile-the-mainline-kernel-the-manjaro-way/51700.
Unfortunately, that document is now inaccessible (as it belonged to the old forum). Would it be possible to have those instructions again?
Thanks!
That is what the internet wayback machine is for
But since it is a 4 years old topic i would wait till someone confirms this is still valid.
Generally speaking, all the patches for manjaro over the generic linux kernel are here
Unfortunately, the single snapshot on the wayback machine seems to miss the last part of the thread. One where there were instructions from Philm on how to change “-MANJARO” into something else to mark the kernel as custom and on how to guarantee compatibility with kernel modules shipped with other packages (e.g., the virtualbox support).
You do this by editing the EXTRAVERSION string in the Makefile. It’s near the top of the file.
Building with PKGBUILD you get no direct control on the Makefile, though. You can only edit the PKGBUILD script itself, add patches and modify the config. So I guess you need to know how to change the PKGBUILD.
Well, it’s a shell script, so it’s plain text. The EXTRAVERSION will be defined in there as a variable somewhere. Run a case-sensitive search inside the file for “MANJARO”, and that should give you a starting point.
Unfortunately, there is no “EXTRAVERSION” definition in PKGBUILD.
There is a _kernelname=-MANJARO, but it seems to be a leftover, not being used anywhere in the rest of the script. And in fact it does not exist at all in the -rt kernels.
And finally there is a matching CONFIG_LOCALVERSION=-MANJARO in config.
Now, in lack of instructions, I have started experimenting that is a rather painful thing to do in an uninformed way since a kernel compilation via the PKGBUILD on my machine takes 3 hours.
Changing the pkgbase definition into something like pkgbase=linux${_basever}-custom (to get a recognizable package and one that does not overlap with regular kernels), removing the unused _kernelname=-MANJARO definition and changing CONFIG_LOCALVERSION into CONFIG_LOCALVERSION=-custom in config lets the kernel packages be built. However these packages cannot be installed. Trying to install them ends up in an error (with an uninformative message) when the initrd gets built.
Any clue?
I have also tried looking at the PKGBUILD for the -rt kernels, as an inspiration on how to get a package for a kernel variant that can coexist with the regular kernels. Unfortunately, this PKGBUILD is rather misaligned with the regular one (they appear to have diverged a lot) so the diff between the -rt kernel PKGBUILD and the corresponding regular kernel PKGBUILD is very large and it is not easy to immediately spot the relevant differences.
That is the one I meant.
Mind you, it has been roughly 20 years since I last compiled a kernel from sources, and they were always the upstream sources from kernel.org itself. 
A problem with the missing signature, perhaps? What is the content of your /etc/pacman.conf?
And what is that “uninformative message”? Maybe it’s uninformative to you, but someone else might be able to make sense of it.
You are right, I should have posted it… it is:
-> Running build hook: [filesystems]
==> ERROR: module not found: 'crc32c_intel'
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-6.18-x86_64.img'
==> WARNING: errors were encountered during the build. The image may not be complete.
error: command failed to execute correctly
The error is not the ==> ERROR: module not found: 'crc32c_intel' that happens even with the manjaro official 618, rather the last error: command failed to execute correctly where error appears in red in my terminal.
I believe that there is probably already an issue in that the initrd filename does not include the local-version, so it cannot coexist with that of the official 6.18.
This is actually VERY specific. Comment it out or delete it from the mkinitcpio.conf and regenerate the initrd.
How are you executing the command? Via sudo, su, a direct root login, or run0?
If that last one, that’s what got myself into trouble in June of 2025, so I’ve been avoiding run0 like the plague since then.
The above said, it may also be possible that your error would indeed be the result of the absence of crc32_intel, which is no longer needed — the module has been renamed, and the kernel no longer needs it because it already has its own inbuilt routines for handling CRC32 checksums.
I just got curious - I do occasionally build a kernel but I use the linux-next-git from AUR with modprobedb to get a kernel precisely for my system.
But out of curiosoty
Clone the linux618 from gitlab and change the following in the PKGBUILD
_basever="${_basekernel//.}-custom"
_kernelname="-CUSTOM"
PKGDEST=$PWD makepkg -s
Now I am waiting for the build to complete…
And done
14:07:38 ± [fh@tiger] .../pkgbuilds/linux618
[master U:1] $ PKGDEST=$PWD makepkg -s
==> Making package: linux618-custom 6.18.6-1 (tor 22 jan 2026 14:07:54 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
[sudo] password for fh:
....
==> Leaving fakeroot environment.
==> Finished making: linux618-custom 6.18.6-1 (tor 22 jan 2026 14:28:10 CET)
14:28:10 ± [fh@tiger] .../pkgbuilds/linux618
[master U:1 ?:11] $ ls -l *.pkg.tar.zst
-rw-r--r-- 1 fh fh 151541254 22 jan 14:27 linux618-custom-6.18.6-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 fh fh 40979155 22 jan 14:28 linux618-custom-headers-6.18.6-1-x86_64.pkg.tar.zst
This is in installing the package. So I am doing it either with pamac as my own user (since pamac nicely asks for privilege elevation itself) or with sudo pacman. Same way in which I am installing official kernels.
Yes, but that leftover is also there for the “official” manjaro kernels, for which the error message is printed, but is just noise. So it should be noise also for my kernel.
In my case, the issue is changing the local name in the config. This change probably needs to be associated to some other change that I am missing, and I am trying to find out what it is.
If I remember correctly, the guide by Philm that disapeared with the old forum carried some info on that, and this is why I hoped that Philm or someone else had saved it so it could be put in the current forum.
In general, it would be very nice to have a guide describing how to create kernel packages compatible with Manjaro.
In my case, I need it because of a nasty kernel bug that causes filesystem errors (and possibly corruption) when the /home is on an sd-card. There is a patch for it but it is not in mainline, so for the near future I might need to create my own kernel packages with the patch.
What do mean by compatible ?
Manjaro is theming and tools - it work on top of any kernel - as mentioned - I have built the linux-next several times - sometimes once a week for months - no issues.
git clone https://aur.archlinux.org/linux-next-git
If you use a custom kernel AND you rely on anything not provided by the kernel - I strongly advise to use DKMS modules for that e.g. bcachefs, nvidia, virtualbox et.el.
So what I do is very much the trial and error approach.
I also use variables to eliminate the human error factor.
| Version | Timestamp | |
|---|---|---|
| Revision | 10 | 2026-01-23T07:40:00Z |
| 12 | 2026-01-23T10:17:00Z | |
| 13 | 2026-01-23T10:35:00Z | |
This script is valid as of 2026-01-22T23:00:00Z - anyone reading this months or years from now - please validate - make no assumptions about the state of the Manjaro kernel buildscripts.
#!/usr/bin/env bash
####---- version 13 ----####
# date=2026-01-23 time=11:35:00 timezone="Europe/Copenhagen"
# define custom kernel identifier
custom="custom"
# define custom build host
host="$(hostnamectl hostname)"
# define custom build user
user=$USER
# define builddir - default to user's home
builddir=$HOME
# define manjaro kernel name to work with
manjaro_kernel=linux618
# define the kernel configuration path
kernel_config=${builddir}/${manjaro_kernel}/config
# define the pkgbuild path
pkgrecipe=${builddir}/${manjaro_kernel}/PKGBUILD
# cd into builddir
cd ${builddir}
# remove ${manjaro_kernel} dir if it exist
[[ -d ${builddir}/${manjaro_kernel} ]] && rm -rf ${builddir}/${manjaro_kernel}
# clone Manjaro package build recipe
git clone https://gitlab.manjaro.org/packages/core/${manjaro_kernel}.git ${builddir}/${manjaro_kernel}
# change working folder
cd ${builddir}/${manjaro_kernel}
# --------------------------
# modify build recipe
# add '-CUSTOM' to kernel name
sed -i 's|^_kernelname=.*|_kernelname=\"-'${custom}'\"|g' ${pkgrecipe}
# add '-custom' to package base name
sed -i 's|^pkgbase=.*|pkgbase="linux\${_basever}-'${custom}'\"|g' ${pkgrecipe}
# add '-custom' to the kernel name
sed -i 's|\"\${_basekernel}-\${CARCH}\"|\"\${_basekernel}-'${custom}'-\${CARCH}\"|g' ${pkgrecipe}
# --------------------------
# modify kernel config
# set KBUILD_BUILD_HOST to current hostname
sed -i 's|^export KBUILD_BUILD_HOST=.*|export KBUILD_BUILD_HOST=\"'${host}'\"|g' ${pkgrecipe}
# set KBUILD_BUILD_USER to current user
sed -i 's|^export KBUILD_BUILD_USER=.*|export KBUILD_BUILD_USER=\"'${user}'\"|g' ${pkgrecipe}
# set kernel config CONFIG_LOCALVERSION to '-CUSTOM'
sed -i 's|^CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=\"-'${custom}'\"|g' ${kernel_config}
# set kernel config CONFIG_DEFAULT_HOSTNAME to current hostname
sed -i 's|^CONFIG_DEFAULT_HOSTNAME=.*|CONFIG_DEFAULT_HOSTNAME=\"'${host}'\"|g' ${kernel_config}
# update pkgsums
updpkgsums
# run makepkg
PKGDEST=${builddir}/${manjaro_kernel} makepkg -s
This is basically what I did before. The kernel builds correctly into two packages (one for the kernel itself and one for the headers). However the resulting kernel package is not OK and fails to install properly with the error: command failed to execute output, as mentioned before. Furthermore, when installing, the initramfs it tries to create gets named initramfs-6.18-x86_64.img, while I would like it to carry the local name too, so that my custom 618 kernel can be installed side to side with the official 618 kernel, without having one rewrite the initramfs of the other.
The name of the initramfs is only important to the boot loader. The kernel itself does not contain any reference to the initramfs by name. It is the boot loader which loads the kernel with a specified initramfs.
In other words, you can manually rename the initramfs to whatever you want, and then modify the boot loader entry for your custom kernel to load the initramfs of your choice.
Please let me emphasize - I am not experienced enough to see all through a PKGBUILD - let alone a kernel PKGBUILD. There is way too many environment variables in play…
So what I do is very much the trial and error approach.
I also use variables to eliminate the human error factor.
I didn’t get that error, the package build and install perfectly.
But I did note something else - and realised it was the pkgbase
variable that should have the -custom appended not the _basever.
I have edited the commands above - 10 times now - adding more comments and
moved the -custom tag from _basever to pkgname.
I am running a build right now - to check.
EDIT:
The resulting package install as expected.
It creates the following files
The resulting init/kernel will have the expected filenames
To make a custom Linux 6.18 fully coexist with a Manjaro 6.18 you will need to do script actions that
In the PKGBUILD _package() function we have this
# Used by mkinitcpio to name the kernel
echo "$pkgbase" | install -Dm644 /dev/stdin "$modulesdir/pkgbase"
echo "${_basekernel}-${CARCH}" | install -Dm644 /dev/stdin "$modulesdir/kernelbase"
This is the point I have reached on my speculation on how to achieve naming the final init/kernel image.
Currently it becomes initramfs-6.18-x86_64.img and vmlinuz-6.18-x86_64.
To become totally co-existing - the file names would ideally become
initramfs-6.18-custom-x86_64.img and vmlinuz-6.18-custom-x86_64.
EDIT
And with the latest iteration (v13) this has also been achieved.
Interesting learning experience …
@linux-aarhus Thanks for your help, I’ll try to use your final solution asap!