Difference between revisions of "Mainline Linux Kernel Configs"

From Xen
m (Building the kernel: added CONCURRENCY_LEVEL to both commands)
(Direct users to the foo-pkg targets and not make-kpkg, reference Linus' tree as well as Konrad's lots of style, formatting and spelling fixes etc)
Line 1: Line 1:
== Getting the current stable version ==
+
== Getting the Current Stable Version ==
 
<span id="stable_version"></span>
 
<span id="stable_version"></span>
With [http://blog.xen.org/index.php/2011/06/14/linux-3-0-how-did-we-get-initial-domain-dom0-support-there/ v3.0 - how did dom0 support get there] has technical details, but the summary is that the 3.0 is "With Linux 3.0 we now have the major components to be classified as a working initial domain aka dom0.". There are bugs, which are documented in [http://wiki.xensource.com/xenwiki/Linux_30_bugs Linux 3.0 and further bugs]
 
   
Download it: [ftp://ftp.kernel.org/pub/linux/kernel/v3.0/linux-3.0.8.tar.bz2] from [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary Linus Torvalds tree]: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+
The current kernel tarballs are linked from the front page of [http://kernel.org kernel.org]. For stable use it is recommended that you use the latest "stable" point release. Alternatively you can clone from the stable git tree at <tt>git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git</tt> ([http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary gitweb]).
   
== Getting the current development version ==
+
== Getting the Current Development Version ==
 
<span id="dev_version"></span>
 
<span id="dev_version"></span>
   
  +
There are two main development trees which are interesting to Xen users/developers.
The current day-to-day development is happening in a [http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=summary Konrad's git tree]
 
  +
  +
=== Mainline Kernel ===
  +
  +
The first is Linus Torvald's mainline git tree which can be found at <tt>git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git</tt> ([http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary gitweb]).
  +
  +
This tree has only one active branch, <tt>master</tt>, but also contains tags for each release and release candidate which can be useful for providing a more concrete baseline for a test or bug report than whatever the current tip happens to be.
  +
  +
=== Xen Development Tree ===
  +
  +
The second is Konrad Rzeszutek Wilk's (the Xen Linux maintainer) tree which is where most day-to-day Xen development work ends up en route to Linus' tree. Konrad's tree can be found at <tt>git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git</tt> ([http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=summary gitweb]).
   
 
The repository has numerous topic branches to track individual lines of development, and a couple of roll-up branches which contain everything merged together for easy compilation and running.
 
The repository has numerous topic branches to track individual lines of development, and a couple of roll-up branches which contain everything merged together for easy compilation and running.
Line 16: Line 25:
 
Current active branches are:
 
Current active branches are:
   
* linux-next - patches that are queued up
+
* linux-next - patches that are queued up to go to Linus Torvald's tree. This includes bug-fixes, new features, etc.
to go to Linus Torvalad's tree. This includes bug-fixes, new features, etc.
 
 
* testing (in Konrad's repository) is off patches being run/developed and obviously going through testing - which means they might not compile or work properly.
 
* testing (in Konrad's repository) is off patches being run/developed and obviously going through testing - which means they might not compile or work properly.
   
== Downloading the git tree ==
+
== Using git ==
   
  +
The primary version control system used for Linux kernel development is [http://git-scm.com/ git]. There are numerous git HOWTOs on the web, we
<pre><nowiki>
 
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux
 
$ cd linux
 
</nowiki></pre>
 
   
  +
To clone Linus' tree:
  +
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
  +
$ cd linux
   
  +
To clone Konrad's tree:
that will automatically check out the 'origin/master' default branch. Note that you need at least 256 MB of free memory, otherwise the "git clone" will fail.
 
  +
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux
  +
$ cd linux
   
  +
This will automatically check out the 'origin/master' default branch.
Changing the branch: You most probably want to use the "linux-next" (or "upstream/xen") branch, so do this:
 
   
  +
If you are using Konrad's tree then you most probably want to use the <tt>linux-next</tt> (or <tt>upstream/xen</tt>) branch:
   
  +
$ git reset --hard
<pre><nowiki>
 
  +
$ git checkout -b xen-next origin/linux-next
$ cd /usr/src
 
  +
Branch xen-next set up to track remote branch refs/remotes/origin/linux-next
$ cd linux
 
  +
Switched to a new branch "xen-next"
$ git reset --hard
 
  +
$ git pull
$ git checkout -b upstream/xen origin/upstream/xen
 
  +
$ git log | less
Branch upstream/xen set up to track remote branch refs/remotes/origin/upstream/xen
 
Switched to a new branch "upstream/xen"
 
$ git pull
 
$ git log | less
 
</nowiki></pre>
 
 
 
(or replace "origin/upstream/xen" with "testing" for example)
 
   
 
Later when you want to update the tree use:
 
Later when you want to update the tree use:
   
  +
$ git pull
   
  +
== Configuring the Kernel ==
<pre><nowiki>
 
$ cd linux
 
$ make clean
 
$ git pull
 
</nowiki></pre>
 
 
 
== Configuring the kernel ==
 
 
<span id="configure_xen"></span>
 
<span id="configure_xen"></span>
   
Configure as normal; you can start with your current .config file or use '''make defconfig'''
+
Configure as normal; you can start with your current <tt>.config</tt> file or use '''make defconfig''' and then:
and then depending on what you want your kernel to do (it can do both):
 
   
  +
$ make menuconfig
 
<pre><nowiki>
 
make menuconfig
 
</nowiki></pre>
 
   
 
NOTE0: Make sure you have correct CPU type (Processor Family) set in the kernel configuration, Xen Dom0 options won't show up at all if you have too old CPU selected (too old means a CPU that doesn't support PAE; Pentium Pro was the first CPU to have PAE).
 
NOTE0: Make sure you have correct CPU type (Processor Family) set in the kernel configuration, Xen Dom0 options won't show up at all if you have too old CPU selected (too old means a CPU that doesn't support PAE; Pentium Pro was the first CPU to have PAE).
Line 72: Line 66:
 
NOTE1: If you're building 32 bit version of the kernel, you first need to enable PAE support, since Xen only supports 32 bit PAE kernels nowadays. Xen kernel build options won't show up at all before you've enabled PAE for 32 bit builds (Processor type and features -> High Memory Support (64GB) -> PAE (Physical Address Extension) Support). PAE is not needed for 64 bit kernels.
 
NOTE1: If you're building 32 bit version of the kernel, you first need to enable PAE support, since Xen only supports 32 bit PAE kernels nowadays. Xen kernel build options won't show up at all before you've enabled PAE for 32 bit builds (Processor type and features -> High Memory Support (64GB) -> PAE (Physical Address Extension) Support). PAE is not needed for 64 bit kernels.
   
=== Configure kernel for domU support ===
+
=== Configuring the Kernel for domU Support ===
   
 
# If building 32 bit kernel make sure you have CONFIG_X86_PAE enabled (which is set by selecting CONFIG_HIGHMEM64G)
 
# If building 32 bit kernel make sure you have CONFIG_X86_PAE enabled (which is set by selecting CONFIG_HIGHMEM64G)
Line 101: Line 95:
 
#* CONFIG_XEN_SELFBALLOONING=y
 
#* CONFIG_XEN_SELFBALLOONING=y
   
=== Configure kernel for dom0 support ===
+
=== Configuring the Kernel for dom0 Support ===
   
 
NOTE: Xen dom0 support depends on ACPI support. Make sure you enable ACPI support or you won't see Dom0 options at all.
 
NOTE: Xen dom0 support depends on ACPI support. Make sure you enable ACPI support or you won't see Dom0 options at all.
Line 124: Line 118:
 
* CONFIG_XEN_BALLOON=y
 
* CONFIG_XEN_BALLOON=y
 
* CONFIG_XEN_SCRUB_PAGES=y
 
* CONFIG_XEN_SCRUB_PAGES=y
 
   
 
If you're using RHEL5 or CentOS5 as a dom0 (ie. you have old udev version), make sure you enable the following options as well:
 
If you're using RHEL5 or CentOS5 as a dom0 (ie. you have old udev version), make sure you enable the following options as well:
Line 136: Line 129:
 
<span id="build_kernel"></span>
 
<span id="build_kernel"></span>
   
  +
After having downloaded and configured the kernel source as above building the kernel is as simple as:
There are two parts when building Xen: [[#build_xen|Xen]] and the Kernel. After Kernel configuration you have to do two things, build the kernel and build the ramdrive.
 
   
  +
$ make all -j <2*number_of_cores>
This is the Ubuntu way:
 
   
  +
The <tt>-j</tt> option tells make how many threads to use, a good number is something like twice the number of processor cores in your system since this allows for I/O (e.g. reading the code from disk) to be interleaved with processing (e.g. compiling the code).
<pre><nowiki>
 
$ cd /usr/src/linux
 
$ sudo make -j <number_of_cores +1>
 
$ sudo apt-get install kernel-package fakeroot
 
$ sudo CONCURRENCY_LEVEL=<number_of_cores +1> make-kpkg clean
 
$ sudo CONCURRENCY_LEVEL=<number_of_cores +1> fakeroot make-kpkg --initrd --append-to-version=-pv kernel-image kernel-headers
 
$ sudo dpkg -i ../<linux-image-3.0.XXX.deb>
 
</nowiki></pre>
 
   
  +
== Installing the Kernel ==
The first line will make the kernel with the hidden configuration file (your file hopefully). You might have to do this several times because you will encounter errors that will requiere turning modules off, and start compiling again. It is a good plactice to use make clean when you change many modules at a time. The next line is used for dpkg but is not really that important. the sudo fakeroot line will create your ramdrive needed to boot. This is the debian way of making the image usable this will event copy it to boot but will not update grub.
 
  +
<span id="install_kernel"></span>
   
  +
=== The <tt>foo-pkg</tt> Targets ===
The old-skool way:
 
   
  +
The kernel contains several makefile targets which can create packages in various formats. These packages include a baseline level of integration with the relevant distros (although not likely to be as good as the distros own packages they are good enough). Even if the distro integration is lacking simply being able to cleanly uninstall the package is a big advantage.
<pre><nowiki>
 
cd linux
 
make clean
 
cp -a .config .config-old
 
make oldconfig
 
make menuconfig (if you need to change something)
 
make bzImage
 
make modules
 
make modules_install
 
# in the following lines replace "version" with the actual kernel version you're compiling.
 
make install
 
# And then generate initrd/initramfs image for your dom0 kernel, example for Fedora/RHEL/CentOS:
 
mkinitrd -f /boot/initrd-version.img version
 
# For Fedora Core the 'make install' does it automatically
 
</nowiki></pre>
 
   
  +
The full list of package targets can be found in the output of <tt>make help</tt>:
  +
$ make help
  +
[...]
  +
Kernel packaging:
  +
rpm-pkg - Build both source and binary RPM kernel packages
  +
binrpm-pkg - Build only the binary kernel package
  +
deb-pkg - Build the kernel as a deb package
  +
tar-pkg - Build the kernel as an uncompressed tarball
  +
targz-pkg - Build the kernel as a gzip compressed tarball
  +
tarbz2-pkg - Build the kernel as a bzip2 compressed tarball
  +
tarxz-pkg - Build the kernel as a xz compressed tarball
  +
perf-tar-src-pkg - Build perf-3.8.0-rc2.tar source tarball
  +
perf-targz-src-pkg - Build perf-3.8.0-rc2.tar.gz source tarball
  +
perf-tarbz2-src-pkg - Build perf-3.8.0-rc2.tar.bz2 source tarball
  +
perf-tarxz-src-pkg - Build perf-3.8.0-rc2.tar.xz source tarball
   
  +
The most interesting targets are the <tt>rpm-pkg</tt>, <tt>binrpm-pkg</tt> and <tt>deb-pkg</tt> targets which cover a wide variety of distros. To use simply invoke with make:
=== Update modules ===
 
  +
$ make deb-pkg
<span id="configure_modules"></span>
 
   
  +
Once this command has completed you should find a suitable package in the parent directory which can be installed with <tt>rpm</tt> or <tt>dpkg</tt> in the usual way, e.g.
You need to update some new modules that your newly created kernel requires with XEN.
 
  +
Please note that often a monholitic kernel is a wise choice as it doesn't necessarilly requires initrd.
 
  +
$ sudo dpkg -i ../linux-image-<version>_<version>_<arch>.deb
  +
  +
=== Manual Installation ===
  +
  +
If you want to install the kernel manually then you can simply do, as root:
  +
  +
# make modules_install
  +
# make install
  +
  +
This will install the necessary files to <tt>/boot</tt> and <tt>/lib/modules</tt> with no tracking (for this reason it is highly advised to use the <tt>foo-pkg</tt> targets).
  +
  +
Once you have installed you may need to rebuild the initramfs by hand (some distros do this automatically as part of the above steps). The tool to do this is usually Distro dependent, e.g. <tt>dracut</tt> (recent Fedora & Red Hat) <tt>mkinitrd</tt> (Older Fedora & Red Hat) or <tt>mkinitramfs</tt> (Debian & Ubuntu). e.g.:
  +
# mkinitrd -f /boot/initrd-<version>.img <version>
  +
# mkinitramfs <version>
  +
  +
=== Obsolete Debian/Ubuntu <tt>make-kpkg</tt> Method ===
  +
  +
Older versions of Debian/Ubuntu used a tool called `make-kpkg` to both build and package the kernel. However this tool is now obsolete. It is recommended to use the above methods instead.
  +
  +
$ sudo make -j <number_of_cores +1>
  +
$ sudo apt-get install kernel-package fakeroot
  +
$ sudo CONCURRENCY_LEVEL=<number_of_cores +1> make-kpkg clean
  +
$ sudo CONCURRENCY_LEVEL=<number_of_cores +1> fakeroot make-kpkg --initrd --append-to-version=-pv kernel-image kernel-headers
  +
$ sudo dpkg -i ../<linux-image-3.0.XXX.deb>
  +
  +
The first line will make the kernel with the hidden configuration file (your file hopefully). You might have to do this several times because you will encounter errors that will require turning modules off, and start compiling again. It is a good practice to use make clean when you change many modules at a time. The next line is used for dpkg but is not really that important. the sudo fakeroot line will create your ramdisk needed to boot. This is the Debian way of making the image usable this will event copy it to boot but will not update grub.
  +
  +
== Update modules ==
  +
<span id="configure_modules"></span>
   
  +
You may need to update some new modules that your newly created kernel requires with Xen. Under new enough versions of Xen (e.g. 4.2 and later) the Xen initscripts should take care of this for you.
   
  +
For older Xen versions you may need to do this yourself by adding the modules to the relevant configuration file. Under Debian and Ubuntu style systems this is <tt>/etc/modules</tt>.
<pre><nowiki>
 
$ sudo vim /etc/modules
 
# /etc/modules: kernel modules to load at boot time.
 
#
 
# This file contains the names of kernel modules that should be loaded
 
# at boot time, one per line. Lines beginning with "#" are ignored.
 
lp
 
rtc
 
# Added these lines
 
xen-evtchn
 
xen-gntdev
 
xen-netback
 
xen-blkback
 
xenfs
 
blktap
 
</nowiki></pre>
 
   
  +
The following modules may be required:
Again this is the Ubuntu way, find a way for your particular distribution to do the same.
 
  +
xen-evtchn
  +
xen-gntdev
  +
xen-netback
  +
xen-blkback
  +
xenfs
  +
blktap
   
 
[[Category:Developers]]
 
[[Category:Developers]]

Revision as of 12:06, 28 January 2013

Getting the Current Stable Version

The current kernel tarballs are linked from the front page of kernel.org. For stable use it is recommended that you use the latest "stable" point release. Alternatively you can clone from the stable git tree at git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git (gitweb).

Getting the Current Development Version

There are two main development trees which are interesting to Xen users/developers.

Mainline Kernel

The first is Linus Torvald's mainline git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (gitweb).

This tree has only one active branch, master, but also contains tags for each release and release candidate which can be useful for providing a more concrete baseline for a test or bug report than whatever the current tip happens to be.

Xen Development Tree

The second is Konrad Rzeszutek Wilk's (the Xen Linux maintainer) tree which is where most day-to-day Xen development work ends up en route to Linus' tree. Konrad's tree can be found at git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git (gitweb).

The repository has numerous topic branches to track individual lines of development, and a couple of roll-up branches which contain everything merged together for easy compilation and running.

NOTE! All active git branches require at least Xen 4.0.1, using older version (4.0.0 or older) will cause problems, xend not starting, etc.

Current active branches are:

  • linux-next - patches that are queued up to go to Linus Torvald's tree. This includes bug-fixes, new features, etc.
  • testing (in Konrad's repository) is off patches being run/developed and obviously going through testing - which means they might not compile or work properly.

Using git

The primary version control system used for Linux kernel development is git. There are numerous git HOWTOs on the web, we

To clone Linus' tree:

   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
   $ cd linux

To clone Konrad's tree:

   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux
   $ cd linux

This will automatically check out the 'origin/master' default branch.

If you are using Konrad's tree then you most probably want to use the linux-next (or upstream/xen) branch:

   $ git reset --hard
   $ git checkout -b xen-next origin/linux-next
   Branch xen-next set up to track remote branch refs/remotes/origin/linux-next
   Switched to a new branch "xen-next"
   $ git pull
   $ git log | less

Later when you want to update the tree use:

   $ git pull

Configuring the Kernel

Configure as normal; you can start with your current .config file or use make defconfig and then:

   $ make menuconfig

NOTE0: Make sure you have correct CPU type (Processor Family) set in the kernel configuration, Xen Dom0 options won't show up at all if you have too old CPU selected (too old means a CPU that doesn't support PAE; Pentium Pro was the first CPU to have PAE).

NOTE1: If you're building 32 bit version of the kernel, you first need to enable PAE support, since Xen only supports 32 bit PAE kernels nowadays. Xen kernel build options won't show up at all before you've enabled PAE for 32 bit builds (Processor type and features -> High Memory Support (64GB) -> PAE (Physical Address Extension) Support). PAE is not needed for 64 bit kernels.

Configuring the Kernel for domU Support

  1. If building 32 bit kernel make sure you have CONFIG_X86_PAE enabled (which is set by selecting CONFIG_HIGHMEM64G)
    • non-PAE mode doesn't work in 2.6.25, and has been dropped altogether from 2.6.26 and newer kernel versions.
  2. Enable these core options (Processor type and features| Paravirtualized guest support]
    • CONFIG_PARAVIRT=y
    • CONFIG_XEN=y
    • CONFIG_PARAVIRT_GUEST=y
    • CONFIG_PARAVIRT_SPINLOCKS=y
  3. And Xen pv console device support (Device Drivers|Character devices
    • CONFIG_HVC_DRIVER=y
    • CONFIG_HVC_XEN=y
  4. And Xen disk and network support (Device Drivers|Block devices and Device Drivers|Network device support)
    • CONFIG_XEN_FBDEV_FRONTEND=y
    • CONFIG_XEN_BLKDEV_FRONTEND=y
    • CONFIG_XEN_NETDEV_FRONTEND=y
  5. And the rest (Device Drivers|Xen driver support)
    • CONFIG_XEN_PCIDEV_FRONTEND=y
    • CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
    • CONFIG_XEN_FBDEV_FRONTEND=y
    • CONFIG_XEN_XENBUS_FRONTEND=y
    • CONFIG_XEN_SAVE_RESTORE=y
    • CONFIG_XEN_GRANT_DEV_ALLOC=m
  6. And for tmem support:
    • CONFIG_XEN_TMEM=y
    • CONFIG_CLEANCACHE=y
    • CONFIG_FRONTSWAP=y
    • CONFIG_XEN_SELFBALLOONING=y

Configuring the Kernel for dom0 Support

NOTE: Xen dom0 support depends on ACPI support. Make sure you enable ACPI support or you won't see Dom0 options at all.

In addition to the config options above you also need to enable:

  • CONFIG_X86_IO_APIC=y
  • CONFIG_ACPI=y
  • CONFIG_ACPI_PROCFS=y (optional)
  • CONFIG_XEN_DOM0=y
  • CONFIG_PCI_XEN=y
  • CONFIG_XEN_DEV_EVTCHN=y
  • CONFIG_XENFS=y
  • CONFIG_XEN_COMPAT_XENFS=y
  • CONFIG_XEN_SYS_HYPERVISOR=y
  • CONFIG_XEN_GNTDEV=y
  • CONFIG_XEN_BACKEND=y
  • CONFIG_XEN_NETDEV_BACKEND=m
  • CONFIG_XEN_BLKDEV_BACKEND=m
  • CONFIG_XEN_PCIDEV_BACKEND=m
  • CONFIG_XEN_PRIVILEGED_GUEST=y
  • CONFIG_XEN_BALLOON=y
  • CONFIG_XEN_SCRUB_PAGES=y

If you're using RHEL5 or CentOS5 as a dom0 (ie. you have old udev version), make sure you enable the following options as well:

  • CONFIG_SYSFS_DEPRECATED=y
  • CONFIG_SYSFS_DEPRECATED_V2=y

For more current Xen related config options check the example .config files from the troubleshooting section, and check the 2.6.18-to-2.6.31-and-higher wiki page.

Building the kernel

After having downloaded and configured the kernel source as above building the kernel is as simple as:

   $ make all -j <2*number_of_cores>

The -j option tells make how many threads to use, a good number is something like twice the number of processor cores in your system since this allows for I/O (e.g. reading the code from disk) to be interleaved with processing (e.g. compiling the code).

Installing the Kernel

The foo-pkg Targets

The kernel contains several makefile targets which can create packages in various formats. These packages include a baseline level of integration with the relevant distros (although not likely to be as good as the distros own packages they are good enough). Even if the distro integration is lacking simply being able to cleanly uninstall the package is a big advantage.

The full list of package targets can be found in the output of make help:

   $ make help
   [...]
   Kernel packaging:
     rpm-pkg             - Build both source and binary RPM kernel packages
     binrpm-pkg          - Build only the binary kernel package
     deb-pkg             - Build the kernel as a deb package
     tar-pkg             - Build the kernel as an uncompressed tarball
     targz-pkg           - Build the kernel as a gzip compressed tarball
     tarbz2-pkg          - Build the kernel as a bzip2 compressed tarball
     tarxz-pkg           - Build the kernel as a xz compressed tarball
     perf-tar-src-pkg    - Build perf-3.8.0-rc2.tar source tarball
     perf-targz-src-pkg  - Build perf-3.8.0-rc2.tar.gz source tarball
     perf-tarbz2-src-pkg - Build perf-3.8.0-rc2.tar.bz2 source tarball
     perf-tarxz-src-pkg  - Build perf-3.8.0-rc2.tar.xz source tarball

The most interesting targets are the rpm-pkg, binrpm-pkg and deb-pkg targets which cover a wide variety of distros. To use simply invoke with make:

   $ make deb-pkg

Once this command has completed you should find a suitable package in the parent directory which can be installed with rpm or dpkg in the usual way, e.g.

   $ sudo dpkg -i ../linux-image-<version>_<version>_<arch>.deb

Manual Installation

If you want to install the kernel manually then you can simply do, as root:

   # make modules_install
   # make install

This will install the necessary files to /boot and /lib/modules with no tracking (for this reason it is highly advised to use the foo-pkg targets).

Once you have installed you may need to rebuild the initramfs by hand (some distros do this automatically as part of the above steps). The tool to do this is usually Distro dependent, e.g. dracut (recent Fedora & Red Hat) mkinitrd (Older Fedora & Red Hat) or mkinitramfs (Debian & Ubuntu). e.g.:

   # mkinitrd -f /boot/initrd-<version>.img <version>
   # mkinitramfs <version>

Obsolete Debian/Ubuntu make-kpkg Method

Older versions of Debian/Ubuntu used a tool called `make-kpkg` to both build and package the kernel. However this tool is now obsolete. It is recommended to use the above methods instead.

   $ sudo make -j <number_of_cores +1>
   $ sudo apt-get install kernel-package fakeroot
   $ sudo CONCURRENCY_LEVEL=<number_of_cores +1> make-kpkg clean
   $ sudo CONCURRENCY_LEVEL=<number_of_cores +1> fakeroot make-kpkg --initrd --append-to-version=-pv kernel-image kernel-headers
   $ sudo dpkg -i ../<linux-image-3.0.XXX.deb>

The first line will make the kernel with the hidden configuration file (your file hopefully). You might have to do this several times because you will encounter errors that will require turning modules off, and start compiling again. It is a good practice to use make clean when you change many modules at a time. The next line is used for dpkg but is not really that important. the sudo fakeroot line will create your ramdisk needed to boot. This is the Debian way of making the image usable this will event copy it to boot but will not update grub.

Update modules

You may need to update some new modules that your newly created kernel requires with Xen. Under new enough versions of Xen (e.g. 4.2 and later) the Xen initscripts should take care of this for you.

For older Xen versions you may need to do this yourself by adding the modules to the relevant configuration file. Under Debian and Ubuntu style systems this is /etc/modules.

The following modules may be required:

   xen-evtchn
   xen-gntdev
   xen-netback
   xen-blkback
   xenfs
   blktap