# How to use pure upstream kernel?

## fluffysheap

I know how to work with the upstream kernel, my concern is more about what differences I should expect compared to the Gentoo-supplied kernel.  I'm using my own configured and built kernel from gentoo-sources, not a binary or genkernel based one.

I know Gentoo has one of the least patched kernels of all distros, but I don't want to trip over anything unexpected.  AFAIK the "gentoo support" option in kernel config just sets other options, so ideally I should be safe just copying my kernel config into the upstream tree and doing make oldconfig, right?  What changes should I be expecting with an upstream kernel?

----------

## alamahant

Hi

if you emerge gentoo-sources with the experimental USE flag then you will have 

```

# Gentoo Linux

CONFIG_GENTOO_LINUX=y

CONFIG_GENTOO_LINUX_UDEV=y

CONFIG_GENTOO_LINUX_PORTAGE=y

CONFIG_GENTOO_LINUX_INIT_SCRIPT=y

CONFIG_GENTOO_LINUX_INIT_SYSTEMD=y

# end of Gentoo Linux

```

and also

```

Processor type and features

.

.

.

# CONFIG_MK8 is not set

# CONFIG_MK8SSE3 is not set

# CONFIG_MK10 is not set

# CONFIG_MBARCELONA is not set

# CONFIG_MBOBCAT is not set

# CONFIG_MJAGUAR is not set

# CONFIG_MBULLDOZER is not set

# CONFIG_MPILEDRIVER is not set

# CONFIG_MSTEAMROLLER is not set

# CONFIG_MEXCAVATOR is not set

# CONFIG_MZEN is not set

# CONFIG_MZEN2 is not set

# CONFIG_MZEN3 is not set

# CONFIG_MPSC is not set

# CONFIG_MCORE2 is not set

# CONFIG_MATOM is not set

# CONFIG_MNEHALEM is not set

# CONFIG_MWESTMERE is not set

# CONFIG_MSILVERMONT is not set

# CONFIG_MGOLDMONT is not set

# CONFIG_MGOLDMONTPLUS is not set

# CONFIG_MSANDYBRIDGE is not set

# CONFIG_MIVYBRIDGE is not set

# CONFIG_MHASWELL is not set

# CONFIG_MBROADWELL is not set

# CONFIG_MSKYLAKE is not set

# CONFIG_MSKYLAKEX is not set

# CONFIG_MCANNONLAKE is not set

# CONFIG_MICELAKE is not set

# CONFIG_MCASCADELAKE is not set

# CONFIG_MCOOPERLAKE is not set

# CONFIG_MTIGERLAKE is not set

# CONFIG_MSAPPHIRERAPIDS is not set

# CONFIG_MROCKETLAKE is not set

# CONFIG_MALDERLAKE is not set

# CONFIG_GENERIC_CPU is not set

# CONFIG_GENERIC_CPU2 is not set

# CONFIG_GENERIC_CPU3 is not set

# CONFIG_GENERIC_CPU4 is not set

CONFIG_MNATIVE_INTEL=y

# CONFIG_MNATIVE_AMD is not set

```

ie options to compile the kernel with -march=native or -march=<specific-cpu>

You will prompted about these when you run "make menu|oldconfig"

I usually emerge gentoo-sources and throw in an Arch .config of the same version.

----------

## Tony0945

Uh, I compile my kernels with CONFIG_MNATIVE_AMD=y not INTEL.

It depends on your CPU. I don't understand why CONFIG_NATIVE was broken in two. Surely the build system can tell if it's detected CPU is an AMD or INTEL.

Also, don't set CONFIG_GENTOO_LINUX_INIT_SYSTEMD=y unless you are running systemd.

```
tony@MSI ~ $ zgrep SYSTEMD /proc/config.gz

# CONFIG_GENTOO_LINUX_INIT_SYSTEMD is not set

tony@MSI ~ $ zgrep MNATIVE /proc/config.gz

# CONFIG_MNATIVE_INTEL is not set

CONFIG_MNATIVE_AMD=y

```

----------

## Hu

If you want to be very cautious, inspect the patch files that convert vanilla-sources into gentoo-sources.  This will tell you in detail what is changed.  You may need proficiency reading the kernel's Kconfig language and reading kernel C code to do this well.

----------

## Juippisi

 *Tony0945 wrote:*   

> 
> 
> Also, don't set CONFIG_GENTOO_LINUX_INIT_SYSTEMD=y unless you are running systemd.
> 
> 

 

