요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
.. [see the bottom of this file for redistribution information]
===========================================
How to quickly build a trimmed Linux kernel
===========================================
This guide explains how to swiftly build Linux kernels that are ideal for
testing purposes, but perfectly fine for day-to-day use, too.
The essence of the process (aka 'TL;DR')
========================================
*[If you are new to compiling Linux, ignore this TLDR and head over to the next
section below: it contains a step-by-step guide, which is more detailed, but
still brief and easy to follow; that guide and its accompanying reference
section also mention alternatives, pitfalls, and additional aspects, all of
which might be relevant for you.]*
If your system uses techniques like Secure Boot, prepare it to permit starting
self-compiled Linux kernels; install compilers and everything else needed for
building Linux; make sure to have 12 Gigabyte free space in your home directory.
Now run the following commands to download fresh Linux mainline sources, which
you then use to configure, build and install your own kernel::
git clone --depth 1 -b master \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/
cd ~/linux/
# Hint: if you want to apply patches, do it at this point. See below for details.
# Hint: it's recommended to tag your build at this point. See below for details.
yes "" | make localmodconfig
# Hint: at this point you might want to adjust the build configuration; you'll
# have to, if you are running Debian. See below for details.
make -j $(nproc --all)
# Note: on many commodity distributions the next command suffices, but on Arch
# Linux, its derivatives, and some others it does not. See below for details.
command -v installkernel && sudo make modules_install install
reboot
If you later want to build a newer mainline snapshot, use these commands::
cd ~/linux/
git fetch --depth 1 origin
# Note: the next command will discard any changes you did to the code:
git checkout --force --detach origin/master
# Reminder: if you want to (re)apply patches, do it at this point.
# Reminder: you might want to add or modify a build tag at this point.
make olddefconfig
make -j $(nproc --all)
# Reminder: the next command on some distributions does not suffice.
command -v installkernel && sudo make modules_install install
reboot
Step-by-step guide
==================
Compiling your own Linux kernel is easy in principle. There are various ways to
do it. Which of them actually work and is the best depends on the circumstances.
This guide describes a way perfectly suited for those who want to quickly
install Linux from sources without being bothered by complicated details; the
goal is to cover everything typically needed on mainstream Linux distributions
running on commodity PC or server hardware.
The described approach is great for testing purposes, for example to try a
proposed fix or to check if a problem was already fixed in the latest codebase.
Nonetheless, kernels built this way are also totally fine for day-to-day use
while at the same time being easy to keep up to date.
The following steps describe the important aspects of the process; a
comprehensive reference section later explains each of them in more detail. It
sometimes also describes alternative approaches, pitfalls, as well as errors
that might occur at a particular point -- and how to then get things rolling
again.
..
Note: if you see this note, you are reading the text's source file. You
might want to switch to a rendered version, as it makes it a lot easier to
quickly look something up in the reference section and afterwards jump back
to where you left off. Find a the latest rendered version here:
https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html
.. _backup_sbs:
* Create a fresh backup and put system repair and restore tools at hand, just
to be prepared for the unlikely case of something going sideways.
[:ref:`details<backup>`]
.. _secureboot_sbs:
* On platforms with 'Secure Boot' or similar techniques, prepare everything to
ensure the system will permit your self-compiled kernel to boot later. The
quickest and easiest way to achieve this on commodity x86 systems is to
disable such techniques in the BIOS setup utility; alternatively, remove
their restrictions through a process initiated by
``mokutil --disable-validation``.
[:ref:`details<secureboot>`]
.. _buildrequires_sbs:
* Install all software required to build a Linux kernel. Often you will need:
'bc', 'binutils' ('ld' et al.), 'bison', 'flex', 'gcc', 'git', 'openssl',
'pahole', 'perl', and the development headers for 'libelf' and 'openssl'. The
reference section shows how to quickly install those on various popular Linux
distributions.
[:ref:`details<buildrequires>`]
.. _diskspace_sbs:
* Ensure to have enough free space for building and installing Linux. For the
latter 150 Megabyte in /lib/ and 100 in /boot/ are a safe bet. For storing
sources and build artifacts 12 Gigabyte in your home directory should
typically suffice. If you have less available, be sure to check the reference
section for the step that explains adjusting your kernels build
configuration: it mentions a trick that reduce the amount of required space
in /home/ to around 4 Gigabyte.
[:ref:`details<diskspace>`]
.. _sources_sbs:
* Retrieve the sources of the Linux version you intend to build; then change
into the directory holding them, as all further commands in this guide are
meant to be executed from there.
*[Note: the following paragraphs describe how to retrieve the sources by
partially cloning the Linux stable git repository. This is called a shallow
clone. The reference section explains two alternatives:* :ref:`packaged
archives<sources_archive>` *and* :ref:`a full git clone<sources_full>` *;
prefer the latter, if downloading a lot of data does not bother you, as that
will avoid some* :ref:`peculiar characteristics of shallow clones the
reference section explains<sources_shallow>` *.]*
First, execute the following command to retrieve a fresh mainline codebase::
git clone --no-checkout --depth 1 -b master \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/
cd ~/linux/
If you want to access recent mainline releases and pre-releases, deepen you
clone's history to the oldest mainline version you are interested in::
git fetch --shallow-exclude=v6.0 origin
In case you want to access a stable/longterm release (say v6.1.5), simply add
the branch holding that series; afterwards fetch the history at least up to
the mainline version that started the series (v6.1)::
git remote set-branches --add origin linux-6.1.y
git fetch --shallow-exclude=v6.0 origin
Now checkout the code you are interested in. If you just performed the
initial clone, you will be able to check out a fresh mainline codebase, which
is ideal for checking whether developers already fixed an issue::
git checkout --detach origin/master
If you deepened your clone, you instead of ``origin/master`` can specify the
version you deepened to (``v6.0`` above); later releases like ``v6.1`` and
pre-release like ``v6.2-rc1`` will work, too. Stable or longterm versions
like ``v6.1.5`` work just the same, if you added the appropriate
stable/longterm branch as described.
[:ref:`details<sources>`]
.. _patching_sbs:
* In case you want to apply a kernel patch, do so now. Often a command like
this will do the trick::
patch -p1 < ../proposed-fix.patch
If the ``-p1`` is actually needed, depends on how the patch was created; in
case it does not apply thus try without it.
If you cloned the sources with git and anything goes sideways, run ``git
reset --hard`` to undo any changes to the sources.
[:ref:`details<patching>`]
.. _tagging_sbs:
* If you patched your kernel or have one of the same version installed already,
better add a unique tag to the one you are about to build::
echo "-proposed_fix" > localversion
Running ``uname -r`` under your kernel later will then print something like
'6.1-rc4-proposed_fix'.
[:ref:`details<tagging>`]
.. _configuration_sbs:
* Create the build configuration for your kernel based on an existing
configuration.
If you already prepared such a '.config' file yourself, copy it to
~/linux/ and run ``make olddefconfig``.
Use the same command, if your distribution or somebody else already tailored
your running kernel to your or your hardware's needs: the make target
'olddefconfig' will then try to use that kernel's .config as base.
Using this make target is fine for everybody else, too -- but you often can
save a lot of time by using this command instead::
yes "" | make localmodconfig
This will try to pick your distribution's kernel as base, but then disable
modules for any features apparently superfluous for your setup. This will
reduce the compile time enormously, especially if you are running an
universal kernel from a commodity Linux distribution.
There is a catch: 'localmodconfig' is likely to disable kernel features you
did not use since you booted your Linux -- like drivers for currently
disconnected peripherals or a virtualization software not haven't used yet.
You can reduce or nearly eliminate that risk with tricks the reference
section outlines; but when building a kernel just for quick testing purposes
it is often negligible if such features are missing. But you should keep that
aspect in mind when using a kernel built with this make target, as it might
be the reason why something you only use occasionally stopped working.
[:ref:`details<configuration>`]
.. _configmods_sbs:
* Check if you might want to or have to adjust some kernel configuration
options:
* Evaluate how you want to handle debug symbols. Enable them, if you later
might need to decode a stack trace found for example in a 'panic', 'Oops',
'warning', or 'BUG'; on the other hand disable them, if you are short on
storage space or prefer a smaller kernel binary. See the reference section
for details on how to do either. If neither applies, it will likely be fine
to simply not bother with this. [:ref:`details<configmods_debugsymbols>`]
* Are you running Debian? Then to avoid known problems by performing
additional adjustments explained in the reference section.
[:ref:`details<configmods_distros>`].
* If you want to influence the other aspects of the configuration, do so now
by using make targets like 'menuconfig' or 'xconfig'.
[:ref:`details<configmods_individual>`].
.. _build_sbs:
* Build the image and the modules of your kernel::
make -j $(nproc --all)
If you want your kernel packaged up as deb, rpm, or tar file, see the
reference section for alternatives.
[:ref:`details<build>`]
.. _install_sbs:
* Now install your kernel::
command -v installkernel && sudo make modules_install install
Often all left for you to do afterwards is a ``reboot``, as many commodity
Linux distributions will then create an initramfs (also known as initrd) and
an entry for your kernel in your bootloader's configuration; but on some
distributions you have to take care of these two steps manually for reasons
the reference section explains.
On a few distributions like Arch Linux and its derivatives the above command
does nothing at all; in that case you have to manually install your kernel,
as outlined in the reference section.
If you are running an immutable Linux distribution, check its documentation
and the web to find out how to install your own kernel there.
[:ref:`details<install>`]
.. _another_sbs:
* To later build another kernel you need similar steps, but sometimes slightly
different commands.
First, switch back into the sources tree::
cd ~/linux/
In case you want to build a version from a stable/longterm series you have
not used yet (say 6.2.y), tell git to track it::
git remote set-branches --add origin linux-6.2.y
Now fetch the latest upstream changes; you again need to specify the earliest
version you care about, as git otherwise might retrieve the entire commit
history::
git fetch --shallow-exclude=v6.0 origin
Now switch to the version you are interested in -- but be aware the command
used here will discard any modifications you performed, as they would
conflict with the sources you want to checkout::
git checkout --force --detach origin/master
At this point you might want to patch the sources again or set/modify a build
tag, as explained earlier. Afterwards adjust the build configuration to the
new codebase using olddefconfig, which will now adjust the configuration file
you prepared earlier using localmodconfig (~/linux/.config) for your next
kernel::
# reminder: if you want to apply patches, do it at this point
# reminder: you might want to update your build tag at this point
make olddefconfig
Now build your kernel::
make -j $(nproc --all)
Afterwards install the kernel as outlined above::
command -v installkernel && sudo make modules_install install
[:ref:`details<another>`]
.. _uninstall_sbs:
* Your kernel is easy to remove later, as its parts are only stored in two
places and clearly identifiable by the kernel's release name. Just ensure to
not delete the kernel you are running, as that might render your system
unbootable.
Start by deleting the directory holding your kernel's modules, which is named
after its release name -- '6.0.1-foobar' in the following example::
sudo rm -rf /lib/modules/6.0.1-foobar
Now try the following command, which on some distributions will delete all
other kernel files installed while also removing the kernel's entry from the
bootloader configuration::
command -v kernel-install && sudo kernel-install -v remove 6.0.1-foobar
If that command does not output anything or fails, see the reference section;
do the same if any files named '*6.0.1-foobar*' remain in /boot/.
[:ref:`details<uninstall>`]
.. _submit_improvements_qbtl:
Did you run into trouble following any of the above steps that is not cleared up
by the reference section below? Or do you have ideas how to improve the text?
Then please take a moment of your time and let the maintainer of this document
know by email (Thorsten Leemhuis <[email protected]>), ideally while CCing the
Linux docs mailing list ([email protected]). Such feedback is vital to
improve this document further, which is in everybody's interest, as it will
enable more people to master the task described here.
Reference section for the step-by-step guide
============================================
This section holds additional information for each of the steps in the above
guide.
.. _backup:
Prepare for emergencies
-----------------------
*Create a fresh backup and put system repair and restore tools at hand*
[:ref:`... <backup_sbs>`]
Remember, you are dealing with computers, which sometimes do unexpected things
-- especially if you fiddle with crucial parts like the kernel of an operating
system. That's what you are about to do in this process. Hence, better prepare
for something going sideways, even if that should not happen.
[:ref:`back to step-by-step guide <backup_sbs>`]
.. _secureboot:
Dealing with techniques like Secure Boot
----------------------------------------
*On platforms with 'Secure Boot' or similar techniques, prepare everything to
ensure the system will permit your self-compiled kernel to boot later.*
[:ref:`... <secureboot_sbs>`]
Many modern systems allow only certain operating systems to start; they thus by
default will reject booting self-compiled kernels.
You ideally deal with this by making your platform trust your self-built kernels
with the help of a certificate and signing. How to do that is not described
here, as it requires various steps that would take the text too far away from
its purpose; 'Documentation/admin-guide/module-signing.rst' and various web
sides already explain this in more detail.
Temporarily disabling solutions like Secure Boot is another way to make your own
Linux boot. On commodity x86 systems it is possible to do this in the BIOS Setup
utility; the steps to do so are not described here, as they greatly vary between
machines.
On mainstream x86 Linux distributions there is a third and universal option:
disable all Secure Boot restrictions for your Linux environment. You can
initiate this process by running ``mokutil --disable-validation``; this will
tell you to create a one-time password, which is safe to write down. Now
restart; right after your BIOS performed all self-tests the bootloader Shim will
show a blue box with a message 'Press any key to perform MOK management'. Hit
some key before the countdown exposes. This will open a menu and choose 'Change
Secure Boot state' there. Shim's 'MokManager' will now ask you to enter three
randomly chosen characters from the one-time password specified earlier. Once
you provided them, confirm that you really want to disable the validation.
Afterwards, permit MokManager to reboot the machine.
[:ref:`back to step-by-step guide <secureboot_sbs>`]
.. _buildrequires:
Install build requirements
--------------------------
*Install all software required to build a Linux kernel.*
[:ref:`...<buildrequires_sbs>`]
The kernel is pretty stand-alone, but besides tools like the compiler you will
sometimes need a few libraries to build one. How to install everything needed
depends on your Linux distribution and the configuration of the kernel you are
about to build.
Here are a few examples what you typically need on some mainstream
distributions:
* Debian, Ubuntu, and derivatives::
sudo apt install bc binutils bison dwarves flex gcc git make openssl \
pahole perl-base libssl-dev libelf-dev
* Fedora and derivatives::
sudo dnf install binutils /usr/include/{libelf.h,openssl/pkcs7.h} \
/usr/bin/{bc,bison,flex,gcc,git,openssl,make,perl,pahole}
* openSUSE and derivatives::
sudo zypper install bc binutils bison dwarves flex gcc git make perl-base \
openssl openssl-devel libelf-dev
In case you wonder why these lists include openssl and its development headers:
they are needed for the Secure Boot support, which many distributions enable in
their kernel configuration for x86 machines.
Sometimes you will need tools for compression formats like bzip2, gzip, lz4,
lzma, lzo, xz, or zstd as well.
You might need additional libraries and their development headers in case you
perform tasks not covered in this guide. For example, zlib will be needed when
building kernel tools from the tools/ directory; adjusting the build
configuration with make targets like 'menuconfig' or 'xconfig' will require
development headers for ncurses or Qt5.
[:ref:`back to step-by-step guide <buildrequires_sbs>`]
.. _diskspace:
Space requirements
------------------
*Ensure to have enough free space for building and installing Linux.*
[:ref:`... <diskspace_sbs>`]
The numbers mentioned are rough estimates with a big extra charge to be on the
safe side, so often you will need less.
If you have space constraints, remember to read the reference section when you
reach the :ref:`section about configuration adjustments' <configmods>`, as
ensuring debug symbols are disabled will reduce the consumed disk space by quite
a few gigabytes.
[:ref:`back to step-by-step guide <diskspace_sbs>`]
.. _sources:
Download the sources
--------------------
*Retrieve the sources of the Linux version you intend to build.*
[:ref:`...<sources_sbs>`]
The step-by-step guide outlines how to retrieve Linux' sources using a shallow
git clone. There is :ref:`more to tell about this method<sources_shallow>` and
two alternate ways worth describing: :ref:`packaged archives<sources_archive>`
and :ref:`a full git clone<sources_full>`. And the aspects ':ref:`wouldn't it
be wiser to use a proper pre-release than the latest mainline code
<sources_snapshot>`' and ':ref:`how to get an even fresher mainline codebase
<sources_fresher>`' need elaboration, too.
Note, to keep things simple the commands used in this guide store the build
artifacts in the source tree. If you prefer to separate them, simply add
something like ``O=~/linux-builddir/`` to all make calls; also adjust the path
in all commands that add files or modify any generated (like your '.config').
[:ref:`back to step-by-step guide <sources_sbs>`]
.. _sources_shallow:
Noteworthy characteristics of shallow clones
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The step-by-step guide uses a shallow clone, as it is the best solution for most
of this document's target audience. There are a few aspects of this approach
worth mentioning:
* This document in most places uses ``git fetch`` with ``--shallow-exclude=``
to specify the earliest version you care about (or to be precise: its git
tag). You alternatively can use the parameter ``--shallow-since=`` to specify
an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to
define the depth of the history you want to download. As a second
alternative, you can also specify a certain depth explicitly with a parameter
like ``--depth=1``, unless you add branches for stable/longterm kernels.
* When running ``git fetch``, remember to always specify the oldest version,
the time you care about, or an explicit depth as shown in the step-by-step
guide. Otherwise you will risk downloading nearly the entire git history,
which will consume quite a bit of time and bandwidth while also stressing the
servers.
Note, you do not have to use the same version or date all the time. But when
you change it over time, git will deepen or flatten the history to the
specified point. That allows you to retrieve versions you initially thought
you did not need -- or it will discard the sources of older versions, for
example in case you want to free up some disk space. The latter will happen
automatically when using ``--shallow-since=`` or
``--depth=``.
* Be warned, when deepening your clone you might encounter an error like
'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'.
In that case run ``git repack -d`` and try again``
* In case you want to revert changes from a certain version (say Linux 6.3) or
perform a bisection (v6.2..v6.3), better tell ``git fetch`` to retrieve
objects up to three versions earlier (e.g. 6.0): ``git describe`` will then
be able to describe most commits just like it would in a full git clone.
[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
.. _sources_archive:
Downloading the sources using a packages archive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
People new to compiling Linux often assume downloading an archive via the
front-page of https://kernel.org is the best approach to retrieve Linux'
sources. It actually can be, if you are certain to build just one particular
kernel version without changing any code. Thing is: you might be sure this will
be the case, but in practice it often will turn out to be a wrong assumption.
That's because when reporting or debugging an issue developers will often ask to
give another version a try. They also might suggest temporarily undoing a commit
with ``git revert`` or might provide various patches to try. Sometimes reporters
will also be asked to use ``git bisect`` to find the change causing a problem.
These things rely on git or are a lot easier and quicker to handle with it.
A shallow clone also does not add any significant overhead. For example, when
you use ``git clone --depth=1`` to create a shallow clone of the latest mainline
codebase git will only retrieve a little more data than downloading the latest
mainline pre-release (aka 'rc') via the front-page of kernel.org would.
A shallow clone therefore is often the better choice. If you nevertheless want
to use a packaged source archive, download one via kernel.org; afterwards
extract its content to some directory and change to the subdirectory created
during extraction. The rest of the step-by-step guide will work just fine, apart
from things that rely on git -- but this mainly concerns the section on
successive builds of other versions.
[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
.. _sources_full:
Downloading the sources using a full git clone
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If downloading and storing a lot of data (~4,4 Gigabyte as of early 2023) is
nothing that bothers you, instead of a shallow clone perform a full git clone
instead. You then will avoid the specialties mentioned above and will have all
versions and individual commits at hand at any time::
curl -L \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle \
-o linux-stable.git.bundle
git clone linux-stable.git.bundle ~/linux/
rm linux-stable.git.bundle
cd ~/linux/
git remote set-url origin \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
git fetch origin
git checkout --detach origin/master
[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
.. _sources_snapshot:
Proper pre-releases (RCs) vs. latest mainline
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When cloning the sources using git and checking out origin/master, you often
will retrieve a codebase that is somewhere between the latest and the next
release or pre-release. This almost always is the code you want when giving
mainline a shot: pre-releases like v6.1-rc5 are in no way special, as they do
not get any significant extra testing before being published.
There is one exception: you might want to stick to the latest mainline release
(say v6.1) before its successor's first pre-release (v6.2-rc1) is out. That is
because compiler errors and other problems are more likely to occur during this
time, as mainline then is in its 'merge window': a usually two week long phase,
in which the bulk of the changes for the next release is merged.
[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
.. _sources_fresher:
Avoiding the mainline lag
~~~~~~~~~~~~~~~~~~~~~~~~~
The explanations for both the shallow clone and the full clone both retrieve the
code from the Linux stable git repository. That makes things simpler for this
document's audience, as it allows easy access to both mainline and
stable/longterm releases. This approach has just one downside:
Changes merged into the mainline repository are only synced to the master branch
of the Linux stable repository every few hours. This lag most of the time is
not something to worry about; but in case you really need the latest code, just
add the mainline repo as additional remote and checkout the code from there::
git remote add mainline \
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch mainline
git checkout --detach mainline/master
When doing this with a shallow clone, remember to call ``git fetch`` with one
of the parameters described earlier to limit the depth.
[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
.. _patching:
Patch the sources (optional)
----------------------------
*In case you want to apply a kernel patch, do so now.*
[:ref:`...<patching_sbs>`]
This is the point where you might want to patch your kernel -- for example when
a developer proposed a fix and asked you to check if it helps. The step-by-step
guide already explains everything crucial here.
[:ref:`back to step-by-step guide <patching_sbs>`]
.. _tagging:
Tagging this kernel build (optional, often wise)
------------------------------------------------
*If you patched your kernel or already have that kernel version installed,
better tag your kernel by extending its release name:*
[:ref:`...<tagging_sbs>`]
Tagging your kernel will help avoid confusion later, especially when you patched
your kernel. Adding an individual tag will also ensure the kernel's image and
its modules are installed in parallel to any existing kernels.
There are various ways to add such a tag. The step-by-step guide realizes one by
creating a 'localversion' file in your build directory from which the kernel
build scripts will automatically pick up the tag. You can later change that file
to use a different tag in subsequent builds or simply remove that file to dump
the tag.
[:ref:`back to step-by-step guide <tagging_sbs>`]
.. _configuration:
Define the build configuration for your kernel
----------------------------------------------
*Create the build configuration for your kernel based on an existing
configuration.* [:ref:`... <configuration_sbs>`]
There are various aspects for this steps that require a more careful
explanation:
Pitfalls when using another configuration file as base
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Make targets like localmodconfig and olddefconfig share a few common snares you
want to be aware of:
* These targets will reuse a kernel build configuration in your build directory
(e.g. '~/linux/.config'), if one exists. In case you want to start from
scratch you thus need to delete it.
* The make targets try to find the configuration for your running kernel
automatically, but might choose poorly. A line like '# using defaults found
in /boot/config-6.0.7-250.fc36.x86_64' or 'using config:
'/boot/config-6.0.7-250.fc36.x86_64' tells you which file they picked. If
that is not the intended one, simply store it as '~/linux/.config'
before using these make targets.
* Unexpected things might happen if you try to use a config file prepared for
one kernel (say v6.0) on an older generation (say v5.15). In that case you
might want to use a configuration as base which your distribution utilized
when they used that or an slightly older kernel version.
Influencing the configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The make target olddefconfig and the ``yes "" |`` used when utilizing
localmodconfig will set any undefined build options to their default value. This
among others will disable many kernel features that were introduced after your
base kernel was released.
If you want to set these configurations options manually, use ``oldconfig``
instead of ``olddefconfig`` or omit the ``yes "" |`` when utilizing
localmodconfig. Then for each undefined configuration option you will be asked
how to proceed. In case you are unsure what to answer, simply hit 'enter' to
apply the default value.
Big pitfall when using localmodconfig
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As explained briefly in the step-by-step guide already: with localmodconfig it
can easily happen that your self-built kernel will lack modules for tasks you
did not perform before utilizing this make target. That's because those tasks
require kernel modules that are normally autoloaded when you perform that task
for the first time; if you didn't perform that task at least once before using
localmodconfig, the latter will thus assume these modules are superfluous and
disable them.
You can try to avoid this by performing typical tasks that often will autoload
additional kernel modules: start a VM, establish VPN connections, loop-mount a
CD/DVD ISO, mount network shares (CIFS, NFS, ...), and connect all external
devices (2FA keys, headsets, webcams, ...) as well as storage devices with file
systems you otherwise do not utilize (btrfs, ext4, FAT, NTFS, XFS, ...). But it
is hard to think of everything that might be needed -- even kernel developers
often forget one thing or another at this point.
Do not let that risk bother you, especially when compiling a kernel only for
testing purposes: everything typically crucial will be there. And if you forget
something important you can turn on a missing feature later and quickly run the
commands to compile and install a better kernel.
But if you plan to build and use self-built kernels regularly, you might want to
reduce the risk by recording which modules your system loads over the course of
a few weeks. You can automate this with `modprobed-db
<https://github.com/graysky2/modprobed-db>`_. Afterwards use ``LSMOD=<path>`` to
point localmodconfig to the list of modules modprobed-db noticed being used::
yes "" | make LSMOD="${HOME}"/.config/modprobed.db localmodconfig
Remote building with localmodconfig
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you want to use localmodconfig to build a kernel for another machine, run
``lsmod > lsmod_foo-machine`` on it and transfer that file to your build host.
Now point the build scripts to the file like this: ``yes "" | make
LSMOD=~/lsmod_foo-machine localmodconfig``. Note, in this case
you likely want to copy a base kernel configuration from the other machine over
as well and place it as .config in your build directory.
[:ref:`back to step-by-step guide <configuration_sbs>`]
.. _configmods:
Adjust build configuration
--------------------------
*Check if you might want to or have to adjust some kernel configuration
options:*
Depending on your needs you at this point might want or have to adjust some
kernel configuration options.
.. _configmods_debugsymbols:
Debug symbols
~~~~~~~~~~~~~
*Evaluate how you want to handle debug symbols.*
[:ref:`...<configmods_sbs>`]
Most users do not need to care about this, it's often fine to leave everything
as it is; but you should take a closer look at this, if you might need to decode
a stack trace or want to reduce space consumption.
Having debug symbols available can be important when your kernel throws a
'panic', 'Oops', 'warning', or 'BUG' later when running, as then you will be
able to find the exact place where the problem occurred in the code. But
collecting and embedding the needed debug information takes time and consumes
quite a bit of space: in late 2022 the build artifacts for a typical x86 kernel
configured with localmodconfig consumed around 5 Gigabyte of space with debug
symbols, but less than 1 when they were disabled. The resulting kernel image and
the modules are bigger as well, which increases load times.
Hence, if you want a small kernel and are unlikely to decode a stack trace
later, you might want to disable debug symbols to avoid above downsides::
./scripts/config --file .config -d DEBUG_INFO \
-d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -d DEBUG_INFO_DWARF4 \
-d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE
make olddefconfig
You on the other hand definitely want to enable them, if there is a decent
chance that you need to decode a stack trace later (as explained by 'Decode
failure messages' in Documentation/admin-guide/tainted-kernels.rst in more
detail)::
./scripts/config --file .config -d DEBUG_INFO_NONE -e DEBUG_KERNEL
-e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS -e KALLSYMS_ALL
make olddefconfig
Note, many mainstream distributions enable debug symbols in their kernel
configurations -- make targets like localmodconfig and olddefconfig thus will
often pick that setting up.
[:ref:`back to step-by-step guide <configmods_sbs>`]
.. _configmods_distros:
Distro specific adjustments
~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Are you running* [:ref:`... <configmods_sbs>`]
The following sections help you to avoid build problems that are known to occur
when following this guide on a few commodity distributions.
**Debian:**
* Remove a stale reference to a certificate file that would cause your build to
fail::
./scripts/config --file .config --set-str SYSTEM_TRUSTED_KEYS ''
Alternatively, download the needed certificate and make that configuration
option point to it, as `the Debian handbook explains in more detail
<https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
-- or generate your own, as explained in
Documentation/admin-guide/module-signing.rst.
[:ref:`back to step-by-step guide <configmods_sbs>`]
.. _configmods_individual:
Individual adjustments
~~~~~~~~~~~~~~~~~~~~~~
*If you want to influence the other aspects of the configuration, do so
now* [:ref:`... <configmods_sbs>`]
You at this point can use a command like ``make menuconfig`` to enable or
disable certain features using a text-based user interface; to use a graphical
configuration utilize, use the make target ``xconfig`` or ``gconfig`` instead.
All of them require development libraries from toolkits they are based on
(ncurses, Qt5, Gtk2); an error message will tell you if something required is
missing.
[:ref:`back to step-by-step guide <configmods_sbs>`]
.. _build:
Build your kernel
-----------------
*Build the image and the modules of your kernel* [:ref:`... <build_sbs>`]
A lot can go wrong at this stage, but the instructions below will help you help
yourself. Another subsection explains how to directly package your kernel up as
deb, rpm or tar file.
Dealing with build errors
~~~~~~~~~~~~~~~~~~~~~~~~~
When a build error occurs, it might be caused by some aspect of your machine's
setup that often can be fixed quickly; other times though the problem lies in
the code and can only be fixed by a developer. A close examination of the
failure messages coupled with some research on the internet will often tell you
which of the two it is. To perform such an investigation, restart the build
process like this::
make V=1
The ``V=1`` activates verbose output, which might be needed to see the actual
error. To make it easier to spot, this command also omits the ``-j $(nproc
--all)`` used earlier to utilize every CPU core in the system for the job -- but
this parallelism also results in some clutter when failures occur.
After a few seconds the build process should run into the error again. Now try
to find the most crucial line describing the problem. Then search the internet
for the most important and non-generic section of that line (say 4 to 8 words);
avoid or remove anything that looks remotely system-specific, like your username
or local path names like ``/home/username/linux/``. First try your regular
internet search engine with that string, afterwards search Linux kernel mailing
lists via `lore.kernel.org/all/ <https://lore.kernel.org/all/>`_.
This most of the time will find something that will explain what is wrong; quite
often one of the hits will provide a solution for your problem, too. If you
do not find anything that matches your problem, try again from a different angle
by modifying your search terms or using another line from the error messages.
In the end, most trouble you are to run into has likely been encountered and
reported by others already. That includes issues where the cause is not your
system, but lies the code. If you run into one of those, you might thus find a
solution (e.g. a patch) or workaround for your problem, too.
Package your kernel up
~~~~~~~~~~~~~~~~~~~~~~
The step-by-step guide uses the default make targets (e.g. 'bzImage' and
'modules' on x86) to build the image and the modules of your kernel, which later
steps of the guide then install. You instead can also directly build everything
and directly package it up by using one of the following targets:
* ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package
* ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package
* ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball
This is just a selection of available make targets for this purpose, see
``make help`` for others. You can also use these targets after running
``make -j $(nproc --all)``, as they will pick up everything already built.
If you employ the targets to generate deb or rpm packages, ignore the
step-by-step guide's instructions on installing and removing your kernel;
instead install and remove the packages using the package utility for the format
(e.g. dpkg and rpm) or a package management utility build on top of them (apt,
aptitude, dnf/yum, zypper, ...). Be aware that the packages generated using
these two make targets are designed to work on various distributions utilizing
those formats, they thus will sometimes behave differently than your
distribution's kernel packages.
[:ref:`back to step-by-step guide <build_sbs>`]
.. _install:
Install your kernel
-------------------
*Now install your kernel* [:ref:`... <install_sbs>`]
What you need to do after executing the command in the step-by-step guide
depends on the existence and the implementation of an ``installkernel``
executable. Many commodity Linux distributions ship such a kernel installer in
``/sbin/`` that does everything needed, hence there is nothing left for you
except rebooting. But some distributions contain an installkernel that does
only part of the job -- and a few lack it completely and leave all the work to
you.
If ``installkernel`` is found, the kernel's build system will delegate the
actual installation of your kernel's image and related files to this executable.
On almost all Linux distributions it will store the image as '/boot/vmlinuz-
<your kernel's release name>' and put a 'System.map-<your kernel's release
name>' alongside it. Your kernel will thus be installed in parallel to any
existing ones, unless you already have one with exactly the same release name.
Installkernel on many distributions will afterwards generate an 'initramfs'
(often also called 'initrd'), which commodity distributions rely on for booting;
hence be sure to keep the order of the two make targets used in the step-by-step
guide, as things will go sideways if you install your kernel's image before its
modules. Often installkernel will then add your kernel to the bootloader
configuration, too. You have to take care of one or both of these tasks
yourself, if your distributions installkernel doesn't handle them.
A few distributions like Arch Linux and its derivatives totally lack an
installkernel executable. On those just install the modules using the kernel's
build system and then install the image and the System.map file manually::
sudo make modules_install
sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease)
sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease)
If your distribution boots with the help of an initramfs, now generate one for
your kernel using the tools your distribution provides for this process.
Afterwards add your kernel to your bootloader configuration and reboot.
[:ref:`back to step-by-step guide <install_sbs>`]
.. _another:
Another round later
-------------------
*To later build another kernel you need similar, but sometimes slightly
different commands* [:ref:`... <another_sbs>`]
The process to build later kernels is similar, but at some points slightly
different. You for example do not want to use 'localmodconfig' for succeeding
kernel builds, as you already created a trimmed down configuration you want to
use from now on. Hence instead just use ``oldconfig`` or ``olddefconfig`` to
adjust your build configurations to the needs of the kernel version you are
about to build.
If you created a shallow-clone with git, remember what the :ref:`section that
explained the setup described in more detail <sources>`: you need to use a
slightly different ``git fetch`` command and when switching to another series
need to add an additional remote branch.
[:ref:`back to step-by-step guide <another_sbs>`]
.. _uninstall:
Uninstall the kernel later
--------------------------
*All parts of your installed kernel are identifiable by its release name and
thus easy to remove later.* [:ref:`... <uninstall_sbs>`]
Do not worry installing your kernel manually and thus bypassing your
distribution's packaging system will totally mess up your machine: all parts of
your kernel are easy to remove later, as files are stored in two places only and
normally identifiable by the kernel's release name.
One of the two places is a directory in /lib/modules/, which holds the modules
for each installed kernel. This directory is named after the kernel's release
name; hence, to remove all modules for one of your kernels, simply remove its
modules directory in /lib/modules/.
The other place is /boot/, where typically one to five files will be placed
during installation of a kernel. All of them usually contain the release name in
their file name, but how many files and their name depends somewhat on your
distribution's installkernel executable (:ref:`see above <install>`) and its
initramfs generator. On some distributions the ``kernel-install`` command
mentioned in the step-by-step guide will remove all of these files for you --
and the entry for your kernel in the bootloader configuration at the same time,
too. On others you have to take care of these steps yourself. The following
command should interactively remove the two main files of a kernel with the
release name '6.0.1-foobar'::
rm -i /boot/{System.map,vmlinuz}-6.0.1-foobar
Now remove the belonging initramfs, which often will be called something like
``/boot/initramfs-6.0.1-foobar.img`` or ``/boot/initrd.img-6.0.1-foobar``.
Afterwards check for other files in /boot/ that have '6.0.1-foobar' in their
name and delete them as well. Now remove the kernel from your bootloader's
configuration.
Note, be very careful with wildcards like '*' when deleting files or directories
for kernels manually: you might accidentally remove files of a 6.0.11 kernel
when all you want is to remove 6.0 or 6.0.1.
[:ref:`back to step-by-step guide <uninstall_sbs>`]
.. _faq:
FAQ
===
Why does this 'how-to' not work on my system?
---------------------------------------------
As initially stated, this guide is 'designed to cover everything typically
needed [to build a kernel] on mainstream Linux distributions running on
commodity PC or server hardware'. The outlined approach despite this should work
on many other setups as well. But trying to cover every possible use-case in one
guide would defeat its purpose, as without such a focus you would need dozens or
hundreds of constructs along the lines of 'in case you are having <insert
machine or distro>, you at this point have to do <this and that>
<instead|additionally>'. Each of which would make the text longer, more
complicated, and harder to follow.
That being said: this of course is a balancing act. Hence, if you think an
additional use-case is worth describing, suggest it to the maintainers of this
document, as :ref:`described above <submit_improvements_qbtl>`.
..
end-of-content
..
This document is maintained by Thorsten Leemhuis <[email protected]>. If
you spot a typo or small mistake, feel free to let him know directly and
he'll fix it. You are free to do the same in a mostly informal way if you
want to contribute changes to the text -- but for copyright reasons please CC
[email protected] and 'sign-off' your contribution as
Documentation/process/submitting-patches.rst explains in the section 'Sign
your work - the Developer's Certificate of Origin'.
..
This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
of the file. If you want to distribute this text under CC-BY-4.0 only,
please use 'The Linux kernel development community' for author attribution
and link this as source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/quickly-build-trimmed-linux.rst
..
Note: Only the content of this RST file as found in the Linux kernel sources
is available under CC-BY-4.0, as versions of this text that were processed
(for example by the kernel's build system) might contain content taken from
files which use a more restrictive license.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
문서 개요와 빠른 절차
1-53이 문서는 `(GPL-2.0+ OR CC-BY-4.0)` 이중 조건으로 배포되며, 재배포에 관한 자세한 정보는 파일 끝에 있습니다. 제목은 '잘라낸 Linux kernel을 빠르게 build하는 방법'입니다.
이 guide는 test에 이상적이면서 일상적으로 사용해도 충분한 Linux kernel을 신속하게 build하는 방법을 설명합니다.
다음은 과정의 핵심, 즉 TL;DR입니다. Linux compile이 처음이라면 이 요약을 건너뛰고 다음의 단계별 guide를 읽으십시오. 그 guide는 더 자세하지만 여전히 짧고 따라 하기 쉬우며, 함께 제공되는 reference section은 관련 대안, 함정, 추가 고려 사항도 설명합니다.
System이 Secure Boot 같은 기술을 사용한다면 직접 compile한 Linux kernel을 시작할 수 있도록 준비합니다. Compiler와 build에 필요한 나머지 도구를 설치하고 home directory에 12GB의 여유 공간을 확보한 다음, 아래 명령으로 최신 Linux mainline source를 받아 설정하고 build하여 설치합니다.
git clone --depth 1 -b master \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/
cd ~/linux/
# Hint: if you want to apply patches, do it at this point. See below for details.
# Hint: it's recommended to tag your build at this point. See below for details.
yes "" | make localmodconfig
# Hint: at this point you might want to adjust the build configuration; you'll
# have to, if you are running Debian. See below for details.
make -j $(nproc --all)
# Note: on many commodity distributions the next command suffices, but on Arch
# Linux, its derivatives, and some others it does not. See below for details.
command -v installkernel && sudo make modules_install install
reboot나중에 더 새로운 mainline snapshot을 build하려면 아래 명령을 사용합니다. `git checkout --force`는 source에 가한 변경을 버리므로 patch를 다시 적용하고 build tag도 다시 확인해야 합니다.
cd ~/linux/
git fetch --depth 1 origin
# Note: the next command will discard any changes you did to the code:
git checkout --force --detach origin/master
# Reminder: if you want to (re)apply patches, do it at this point.
# Reminder: you might want to add or modify a build tag at this point.
make olddefconfig
make -j $(nproc --all)
# Reminder: the next command on some distributions does not suffice.
command -v installkernel && sudo make modules_install install
reboot단계별 guide와 사전 준비
54-122직접 Linux kernel을 compile하는 일은 원칙적으로 쉽지만 방법이 여러 가지이고, 실제로 동작하는 최선의 방법은 상황에 따라 달라집니다. 이 guide는 복잡한 세부 사항에 방해받지 않고 source에서 Linux를 빠르게 설치하려는 사람을 위해, 범용 PC나 server hardware에서 주류 Linux distribution을 쓸 때 보통 필요한 모든 것을 다루는 방법을 제시합니다.
이 방법은 제안된 수정의 효과를 시험하거나 문제가 최신 codebase에서 이미 고쳐졌는지 확인하는 데 특히 적합합니다. 동시에 이 방식으로 만든 kernel은 일상 사용에도 충분하고 최신 상태로 유지하기도 쉽습니다.
이하의 단계는 중요한 부분만 설명하고, 뒤의 reference section이 각 항목의 대안, 함정, 발생 가능한 오류와 복구 방법을 자세히 보충합니다. RST source를 직접 보고 있다면 `https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html`의 최신 rendering을 이용하는 편이 reference를 오가기에 쉽습니다.
예상 밖의 문제가 생길 가능성에 대비해 새 backup을 만들고 system 복구 및 복원 도구를 준비합니다.
Secure Boot 또는 비슷한 기술을 쓰는 platform에서는 직접 compile한 kernel의 boot를 허용하도록 준비합니다. 범용 x86 system에서는 BIOS 설정에서 해당 기능을 끄는 방법이 가장 빠르고 쉽습니다. 또는 `mokutil --disable-validation`로 시작하는 절차를 통해 제한을 제거할 수 있습니다.
Kernel build에 필요한 software를 모두 설치합니다. 대체로 `bc`, `binutils`의 `ld` 등, `bison`, `flex`, `gcc`, `git`, `openssl`, `pahole`, `perl`, 그리고 `libelf`와 `openssl`의 development header가 필요합니다. 배포판별 빠른 설치 방법은 reference section에 있습니다.
Build와 설치 공간도 확보합니다. 설치에는 `/lib/` 150MB와 `/boot/` 100MB면 넉넉하고, source와 build artifact에는 home directory 12GB가 보통 충분합니다. 여유가 부족하면 설정 조정 절에서 debug symbol을 끄는 방법을 확인하십시오. 그러면 `/home/` 사용량을 약 4GB까지 줄일 수 있습니다.
Source 취득, patch, build tag
123-194Build할 Linux version의 source를 받은 뒤 그 directory로 이동합니다. 이후의 모든 명령은 그 위치에서 실행한다고 가정합니다. 여기서는 Linux stable git repository를 일부만 받는 shallow clone을 사용하지만, reference section은 packaged archive와 full git clone도 설명합니다. 많은 data를 내려받아도 괜찮다면 shallow clone의 특이점을 피할 수 있는 full clone을 선호할 수 있습니다.
먼저 다음 명령으로 최신 mainline codebase를 받습니다.
git clone --no-checkout --depth 1 -b master \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/
cd ~/linux/최근 mainline release와 pre-release에도 접근하려면 관심 있는 가장 오래된 mainline version까지 clone history를 깊게 만듭니다.
git fetch --shallow-exclude=v6.0 originStable 또는 longterm release, 예를 들어 v6.1.5가 필요하면 해당 series branch를 추가하고 그 series가 시작된 mainline version인 v6.1보다 앞까지 history를 가져옵니다.
git remote set-branches --add origin linux-6.1.y
git fetch --shallow-exclude=v6.0 origin이제 원하는 code를 checkout합니다. 최초 clone 직후에는 developer가 문제를 이미 해결했는지 확인하기에 알맞은 최신 mainline을 선택할 수 있습니다.
git checkout --detach origin/masterClone을 깊게 했다면 `origin/master` 대신 앞서 지정한 `v6.0`, 이후 release인 `v6.1`, pre-release인 `v6.2-rc1` 등을 지정할 수 있습니다. 해당 stable/longterm branch를 추가했다면 `v6.1.5` 같은 version도 같은 방식으로 선택합니다.
Kernel patch를 적용하려면 지금 처리합니다. 보통 다음 명령으로 충분합니다.
patch -p1 < ../proposed-fix.patch`-p1`의 필요 여부는 patch 생성 방식에 달려 있으므로 적용되지 않으면 옵션 없이 시도합니다. Git clone을 사용했고 source 변경이 잘못되었다면 `git reset --hard`로 모든 변경을 되돌립니다.
Kernel을 patch했거나 같은 version이 이미 설치되어 있다면 build에 고유 tag를 붙이는 편이 좋습니다.
echo "-proposed_fix" > localversion이 kernel에서 `uname -r`을 실행하면 `6.1-rc4-proposed_fix`와 같은 release name이 표시됩니다.
설정, build, 설치
195-279기존 설정을 바탕으로 kernel build configuration을 만듭니다. 직접 준비한 `.config`가 있다면 `~/linux/`에 복사하고 `make olddefconfig`를 실행합니다. Distribution이나 다른 관리자가 현재 kernel을 사용자와 hardware에 맞게 조정했다면 같은 명령이 실행 중인 kernel의 `.config`를 base로 찾으려 합니다.
`olddefconfig`는 누구나 쓸 수 있지만, 범용 distribution kernel을 쓴다면 다음 명령으로 compile 시간을 크게 줄일 수 있습니다.
yes "" | make localmodconfig`localmodconfig`는 distribution kernel 설정을 base로 삼되 현재 환경에 불필요해 보이는 기능의 module을 끕니다. 다만 boot 후 사용하지 않은 기능도 끌 수 있습니다. 현재 분리된 주변 장치의 driver나 아직 실행하지 않은 virtualization software가 그 예입니다. Reference의 요령으로 위험을 줄일 수 있고 단기 test kernel에서는 대체로 감수할 만하지만, 가끔 쓰는 기능이 멈췄다면 이 설정을 의심해야 합니다.
이제 kernel configuration의 추가 조정이 필요한지 확인합니다. Panic, Oops, warning, BUG의 stack trace를 나중에 해석해야 한다면 debug symbol을 켜고, 저장 공간이나 작은 kernel binary가 더 중요하면 끕니다. 어느 쪽도 아니라면 기존 설정을 유지해도 대체로 괜찮습니다.
Debian을 사용한다면 알려진 build 문제를 피하기 위한 추가 조정을 적용합니다. 그 밖의 설정을 직접 바꾸려면 `menuconfig` 또는 `xconfig` 같은 make target을 사용합니다.
다음 명령으로 kernel image와 module을 build합니다.
make -j $(nproc --all)Deb, rpm, tar file로 package하려면 reference section에 설명한 다른 make target을 사용할 수 있습니다.
이제 kernel을 설치합니다.
command -v installkernel && sudo make modules_install install많은 범용 distribution은 이 명령 뒤 initramfs, 즉 initrd와 bootloader entry를 자동으로 만들므로 보통 `reboot`만 하면 됩니다. 일부 distribution에서는 두 작업을 직접 해야 합니다. Arch Linux와 그 파생판처럼 위 명령이 아무것도 하지 않는 경우에는 reference에 따라 수동 설치합니다. Immutable Linux distribution이라면 자체 문서와 web 자료에서 custom kernel 설치법을 확인합니다.
후속 build, 제거, feedback
280-359나중에 다른 kernel을 build할 때도 과정은 비슷하지만 일부 명령이 달라집니다. 먼저 source tree로 돌아갑니다.
cd ~/linux/아직 사용하지 않은 stable/longterm series, 예를 들어 6.2.y를 build하려면 git이 그 branch를 추적하도록 추가합니다.
git remote set-branches --add origin linux-6.2.y그다음 최신 upstream 변경을 가져옵니다. 관심 있는 가장 오래된 version을 다시 지정하지 않으면 git이 전체 commit history에 가까운 양을 내려받을 수 있습니다.
git fetch --shallow-exclude=v6.0 origin원하는 version으로 전환합니다. 다음 명령은 checkout할 source와 충돌할 수 있는 기존 변경을 모두 버립니다.
git checkout --force --detach origin/master필요하면 patch와 build tag를 다시 적용합니다. 이어서 앞서 `localmodconfig`로 만든 `~/linux/.config`를 새 codebase에 맞게 `olddefconfig`로 조정합니다.
# reminder: if you want to apply patches, do it at this point
# reminder: you might want to update your build tag at this point
make olddefconfigKernel을 build하고 앞에서 설명한 방식으로 설치합니다.
make -j $(nproc --all)command -v installkernel && sudo make modules_install install직접 설치한 kernel은 구성 요소가 두 위치에 있고 release name으로 분명히 구별되므로 제거하기 쉽습니다. 현재 실행 중인 kernel을 지우면 system이 boot되지 않을 수 있으므로 반드시 다른 kernel로 boot한 상태에서 작업합니다.
예제 release name `6.0.1-foobar`의 module directory를 먼저 지웁니다.
sudo rm -rf /lib/modules/6.0.1-foobar일부 distribution에서는 다음 명령이 나머지 kernel file과 bootloader entry까지 제거합니다.
command -v kernel-install && sudo kernel-install -v remove 6.0.1-foobar명령이 아무것도 출력하지 않거나 실패하거나 `/boot/`에 `*6.0.1-foobar*` file이 남으면 reference section의 수동 제거 절차를 따릅니다.
위 단계에서 해결되지 않은 문제를 겪었거나 개선 아이디어가 있다면 문서 maintainer Thorsten Leemhuis `<[email protected]>`에게 email을 보내고 가능하면 Linux docs mailing list `[email protected]`를 CC하십시오. 이런 feedback은 더 많은 사람이 이 작업을 익히도록 문서를 개선하는 데 중요합니다.
Reference: 비상 대비와 Secure Boot
360-417이 reference section은 앞의 단계별 guide 각 항목에 추가 정보를 제공합니다.
Kernel처럼 운영체제의 핵심 부분을 다룰 때 computer가 예상 밖으로 동작할 수 있습니다. 실제로 문제가 생길 가능성은 낮아도 새 backup과 system 복구·복원 도구를 준비해 두는 편이 안전합니다.
많은 최신 system은 허용된 운영체제만 시작하므로 직접 compile한 kernel의 boot를 기본적으로 거부합니다. 가장 이상적인 해결책은 certificate와 signing을 이용해 platform이 self-built kernel을 신뢰하도록 하는 것입니다. 이 과정은 문서 범위를 벗어나므로 `Documentation/admin-guide/module-signing.rst`와 관련 web 문서를 참조합니다.
다른 방법은 Secure Boot 같은 기능을 일시적으로 끄는 것입니다. 범용 x86 system에서는 BIOS Setup utility에서 끌 수 있지만 machine마다 절차가 크게 달라 여기서는 설명하지 않습니다.
주류 x86 Linux distribution에서는 Linux 환경에 대한 모든 Secure Boot 제한을 끄는 보편적인 방법도 있습니다. `mokutil --disable-validation`을 실행해 일회용 password를 만들고 기록한 뒤 restart합니다.
BIOS self-test 직후 bootloader Shim이 'Press any key to perform MOK management'라는 파란 화면과 countdown을 표시하면 시간이 끝나기 전에 key를 누릅니다. Menu에서 'Change Secure Boot state'를 고르고, Shim의 `MokManager`가 앞서 만든 일회용 password 중 임의로 고른 세 문자를 요구하면 입력합니다. Validation을 정말 끌 것인지 확인하고 MokManager가 machine을 reboot하도록 허용합니다.
Reference: build 요구 사항과 공간
418-480Kernel은 상당히 독립적이지만 compiler 외에도 몇몇 library가 필요할 수 있습니다. 필요한 항목은 Linux distribution과 build할 kernel configuration에 따라 달라집니다.
Debian, Ubuntu와 파생판에서는 보통 다음 package를 설치합니다.
sudo apt install bc binutils bison dwarves flex gcc git make openssl \
pahole perl-base libssl-dev libelf-devFedora와 파생판에서는 다음 명령을 사용합니다.
sudo dnf install binutils /usr/include/{libelf.h,openssl/pkcs7.h} \
/usr/bin/{bc,bison,flex,gcc,git,openssl,make,perl,pahole}openSUSE와 파생판에서는 다음 명령을 사용합니다.
sudo zypper install bc binutils bison dwarves flex gcc git make perl-base \
openssl openssl-devel libelf-dev목록에 `openssl`과 development header가 들어가는 이유는 많은 distribution이 x86 kernel 설정에서 활성화한 Secure Boot 지원에 필요하기 때문입니다. Configuration에 따라 bzip2, gzip, lz4, lzma, lzo, xz, zstd 같은 compression format 도구도 필요할 수 있습니다.
이 guide 밖의 작업에는 추가 library와 development header가 필요할 수 있습니다. 예를 들어 `tools/` directory의 kernel tool을 build하려면 zlib이 필요하고, `menuconfig` 또는 `xconfig`로 설정을 바꾸려면 ncurses 또는 Qt5 development header가 필요합니다.
앞에서 제시한 공간 수치는 충분한 여유를 더한 대략적인 추정치이므로 실제 사용량은 더 적을 때가 많습니다. 공간이 빠듯하다면 설정 조정 절에서 debug symbol을 확실히 끄십시오. 사용 공간을 수 GB 줄일 수 있습니다.
Reference: source와 shallow clone
481-546단계별 guide는 shallow git clone으로 Linux source를 받습니다. 대안은 packaged archive와 full git clone이며, 최신 mainline code와 정식 pre-release 중 무엇을 고를지, 더 최신 mainline codebase를 얻는 방법도 뒤에서 설명합니다.
Guide의 명령은 단순화를 위해 build artifact를 source tree에 저장합니다. 분리하고 싶다면 모든 make 호출에 `O=~/linux-builddir/` 같은 옵션을 붙이고, file을 추가하거나 `.config` 같은 생성물을 고치는 명령의 path도 그에 맞게 바꿉니다.
Shallow clone은 이 문서 독자 대부분에게 가장 알맞지만 알아둘 특성이 있습니다. 여기서는 `git fetch`의 `--shallow-exclude=`로 필요한 가장 오래된 version, 정확히는 git tag를 지정합니다. 대신 `--shallow-since='2023-07-15'` 같은 절대 날짜나 `--shallow-since='12 months'` 같은 상대 날짜를 쓸 수 있고, stable/longterm branch를 추가하지 않는다면 `--depth=1`처럼 깊이를 직접 지정할 수도 있습니다.
`git fetch`를 실행할 때는 단계별 guide처럼 가장 오래된 version, 관심 기간, 명시적 depth 중 하나를 항상 지정해야 합니다. 그렇지 않으면 거의 전체 git history를 내려받아 시간과 bandwidth를 많이 쓰고 server에도 부담을 줄 수 있습니다.
항상 같은 version이나 날짜를 쓸 필요는 없습니다. 기준을 바꾸면 git이 지정 지점까지 history를 깊게 만들거나 얕게 줄입니다. 처음에는 필요 없다고 생각했던 version을 나중에 가져올 수도 있고, 오래된 source를 버려 disk 공간을 확보할 수도 있습니다. `--shallow-since=`나 `--depth=`를 사용하면 후자가 자동으로 일어납니다.
Clone을 깊게 만들 때 `fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da`와 같은 오류가 나면 `git repack -d`를 실행하고 다시 시도합니다.
특정 version, 예를 들어 Linux 6.3의 변경을 revert하거나 v6.2부터 v6.3 사이를 bisect하려면 `git fetch`가 세 version 정도 더 오래된 object, 예를 들어 6.0까지 가져오게 하는 편이 좋습니다. 그러면 `git describe`가 full clone에서처럼 대부분의 commit을 설명할 수 있습니다.
Reference: archive, full clone, mainline
547-644Linux compile이 처음인 사람은 흔히 `https://kernel.org` 첫 화면에서 archive를 받는 것이 최선이라고 생각합니다. Code를 바꾸지 않고 특정 kernel version 하나만 build할 것이 확실하다면 실제로 좋은 선택일 수 있지만, 현실에서는 그 가정이 자주 빗나갑니다.
문제를 보고하거나 debug할 때 developer는 다른 version을 시험하거나 `git revert`로 commit을 잠시 되돌리거나 여러 patch를 적용해 보라고 할 수 있습니다. 문제를 만든 변경을 찾기 위해 `git bisect`를 요청할 때도 있습니다. 이런 작업은 git에 의존하거나 git을 쓰면 훨씬 쉽고 빠릅니다.
`git clone --depth=1`로 최신 mainline shallow clone을 만들어도 kernel.org에서 최신 mainline pre-release, 즉 rc archive를 받는 것보다 data가 조금 더 많을 뿐이므로 overhead는 크지 않습니다. 그래도 archive를 쓰려면 kernel.org에서 내려받아 directory에 풀고 생성된 subdirectory로 이동합니다. Git 의존 작업, 주로 후속 version build 절을 제외하면 나머지 guide는 그대로 적용됩니다.
약 4.4GB였던 2023년 초 기준 data를 내려받아 보관해도 괜찮다면 full git clone으로 shallow clone의 특이점을 피하고 모든 version과 개별 commit을 언제든 사용할 수 있습니다.
curl -L \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle \
-o linux-stable.git.bundle
git clone linux-stable.git.bundle ~/linux/
rm linux-stable.git.bundle
cd ~/linux/
git remote set-url origin \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
git fetch origin
git checkout --detach origin/masterGit으로 source를 clone하고 `origin/master`를 checkout하면 최신 release와 다음 release 또는 pre-release 사이의 codebase를 받는 경우가 많습니다. Mainline을 시험할 때는 대개 이것이 원하는 code입니다. `v6.1-rc5` 같은 pre-release도 공개 전 특별히 많은 추가 test를 받는 것은 아닙니다.
예외는 최신 mainline release, 예를 들어 v6.1 뒤에 다음 첫 pre-release인 v6.2-rc1이 나오기 전입니다. 이 보통 2주간의 `merge window`에는 다음 release의 변경 대부분이 합쳐지므로 compiler error와 다른 문제가 생길 가능성이 높습니다. 이때는 최신 mainline release에 머무를 수 있습니다.
이 문서의 shallow와 full clone 명령은 mainline과 stable/longterm에 쉽게 접근하도록 Linux stable git repository를 사용합니다. 단점은 mainline repository의 변경이 stable repository의 master branch로 동기화되기까지 몇 시간이 걸릴 수 있다는 점입니다.
대부분은 이 지연을 걱정할 필요가 없지만 정말 최신 code가 필요하면 mainline repository를 별도 remote로 추가하고 거기서 checkout합니다.
git remote add mainline \
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch mainline
git checkout --detach mainline/masterShallow clone에서 이 방법을 쓸 때도 앞서 설명한 parameter 중 하나로 `git fetch`의 depth를 제한해야 합니다.
Reference: patch, tag, base 설정
645-713Developer가 제안한 fix가 도움이 되는지 확인하는 경우처럼 kernel을 patch하려면 이 시점에 적용합니다. 핵심 절차는 단계별 guide에 이미 설명되어 있습니다.
Patched kernel이거나 같은 version을 이미 설치했다면 release name을 확장해 tag를 붙이는 것이 좋습니다. 개별 tag는 혼동을 줄이고 기존 kernel과 image 및 module이 나란히 설치되게 합니다.
Tag를 추가하는 방법은 여러 가지입니다. Guide는 build directory에 `localversion` file을 만들고 kernel build script가 tag를 자동으로 읽게 합니다. 다음 build에서 file 내용을 바꿔 다른 tag를 쓰거나 file을 지워 tag를 없앨 수 있습니다.
기존 설정을 base로 build configuration을 만들 때 `localmodconfig`와 `olddefconfig`에는 공통 함정이 있습니다.
첫째, build directory, 예를 들어 `~/linux/.config`에 설정이 있으면 그 file을 재사용합니다. 처음부터 시작하려면 기존 file을 지워야 합니다.
둘째, make target은 실행 중인 kernel 설정을 자동으로 찾지만 잘못 고를 수 있습니다. `# using defaults found in /boot/config-6.0.7-250.fc36.x86_64` 또는 `using config: '/boot/config-6.0.7-250.fc36.x86_64'` 같은 출력으로 선택된 file을 확인합니다. 원한 설정이 아니라면 올바른 file을 `~/linux/.config`에 먼저 저장합니다.
셋째, 한 kernel용 설정, 예를 들어 v6.0 설정을 더 오래된 generation인 v5.15에 쓰면 예상 밖의 동작이 생길 수 있습니다. 그 경우 distribution이 해당 version이나 조금 더 오래된 kernel에 사용했던 설정을 base로 삼는 편이 좋습니다.
Reference: 설정 값과 localmodconfig
714-770`olddefconfig`와 `localmodconfig` 앞의 `yes "" |`는 정의되지 않은 build option을 default value로 설정합니다. 따라서 base kernel 이후 추가된 많은 kernel 기능이 기본값에 따라 비활성화될 수 있습니다.
정의되지 않은 option을 직접 정하려면 `olddefconfig` 대신 `oldconfig`를 쓰거나 `localmodconfig`에서 `yes "" |`를 빼십시오. 각 option마다 질문을 받으며 답을 모르면 Enter를 눌러 default를 적용합니다.
`localmodconfig`는 실행 전에 사용하지 않은 작업에 필요한 module을 kernel에서 빠뜨릴 수 있습니다. 해당 작업을 처음 수행할 때 자동으로 load되는 module은 미리 한 번도 쓰지 않았다면 불필요한 것으로 판단되어 비활성화되기 때문입니다.
위험을 줄이려면 VM을 시작하고 VPN을 연결하며 CD/DVD ISO를 loop mount하고 CIFS, NFS 같은 network share를 mount합니다. 2FA key, headset, webcam 등 외부 장치와 평소 쓰지 않는 btrfs, ext4, FAT, NTFS, XFS file system을 가진 storage도 연결합니다. 그래도 필요한 것을 모두 떠올리기는 어렵고 kernel developer도 종종 하나씩 빠뜨립니다.
Test용 kernel이라면 이 위험을 지나치게 걱정하지 않아도 됩니다. 보통 핵심 기능은 남고, 중요한 기능이 빠졌다면 나중에 켜서 더 나은 kernel을 빠르게 compile하고 설치할 수 있습니다.
Self-built kernel을 계속 사용할 계획이라면 몇 주 동안 system이 load한 module을 기록해 위험을 줄일 수 있습니다. `modprobed-db`가 이를 자동화하며, 이후 `LSMOD=<path>`로 `localmodconfig`에 기록 file을 지정합니다.
yes "" | make LSMOD="${HOME}"/.config/modprobed.db localmodconfig다른 machine용 kernel을 원격 build할 때는 대상에서 `lsmod > lsmod_foo-machine`을 실행해 file을 build host로 옮깁니다. 그다음 `yes "" | make LSMOD=~/lsmod_foo-machine localmodconfig`로 지정합니다. 대상 machine의 base kernel configuration도 복사해 build directory의 `.config`로 두는 편이 좋습니다.
Reference: debug symbol과 distribution 설정
771-850필요에 따라 이 시점에 kernel configuration option을 조정합니다. 대부분의 사용자는 현재 설정을 그대로 두어도 되지만 stack trace를 해석해야 하거나 공간을 줄이려면 debug symbol을 자세히 살펴야 합니다.
Kernel이 panic, Oops, warning, BUG를 낼 때 debug symbol이 있으면 code에서 문제가 난 정확한 위치를 찾을 수 있습니다. 하지만 정보 수집과 삽입은 시간과 공간을 많이 씁니다. 2022년 말 기준 `localmodconfig`로 설정한 일반적인 x86 kernel의 build artifact는 debug symbol을 켜면 약 5GB, 끄면 1GB 미만이었습니다. Kernel image와 module도 커져 load 시간이 늘어납니다.
작은 kernel을 원하고 stack trace를 해석할 가능성이 낮다면 다음처럼 debug symbol을 비활성화합니다.
./scripts/config --file .config -d DEBUG_INFO \
-d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -d DEBUG_INFO_DWARF4 \
-d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE
make olddefconfig반대로 나중에 stack trace를 해석할 가능성이 충분하다면 `Documentation/admin-guide/tainted-kernels.rst`의 'Decode failure messages' 설명처럼 다음 option을 활성화합니다.
./scripts/config --file .config -d DEBUG_INFO_NONE -e DEBUG_KERNEL
-e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS -e KALLSYMS_ALL
make olddefconfig많은 주류 distribution은 kernel 설정에서 debug symbol을 켜므로 `localmodconfig`와 `olddefconfig`가 그 값을 이어받는 경우가 많습니다.
일부 범용 distribution에는 이 guide를 따를 때 알려진 build 문제가 있습니다. Debian에서는 build 실패를 일으킬 오래된 certificate file 참조를 제거합니다.
./scripts/config --file .config --set-str SYSTEM_TRUSTED_KEYS ''대신 필요한 certificate를 받아 `SYSTEM_TRUSTED_KEYS`가 가리키게 할 수도 있습니다. 자세한 내용은 Debian handbook을 보거나 `Documentation/admin-guide/module-signing.rst`에 따라 직접 certificate를 생성합니다.
Reference: 개별 설정, 오류, package
851-942다른 설정을 조정하려면 `make menuconfig`로 text-based UI를 열어 기능을 켜거나 끕니다. Graphical configurator는 `xconfig` 또는 `gconfig` target을 사용합니다. 각각 ncurses, Qt5, Gtk2 development library가 필요하며 누락된 항목은 error message가 알려 줍니다.
Build 단계에는 여러 종류의 문제가 생길 수 있습니다. Machine 설정 때문에 빠르게 고칠 수 있는 경우도 있고, code 문제라 developer만 고칠 수 있는 경우도 있습니다. Failure message를 자세히 보고 web을 조사하면 어느 쪽인지 판단할 수 있습니다. 먼저 다음 명령으로 build를 다시 시작합니다.
make V=1`V=1`은 실제 error를 확인하는 데 필요한 verbose output을 켭니다. 또한 이 명령은 모든 CPU core를 사용하는 `-j $(nproc --all)`을 빼서 병렬 출력이 뒤섞이는 일을 줄입니다.
몇 초 뒤 오류가 다시 나면 문제를 가장 잘 설명하는 line을 찾고 그중 일반적이지 않은 핵심 4~8단어를 web에서 검색합니다. Username이나 `/home/username/linux/` 같은 local path처럼 system에만 해당하는 문자열은 제외합니다. 일반 search engine을 먼저 쓰고, 이어서 `lore.kernel.org/all/`에서 Linux kernel mailing list를 검색합니다.
대부분은 원인 설명과 해결책을 찾을 수 있습니다. 맞는 결과가 없으면 검색어를 바꾸거나 다른 error line을 사용합니다. System 설정뿐 아니라 code 자체의 문제도 이미 다른 사람이 보고했을 가능성이 높아 patch나 workaround를 찾을 수 있습니다.
기본 build는 x86의 `bzImage`, `modules` 같은 target으로 image와 module을 만들고 나중 단계에서 설치합니다. 대신 `make -j $(nproc --all) bindeb-pkg`로 deb, `make -j $(nproc --all) binrpm-pkg`로 rpm, `make -j $(nproc --all) tarbz2-pkg`로 bzip2 압축 tarball을 바로 만들 수 있습니다.
이는 일부 target만 나열한 것이므로 다른 항목은 `make help`에서 확인합니다. 먼저 일반 build를 실행한 뒤 package target을 써도 이미 만들어진 결과를 재사용합니다.
Deb 또는 rpm package를 만들었다면 guide의 수동 설치·제거 절차 대신 `dpkg`, `rpm`이나 그 위의 `apt`, `aptitude`, `dnf/yum`, `zypper` 같은 package manager를 사용합니다. 이 target이 만드는 package는 여러 distribution에서 동작하도록 설계되어 배포판 자체 kernel package와 다르게 행동할 수 있습니다.
Reference: 설치와 다음 build
943-1008단계별 guide의 명령 뒤에 할 일은 `installkernel` executable의 존재와 구현에 따라 달라집니다. 많은 범용 distribution은 `/sbin/`에 필요한 일을 모두 하는 installer를 제공해 reboot만 하면 됩니다. 일부는 작업 일부만 하고, 몇몇은 아예 없어 사용자가 모두 처리해야 합니다.
`installkernel`을 찾으면 kernel build system이 image와 관련 file 설치를 이 프로그램에 맡깁니다. 거의 모든 distribution은 image를 `/boot/vmlinuz-<kernel release name>`으로 저장하고 `System.map-<kernel release name>`을 함께 둡니다. 같은 release name이 이미 있지 않다면 기존 kernel과 나란히 설치됩니다.
많은 installkernel은 범용 distribution boot에 필요한 `initramfs`, 즉 `initrd`를 만든 뒤 bootloader configuration에도 kernel을 추가합니다. Image보다 module을 먼저 설치해야 하므로 단계별 guide의 두 make target 순서를 지켜야 합니다. Distribution의 installkernel이 처리하지 않는 항목은 직접 수행합니다.
Arch Linux와 그 파생판처럼 installkernel이 전혀 없는 경우에는 kernel build system으로 module을 설치한 뒤 image와 `System.map`을 수동 설치합니다.
sudo make modules_install
sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease)
sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease)Distribution이 initramfs로 boot한다면 자체 도구로 새 kernel용 initramfs를 만들고, kernel을 bootloader configuration에 추가한 뒤 reboot합니다.
후속 kernel build 과정은 비슷하지만 이미 잘라낸 설정이 있으므로 다시 `localmodconfig`를 쓰지 않습니다. `oldconfig` 또는 `olddefconfig`로 기존 build configuration을 새 kernel version에 맞춥니다.
Git shallow clone을 사용했다면 source 설정 절의 차이를 기억해야 합니다. 조금 다른 `git fetch` 명령을 사용하고 다른 series로 전환할 때 remote branch를 추가해야 합니다.
Reference: kernel 제거
1009-1051Distribution package system을 거치지 않고 수동 설치해도 machine이 완전히 엉키지는 않습니다. Kernel 구성 요소는 두 곳에만 저장되고 보통 release name으로 식별되므로 나중에 쉽게 제거할 수 있습니다.
첫 위치는 설치된 kernel별 module을 담는 `/lib/modules/` 아래 directory입니다. Directory 이름이 kernel release name이므로 해당 kernel의 module을 모두 지우려면 그 directory를 제거합니다.
다른 위치는 `/boot/`이며 설치 중 보통 file 1~5개가 놓입니다. 대개 file name에 release name이 들어가지만 개수와 이름은 distribution의 `installkernel`과 initramfs generator에 따라 달라집니다.
어떤 distribution에서는 단계별 guide의 `kernel-install` 명령이 이 file들과 bootloader entry를 함께 지웁니다. 다른 distribution에서는 직접 처리해야 합니다. 다음 명령은 release name이 `6.0.1-foobar`인 kernel의 주요 file 두 개를 대화형으로 제거합니다.
rm -i /boot/{System.map,vmlinuz}-6.0.1-foobar이어서 `/boot/initramfs-6.0.1-foobar.img` 또는 `/boot/initrd.img-6.0.1-foobar`처럼 이름 붙은 initramfs를 지웁니다. `/boot/`에서 이름에 `6.0.1-foobar`가 들어간 다른 file도 확인해 제거하고 bootloader configuration에서도 kernel을 삭제합니다.
Kernel file이나 directory를 수동 삭제할 때 `*` 같은 wildcard를 매우 조심해야 합니다. 6.0 또는 6.0.1만 지우려다가 6.0.11 kernel의 file까지 지울 수 있습니다.
FAQ, 유지 관리, 재배포 조건
1052-1097이 how-to가 어떤 system에서 동작하지 않는 이유는 범위에 있습니다. 문서는 범용 PC나 server hardware에서 주류 Linux distribution을 사용할 때 보통 필요한 모든 것을 다루도록 설계되었고 다른 많은 환경에서도 동작하지만, 모든 use case를 한 guide에 넣으면 목적을 잃습니다.
모든 machine과 distribution별로 '이 경우에는 여기서 이것을 대신 또는 추가로 수행하라'는 조건을 수십·수백 개 넣으면 문서가 길고 복잡해져 따라가기 어려워집니다. 그럼에도 추가할 가치가 있는 use case가 있다면 앞서 설명한 방식으로 maintainer에게 제안하십시오.
본문은 여기서 끝납니다. 문서 maintainer는 Thorsten Leemhuis `<[email protected]>`입니다. Typo나 작은 오류는 직접 알려도 되고, 비교적 비공식적으로 변경을 기여할 수도 있습니다. 다만 copyright 처리를 위해 `[email protected]`를 CC하고 `Documentation/process/submitting-patches.rst`의 'Sign your work - the Developer's Certificate of Origin' 절에 따라 contribution에 sign-off해야 합니다.
이 text는 파일 위에 적힌 대로 `GPL-2.0+` 또는 `CC-BY-4.0`으로 이용할 수 있습니다. `CC-BY-4.0`만으로 배포하려면 저자를 'The Linux kernel development community'로 표시하고 다음 canonical source를 연결합니다: `https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/quickly-build-trimmed-linux.rst`.
Linux kernel source에 들어 있는 이 RST file의 content만 `CC-BY-4.0`으로 이용할 수 있습니다. Kernel build system 등으로 처리된 version에는 더 제한적인 license의 다른 file에서 가져온 content가 포함될 수 있습니다.
요약과 해설
quickly-build-trimmed-linux.rst:1-1097이 guide의 핵심은 현재 system 설정을 base로 필요한 기능만 남겨 compile 시간을 줄이되, Secure Boot와 `localmodconfig`의 module 누락, distribution별 설치 차이를 사전에 관리하는 것입니다.
반복 build에서는 처음 만든 `.config`를 유지하고 `olddefconfig`로 새 codebase에 맞춥니다. Kernel release tag를 고유하게 만들면 기존 kernel과 안전하게 공존하며 제거할 때도 대상 file을 분명히 식별할 수 있습니다.