요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _readme:
Linux kernel release 6.x <http://kernel.org/>
=============================================
These are the release notes for Linux version 6. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong.
What is Linux?
--------------
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
It is distributed under the GNU General Public License v2 - see the
accompanying COPYING file for more details.
On what hardware does it run?
-----------------------------
Although originally developed first for 32-bit x86-based PCs (386 or higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 Xtensa, and
ARC architectures.
Linux is easily portable to most general-purpose 32- or 64-bit architectures
as long as they have a paged memory management unit (PMMU) and a port of the
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
also been ported to a number of architectures without a PMMU, although
functionality is then obviously somewhat limited.
Linux has also been ported to itself. You can now run the kernel as a
userspace application - this is called UserMode Linux (UML).
Documentation
-------------
- There is a lot of documentation available both in electronic form on
the Internet and in books, both Linux-specific and pertaining to
general UNIX questions. I'd recommend looking into the documentation
subdirectories on any Linux FTP site for the LDP (Linux Documentation
Project) books. This README is not meant to be documentation on the
system: there are much better sources available.
- There are various README files in the Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. Please read the
:ref:`Documentation/process/changes.rst <changes>` file, as it
contains information about the problems, which may result by upgrading
your kernel.
Installing the kernel source
----------------------------
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (e.g. your home directory) and
unpack it::
xz -cd linux-6.x.tar.xz | tar xvf -
Replace "X" with the version number of the latest kernel.
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
- You can also upgrade between 6.x releases by patching. Patches are
distributed in the xz format. To install by patching, get all the
newer patch files, enter the top level directory of the kernel source
(linux-6.x) and execute::
xz -cd ../patch-6.x.xz | patch -p1
Replace "x" for all versions bigger than the version "x" of your current
source tree, **in_order**, and you should be ok. You may want to remove
the backup files (some-file-name~ or some-file-name.orig), and make sure
that there are no failed patches (some-file-name# or some-file-name.rej).
If there are, either you or I have made a mistake.
Unlike patches for the 6.x kernels, patches for the 6.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 6.x kernel. For example, if your base kernel is 6.0
and you want to apply the 6.0.3 patch, you must not first apply the 6.0.1
and 6.0.2 patches. Similarly, if you are running kernel version 6.0.2 and
want to jump to 6.0.3, you must first reverse the 6.0.2 patch (that is,
patch -R) **before** applying the 6.0.3 patch. You can read more on this in
:ref:`Documentation/process/applying-patches.rst <applying_patches>`.
Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found::
linux/scripts/patch-kernel linux
The first argument in the command above is the location of the
kernel source. Patches are applied from the current directory, but
an alternative directory can be specified as the second argument.
- Make sure you have no stale .o files and dependencies lying around::
cd linux
make mrproper
You should now have the sources correctly installed.
Software requirements
---------------------
Compiling and running the 6.x kernels requires up-to-date
versions of various software packages. Consult
:ref:`Documentation/process/changes.rst <changes>` for the minimum version numbers
required and how to get updates for these packages. Beware that using
excessively old versions of these packages can cause indirect
errors that are very difficult to track down, so don't assume that
you can just update packages when obvious problems arise during
build or operation.
Build directory for the kernel
------------------------------
When compiling the kernel, all output files will per default be
stored together with the kernel source code.
Using the option ``make O=output/dir`` allows you to specify an alternate
place for the output files (including .config).
Example::
kernel source code: /usr/src/linux-6.x
build directory: /home/name/build/kernel
To configure and build the kernel, use::
cd /usr/src/linux-6.x
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
Please note: If the ``O=output/dir`` option is used, then it must be
used for all invocations of make.
Configuring the kernel
----------------------
Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use ``make oldconfig``, which will
only ask you for the answers to new questions.
- Alternative configuration commands are::
"make config" Plain text interface.
"make menuconfig" Text based color menus, radiolists & dialogs.
"make nconfig" Enhanced text based color menus.
"make xconfig" Qt based configuration tool.
"make gconfig" GTK based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
new config symbols.
"make olddefconfig"
Like above, but sets new symbols to their default
values without prompting.
"make defconfig" Create a ./.config file by using the default
symbol values from either arch/$ARCH/configs/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.
"make ${PLATFORM}_defconfig"
Create a ./.config file by using the default
symbol values from
arch/$ARCH/configs/${PLATFORM}_defconfig.
Use "make help" to get a list of all available
platforms of your architecture.
"make allyesconfig"
Create a ./.config file by setting symbol
values to 'y' as much as possible.
"make allmodconfig"
Create a ./.config file by setting symbol
values to 'm' as much as possible.
"make allnoconfig" Create a ./.config file by setting symbol
values to 'n' as much as possible.
"make randconfig" Create a ./.config file by setting symbol
values to random values.
"make localmodconfig" Create a config based on current config and
loaded modules (lsmod). Disables any module
option that is not needed for the loaded modules.
To create a localmodconfig for another machine,
store the lsmod of that machine into a file
and pass it in as a LSMOD parameter.
Also, you can preserve modules in certain folders
or kconfig files by specifying their paths in
parameter LMC_KEEP.
target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp
host$ make LSMOD=/tmp/mylsmod \
LMC_KEEP="drivers/usb:drivers/gpu:fs" \
localmodconfig
The above also works when cross compiling.
"make localyesconfig" Similar to localmodconfig, except it will convert
all module options to built in (=y) options. You can
also preserve modules by LMC_KEEP.
"make kvm_guest.config" Enable additional options for kvm guest kernel
support.
"make xen.config" Enable additional options for xen dom0 guest kernel
support.
"make tinyconfig" Configure the tiniest possible kernel.
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.rst.
- NOTES on ``make config``:
- Having unnecessary drivers will make the kernel bigger, and can
under some circumstances lead to problems: probing for a
nonexistent controller card may confuse your other controllers.
- A kernel with math-emulation compiled in will still use the
coprocessor if one is present: the math emulation will just
never get used in that case. The kernel will be slightly larger,
but will work on different machines regardless of whether they
have a math coprocessor or not.
- The "kernel hacking" configuration details usually result in a
bigger or slower kernel (or both), and can even make the kernel
less stable by configuring some routines to actively try to
break bad code to find kernel problems (kmalloc()). Thus you
should probably answer 'n' to the questions for "development",
"experimental", or "debugging" features.
Compiling the kernel
--------------------
- Make sure you have at least gcc 8.1 available.
For more information, refer to :ref:`Documentation/process/changes.rst <changes>`.
- Do a ``make`` to create a compressed kernel image. It is also possible to do
``make install`` if you have lilo installed or if your distribution has an
install script recognised by the kernel's installer. Most popular
distributions will have a recognized install script. You may want to
check your distribution's setup first.
To do the actual install, you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
- If you configured any of the parts of the kernel as ``modules``, you
will also have to do ``make modules_install``.
- Verbose kernel compile/build output:
Normally, the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
For this, use "verbose" build mode. This is done by passing
``V=1`` to the ``make`` command, e.g.::
make V=1 all
To have the build system also tell the reason for the rebuild of each
target, use ``V=2``. The default is ``V=0``.
- Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a ``make modules_install``.
Alternatively, before compiling, use the kernel config option
"LOCALVERSION" to append a unique suffix to the regular kernel version.
LOCALVERSION can be set in the "General Setup" menu.
- In order to boot your new kernel, you'll need to copy the kernel
image (e.g. .../linux/arch/x86/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- Booting a kernel directly from a storage device without the assistance
of a bootloader such as LILO or GRUB, is no longer supported in BIOS
(non-EFI systems). On UEFI/EFI systems, however, you can use EFISTUB
which allows the motherboard to boot directly to the kernel.
On modern workstations and desktops, it's generally recommended to use a
bootloader as difficulties can arise with multiple kernels and secure boot.
For more details on EFISTUB,
see "Documentation/admin-guide/efi-stub.rst".
- It's important to note that as of 2016 LILO (LInux LOader) is no longer in
active development, though as it was extremely popular, it often comes up
in documentation. Popular alternatives include GRUB2, rEFInd, Syslinux,
systemd-boot, or EFISTUB. For various reasons, it's not recommended to use
software that's no longer in active development.
- Chances are your distribution includes an install script and running
``make install`` will be all that's needed. Should that not be the case
you'll have to identify your bootloader and reference its documentation or
configure your EFI.
Legacy LILO Instructions
------------------------
- If you use LILO the kernel images are specified in the file /etc/lilo.conf.
The kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image and copy
the new image over the old one. Then, you MUST RERUN LILO to update the
loading map! If you don't, you won't be able to boot the new kernel image.
- Reinstalling LILO is usually a matter of running /sbin/lilo. You may wish
to edit /etc/lilo.conf to specify an entry for your old kernel image
(say, /vmlinux.old) in case the new one does not work. See the LILO docs
for more information.
- After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
- If you ever need to change the default root device, video mode, etc. in the
kernel image, use your bootloader's boot options where appropriate. No need
to recompile the kernel to change these parameters.
- Reboot with the new kernel and enjoy.
If something goes wrong
-----------------------
If you have problems that seem to be due to kernel bugs, please follow the
instructions at 'Documentation/admin-guide/reporting-issues.rst'.
Hints on understanding kernel bug reports are in
'Documentation/admin-guide/bug-hunting.rst'. More on debugging the kernel
with gdb is in 'Documentation/process/debugging/gdb-kernel-debugging.rst' and
'Documentation/process/debugging/kgdb.rst'.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Linux 6.x, 지원 하드웨어, 문서
1-58이 `Linux kernel release 6.x <http://kernel.org/>` 문서는 Linux 버전 6의 릴리스 노트입니다. Linux가 무엇인지, kernel을 설치하는 방법, 문제가 생겼을 때 해야 할 일을 설명하므로 주의 깊게 읽어야 합니다.
Linux는 Linus Torvalds가 인터넷을 통해 느슨하게 연결된 개발자들의 도움을 받아 처음부터 작성한 Unix 운영체제의 복제 구현입니다. POSIX 및 Single UNIX Specification 준수를 목표로 합니다.
Linux는 진정한 멀티태스킹, 가상 메모리, 공유 라이브러리, demand loading, copy-on-write 방식으로 공유되는 실행 파일, 올바른 메모리 관리, IPv4와 IPv6를 포함하는 다중 스택 네트워킹 등 완전한 현대 Unix에서 기대할 수 있는 기능을 갖춥니다.
Linux는 GNU General Public License v2로 배포됩니다. 자세한 내용은 함께 제공되는 `COPYING` 파일을 참조하십시오.
Linux는 처음에는 32-bit x86 PC(386 이상)를 위해 개발됐지만, 현재는 적어도 Compaq Alpha AXP, Sun SPARC와 UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, Xtensa, ARC architecture에서도 실행됩니다.
Paged Memory Management Unit(PMMU)과 GNU C compiler(`gcc`, GNU Compiler Collection의 일부) port가 있으면 Linux는 대부분의 범용 32-bit 또는 64-bit architecture로 쉽게 이식할 수 있습니다. PMMU가 없는 여러 architecture에도 이식됐지만, 이 경우 기능에는 분명한 제한이 있습니다.
Linux는 자기 자신 위에서도 실행되도록 이식됐습니다. kernel을 userspace application으로 실행하는 이 방식을 UserMode Linux (UML)라고 합니다.
Linux 전용 자료와 일반 UNIX 주제를 다루는 자료는 인터넷과 서적 형태로 많이 제공됩니다. Linux FTP site의 documentation 하위 디렉터리에 있는 LDP(Linux Documentation Project) 서적을 살펴보는 것이 좋습니다. 이 `README`는 시스템 자체의 종합 문서가 아니며, 그 목적에는 더 좋은 자료가 있습니다.
`Documentation/` 하위 디렉터리에는 여러 `README` 파일이 있으며, 보통 특정 driver의 kernel 전용 설치 참고 사항을 담습니다. Kernel을 업그레이드하면서 발생할 수 있는 문제를 설명하는 `Documentation/process/changes.rst`도 읽어야 합니다.
Kernel source 설치와 patch 적용
59-113전체 source를 설치할 때는 kernel tarball을 권한이 있는 디렉터리, 예를 들어 home directory에 놓고 다음과 같이 압축을 풉니다.
xz -cd linux-6.x.tar.xz | tar xvf -명령의 `X`는 최신 kernel의 버전 번호로 바꿉니다. `/usr/src/linux` 영역은 사용하지 마십시오. 이곳에는 보통 불완전한 kernel header 집합이 있으며 library header가 사용합니다. 해당 header는 library와 일치해야 하므로 그때그때 사용하는 kernel source 때문에 뒤섞이면 안 됩니다.
6.x release 사이를 patch로 업그레이드할 수도 있습니다. Patch는 xz 형식으로 배포됩니다. 현재 source tree보다 새 버전인 patch 파일을 모두 받은 뒤 kernel source의 최상위 디렉터리(`linux-6.x`)에서 다음 명령을 실행합니다.
xz -cd ../patch-6.x.xz | patch -p1현재 source tree의 버전 `x`보다 큰 모든 버전에 대해 `x`를 바꾸어, 반드시 순서대로 적용합니다. 필요하면 backup 파일(`some-file-name~`, `some-file-name.orig`)을 제거하고 실패한 patch 파일(`some-file-name#`, `some-file-name.rej`)이 없는지 확인합니다. 실패 파일이 있다면 적용 과정이나 patch 자체에 오류가 있는 것입니다.
6.x kernel용 patch와 달리 6.x.y kernel, 즉 `-stable` kernel용 patch는 누적 증분 방식이 아니라 base 6.x kernel에 직접 적용됩니다. 예를 들어 base가 6.0이고 6.0.3을 적용하려면 6.0.1과 6.0.2를 먼저 적용하면 안 됩니다.
현재 6.0.2에서 6.0.3으로 이동할 때는 6.0.3을 적용하기 전에 먼저 `patch -R`로 6.0.2 patch를 되돌려야 합니다. 자세한 절차는 `Documentation/process/applying-patches.rst`를 참조하십시오.
또는 `patch-kernel` script로 이 과정을 자동화할 수 있습니다. Script는 현재 kernel 버전을 판별하고 발견한 patch를 적용합니다.
linux/scripts/patch-kernel linux첫 번째 인자는 kernel source 위치입니다. Patch는 현재 디렉터리에서 가져오며, 두 번째 인자로 다른 patch 디렉터리를 지정할 수 있습니다.
오래된 `.o` 파일과 dependency가 남아 있지 않도록 다음 명령으로 tree를 정리합니다.
cd linux
make mrproper이제 source가 올바르게 설치된 상태입니다.
Software 요구 사항과 분리된 build directory
114-1476.x kernel을 compile하고 실행하려면 여러 software package의 최신 버전이 필요합니다. 필요한 최소 버전과 package 갱신 방법은 `Documentation/process/changes.rst`에서 확인합니다.
지나치게 오래된 package는 추적하기 매우 어려운 간접 오류를 일으킬 수 있습니다. Build나 실행 중 명백한 문제가 나타났을 때만 package를 갱신하면 된다고 가정해서는 안 됩니다.
기본적으로 kernel을 compile하면 모든 출력 파일은 kernel source code와 함께 저장됩니다. `make O=output/dir` 옵션을 사용하면 `.config`를 포함한 출력 파일의 다른 위치를 지정할 수 있습니다. 다음은 source와 build directory의 예입니다.
kernel source code: /usr/src/linux-6.x
build directory: /home/name/build/kernelKernel을 설정하고 build하는 명령은 다음과 같습니다.
cd /usr/src/linux-6.x
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install`O=output/dir` 옵션을 사용했다면 모든 `make` 호출에 반드시 같은 옵션을 사용해야 합니다.
Kernel 설정 target과 주의 사항
148-258Minor version 하나만 올리더라도 설정 단계를 생략하지 마십시오. Release마다 새 설정 옵션이 추가되며, 설정 파일이 예상대로 준비되지 않으면 뜻밖의 문제가 생깁니다.
기존 설정을 최소한의 작업으로 새 버전에 가져가려면 `make oldconfig`를 사용합니다. 이 target은 새 질문에 대해서만 답을 요구합니다.
| 설정 명령 | 동작 |
|---|---|
| `make config` | 일반 텍스트 인터페이스 |
| `make menuconfig` | 텍스트 기반 컬러 메뉴, 라디오 목록, 대화 상자 |
| `make nconfig` | 향상된 텍스트 기반 컬러 메뉴 |
| `make xconfig` | Qt 기반 설정 도구 |
| `make gconfig` | GTK 기반 설정 도구 |
| `make oldconfig` | 기존 `./.config`를 기준으로 답을 기본 지정하고 새 설정 symbol만 질문 |
| `make olddefconfig` | `oldconfig`와 같지만 질문하지 않고 새 symbol을 기본값으로 설정 |
| `make defconfig` | `arch/$ARCH/configs/defconfig` 또는 `arch/$ARCH/configs/${PLATFORM}_defconfig`의 기본 symbol 값으로 `./.config` 생성 |
| `make ${PLATFORM}_defconfig` | `arch/$ARCH/configs/${PLATFORM}_defconfig`의 기본값으로 `./.config` 생성; 플랫폼 목록은 `make help`로 확인 |
| `make allyesconfig` | 가능한 한 많은 설정 symbol을 `y`로 지정해 `./.config` 생성 |
| `make allmodconfig` | 가능한 한 많은 설정 symbol을 `m`으로 지정해 `./.config` 생성 |
| `make allnoconfig` | 가능한 한 많은 설정 symbol을 `n`으로 지정해 `./.config` 생성 |
| `make randconfig` | 설정 symbol을 무작위 값으로 지정해 `./.config` 생성 |
| `make localmodconfig` | 현재 설정과 로드된 모듈(`lsmod`)을 기준으로 설정을 만들고, 로드된 모듈에 필요하지 않은 module 옵션 비활성화 |
| `make localyesconfig` | `localmodconfig`과 비슷하지만 module 옵션을 모두 built-in(`=y`)으로 변환 |
| `make kvm_guest.config` | KVM guest kernel 지원에 필요한 추가 옵션 활성화 |
| `make xen.config` | Xen dom0 guest kernel 지원에 필요한 추가 옵션 활성화 |
| `make tinyconfig` | 가능한 한 가장 작은 kernel로 설정 |
`make localmodconfig`는 현재 설정과 로드된 module을 기준으로 설정을 만들며, 로드된 module에 필요하지 않은 module 옵션을 비활성화합니다. 다른 시스템을 위한 설정을 만들려면 대상 시스템의 `lsmod` 결과를 파일로 저장해 `LSMOD` parameter로 전달합니다.
특정 디렉터리의 module이나 Kconfig 파일을 보존하려면 그 경로를 `LMC_KEEP` parameter에 지정합니다. 다음 예는 대상 시스템의 module 목록을 host로 옮긴 뒤 USB, GPU, filesystem 관련 설정을 유지하면서 `localmodconfig`를 실행합니다.
target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp
host$ make LSMOD=/tmp/mylsmod \
LMC_KEEP="drivers/usb:drivers/gpu:fs" \
localmodconfig위 방식은 cross compiling에도 적용됩니다. `make localyesconfig`는 같은 정보를 사용하지만 module 옵션을 built-in(`=y`)으로 바꾸며, 이때도 `LMC_KEEP`으로 module을 보존할 수 있습니다.
Linux kernel 설정 도구에 관한 자세한 내용은 `Documentation/kbuild/kconfig.rst`에서 확인할 수 있습니다.
`make config`를 사용할 때 불필요한 driver를 포함하면 kernel이 커지고 경우에 따라 문제가 생길 수 있습니다. 존재하지 않는 controller card를 probe하는 과정이 다른 controller를 혼란스럽게 할 수도 있습니다.
Math emulation을 compile해 넣은 kernel도 coprocessor가 있으면 이를 사용하며, 그 경우 emulation은 사용되지 않습니다. Kernel 크기는 조금 커지지만 math coprocessor 유무와 관계없이 여러 시스템에서 실행할 수 있습니다.
`kernel hacking` 설정은 보통 kernel을 더 크거나 느리게 만들며 둘 다 일어날 수도 있습니다. 일부 routine은 나쁜 코드를 적극적으로 깨뜨려 `kmalloc()` 같은 kernel 문제를 찾도록 설정되므로 안정성이 낮아질 수도 있습니다.
따라서 특별한 개발 목적이 없다면 `development`, `experimental`, `debugging` 기능 질문에는 대체로 `n`으로 답하는 편이 좋습니다.
Compile, 설치, boot 준비
259-325적어도 `gcc 8.1`을 사용할 수 있어야 합니다. 추가 요구 사항은 `Documentation/process/changes.rst`를 참조하십시오.
`make`를 실행해 압축된 kernel image를 만듭니다. LILO가 설치되어 있거나 배포판에 kernel installer가 인식하는 설치 script가 있으면 `make install`을 사용할 수도 있습니다. 널리 쓰이는 배포판은 대부분 인식 가능한 설치 script를 제공하므로 먼저 배포판 설정을 확인하는 것이 좋습니다.
실제 설치에는 root 권한이 필요하지만 일반적인 build에는 필요하지 않습니다. Kernel 일부를 `modules`로 설정했다면 `make modules_install`도 실행해야 합니다.
Kernel build system은 보통 비교적 조용하게 동작합니다. Compile, link, 기타 명령이 정확히 어떻게 실행되는지 확인하려면 `make`에 `V=1`을 전달해 verbose build mode를 사용합니다.
make V=1 all각 target을 다시 build하는 이유까지 표시하려면 `V=2`를 사용합니다. 기본값은 `V=0`입니다.
문제가 생길 때를 대비해 backup kernel을 준비해 두십시오. 아직 충분히 debug되지 않은 새 코드가 들어가는 development release에서는 특히 중요합니다. 그 kernel에 대응하는 module도 함께 보관해야 합니다.
작동 중인 kernel과 같은 버전 번호의 새 kernel을 설치한다면 `make modules_install`을 실행하기 전에 기존 module directory를 backup합니다. 또는 compile 전에 `General Setup` 메뉴의 `LOCALVERSION`에 고유 suffix를 지정해 일반 kernel 버전에 붙일 수 있습니다.
새 kernel로 boot하려면 compile 뒤의 kernel image, 예를 들어 `.../linux/arch/x86/boot/bzImage`를 평소 boot 가능한 kernel이 있는 위치로 복사해야 합니다.
BIOS 기반 non-EFI 시스템에서는 LILO나 GRUB 같은 bootloader의 도움 없이 storage device에서 kernel을 직접 boot하는 방식이 더 이상 지원되지 않습니다. UEFI/EFI 시스템에서는 motherboard가 kernel을 직접 boot할 수 있게 하는 EFISTUB를 사용할 수 있습니다.
현대 workstation과 desktop에서는 여러 kernel과 secure boot 때문에 문제가 생길 수 있으므로 일반적으로 bootloader 사용을 권장합니다. EFISTUB의 자세한 내용은 `Documentation/admin-guide/efi-stub.rst`를 참조하십시오.
LILO(LInux LOader)는 2016년부터 더 이상 활발히 개발되지 않지만 과거에 매우 널리 쓰였기 때문에 문서에 자주 등장합니다. 널리 쓰이는 대안으로 GRUB2, rEFInd, Syslinux, systemd-boot, EFISTUB가 있습니다. 여러 이유로 유지보수가 끝난 software는 사용하지 않는 것이 좋습니다.
배포판에 설치 script가 포함되어 있다면 보통 `make install`만으로 충분합니다. 그렇지 않다면 사용하는 bootloader를 확인해 해당 문서를 따르거나 EFI를 설정해야 합니다.
원본 준비, 설정, build, 설치, boot 항목 갱신, 검증의 순서를 요약합니다.
Legacy LILO 절차
326-350LILO를 사용한다면 kernel image는 `/etc/lilo.conf`에 지정됩니다. Kernel image 파일은 보통 `/vmlinuz`, `/boot/vmlinuz`, `/bzImage`, `/boot/bzImage`입니다.
새 kernel을 사용하려면 기존 image의 사본을 저장하고 새 image를 기존 위치에 복사합니다. 그런 다음 loading map을 갱신하도록 반드시 LILO를 다시 실행해야 합니다. 이 단계를 생략하면 새 kernel image로 boot할 수 없습니다.
LILO 재설치는 보통 `/sbin/lilo`를 실행하면 됩니다. 새 kernel이 동작하지 않을 때를 대비해 `/etc/lilo.conf`를 편집하고 예를 들어 `/vmlinux.old` 같은 기존 kernel image 항목을 추가할 수 있습니다. 자세한 내용은 LILO 문서를 참조하십시오.
LILO를 다시 설치한 뒤 시스템을 종료하고 reboot합니다. 기본 root device, video mode 같은 kernel image parameter를 바꿔야 한다면 적절한 bootloader boot 옵션을 사용하십시오. 이런 parameter를 바꾸기 위해 kernel을 다시 compile할 필요는 없습니다.
새 kernel로 reboot해 동작을 확인합니다.
문제가 생겼을 때
351-360Kernel bug 때문에 생긴 것으로 보이는 문제가 있다면 `Documentation/admin-guide/reporting-issues.rst`의 지침을 따르십시오.
Kernel bug report를 이해하는 방법은 `Documentation/admin-guide/bug-hunting.rst`에 있습니다. `gdb`를 사용한 kernel debugging은 `Documentation/process/debugging/gdb-kernel-debugging.rst`와 `Documentation/process/debugging/kgdb.rst`를 참조하십시오.
요약과 해설
README.rst:1-360이 문서는 Linux 6.x kernel을 직접 준비하고 설정·build·설치하는 전체 경로의 출발점입니다. 핵심 원칙은 요구 도구 버전을 먼저 확인하고, 설정 단계를 건너뛰지 않으며, 분리 build를 쓸 때 모든 `make` 호출에 같은 `O=` 값을 유지하는 것입니다.
설치보다 중요한 안전장치는 작동 중인 kernel과 그에 대응하는 module을 보존하는 일입니다. 새 image를 boot 경로에 놓은 뒤에는 사용하는 bootloader 또는 EFI 방식에 맞게 항목을 갱신하고, 문제가 있으면 kernel issue reporting 문서의 절차를 따라야 합니다.