AFAIK it's needed if you want to run systemd containers on openrc, though. Something to be aware of.

----------

## Tony0945

Just for clarity by "pure upstream kernel" you mean vanilla-sources, correct?

----------

## alamahant

I think he means

```

. I'm using my own configured and built kernel from gentoo-sources, not a binary or genkernel based one.

```

gentoo-sources

----------

## Tony0945

See this post https://forums.gentoo.org/viewtopic-t-1135833-highlight-.html

Follow the script and you won't trip over configuration. If you haven't set CONFIG_IKCONFIG=y and CONFIG_IKCONFIG_PROC=y, do so.

The script still works by passing an existing config file as a parameter.

----------

## Cuong Nguyen

Tried with sys-kernel/vanilla-sources:5.12.13 and got the following errors

```

* ERROR: sys-kernel/vanilla-sources-5.12.13::gentoo failed (prepare phase):

 *   eapply_user (or default) must be called in src_prepare()!

 * 

 * Call stack:

 *            ebuild.sh, line  809:  Called __ebuild_main 'prepare'

 *   phase-functions.sh, line 1059:  Called __dyn_prepare

 *   phase-functions.sh, line  396:  Called die

 * The specific snippet of code:

 *              die "eapply_user (or default) must be called in src_prepare()!"

 * 

 * If you need support, post the output of `emerge --info '=sys-kernel/vanilla-sources-5.12.13::gentoo'`,

 * the complete build log and the output of `emerge -pqv '=sys-kernel/vanilla-sources-5.12.13::gentoo'`.

 * The complete build log is located at '/var/tmp/portage/sys-kernel/vanilla-sources-5.12.13/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/vanilla-sources-5.12.13/temp/environment'.

 * Working directory: '/var/tmp/portage/sys-kernel/vanilla-sources-5.12.13/work/linux-5.12.13'

 * S: '/var/tmp/portage/sys-kernel/vanilla-sources-5.12.13/work/linux-5.12.13'

```

How to fix it, I want to build upstream kernel source and merge it with Microsoft WSL2-Linux-Kernel to build the latest kernel for Windows WSL2

Thank you

----------

## figueroa

I thought he meant vanilla-sources? The OP's question was vague.

----------

## Hu

 *Cuong Nguyen wrote:*   

> Tried with sys-kernel/vanilla-sources:5.12.13 and got the following errors

 That looks like an ebuild bug, but it would be such an obvious one that I would expect it to have been spotted and fixed already.  Are you using any overlays that would override the kernel eclasses?

----------

## alicela1n

You can emerge the vanilla-sources if you want the upstream mainline kernel sources, without the Gentoo patches!

----------

## Cuong Nguyen

 *Hu wrote:*   

>  *Cuong Nguyen wrote:*   Tried with sys-kernel/vanilla-sources:5.12.13 and got the following errors That looks like an ebuild bug, but it would be such an obvious one that I would expect it to have been spotted and fixed already.  Are you using any overlays that would override the kernel eclasses?

 

No, I use only gentoo repository git-synched from https://github.com/gentoo-mirror/gentoo.git. 2 extra repos are vaeth/mv and lto-overlay. Here is the content of vanilia-sources-5.12.13.ebuild.

```

# Copyright 1999-2021 Gentoo Authors

# Distributed under the terms of the GNU General Public License v2

EAPI="6"

K_NOUSENAME="yes"

K_NOSETEXTRAVERSION="yes"

K_SECURITY_UNSUPPORTED="1"

ETYPE="sources"

inherit kernel-2

detect_version

DESCRIPTION="Full sources for the Linux kernel"

HOMEPAGE="https://www.kernel.org"

SRC_URI="${KERNEL_URI}"

KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sparc ~x86"

```

----------

## Hu

Does it work if you disable those overlays?

----------

## Cuong Nguyen

 *Hu wrote:*   

> Does it work if you disable those overlays?

 

Yes, I eventually renamed all the related folder of the overlays and /etc/poratge/env /etc/portage/package.cflags to hide it. And the emerge was success.

Thank you

----------

## Hu

That suggests one of those overlays provided an eclass that failed to provide the functionality that the vanilla-sources ebuild expected.  This could be because functionality was migrated from the ebuild into the eclass in the Gentoo Portage tree, and the overlay eclass was never updated with equivalent features.  If you can find which overlay provides the bad eclass, it may be worth notifying the maintainer and asking them to adjust the eclass.

----------

