Lines Matching +full:step +full:- +full:up
1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
9 testing purposes, but perfectly fine for day-to-day use, too.
15 section below: it contains a step-by-step guide, which is more detailed, but
21 self-compiled Linux kernels; install compilers and everything else needed for
26 git clone --depth 1 -b master \
34 make -j $(nproc --all)
37 command -v installkernel && sudo make modules_install install
43 git fetch --depth 1 origin
45 git checkout --force --detach origin/master
49 make -j $(nproc --all)
51 command -v installkernel && sudo make modules_install install
54 Step-by-step guide
67 Nonetheless, kernels built this way are also totally fine for day-to-day use
68 while at the same time being easy to keep up to date.
73 that might occur at a particular point -- and how to then get things rolling
79 quickly look something up in the reference section and afterwards jump back
81 https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html
93 ensure the system will permit your self-compiled kernel to boot later. The
97 ``mokutil --disable-validation``.
117 section for the step that explains adjusting your kernels build
139 git clone --no-checkout --depth 1 -b master \
143 If you want to access recent mainline releases and pre-releases, deepen you
146 git fetch --shallow-exclude=v6.0 origin
149 the branch holding that series; afterwards fetch the history at least up to
152 git remote set-branches --add origin linux-6.1.y
153 git fetch --shallow-exclude=v6.0 origin
159 git checkout --detach origin/master
163 pre-release like ``v6.2-rc1`` will work, too. Stable or longterm versions
174 patch -p1 < ../proposed-fix.patch
176 If the ``-p1`` is actually needed, depends on how the patch was created; in
180 reset --hard`` to undo any changes to the sources.
189 echo "-proposed_fix" > localversion
191 Running ``uname -r`` under your kernel later will then print something like
192 '6.1-rc4-proposed_fix'.
208 Using this make target is fine for everybody else, too -- but you often can
219 did not use since you booted your Linux -- like drivers for currently
253 make -j $(nproc --all)
255 If you want your kernel packaged up as deb, rpm, or tar file, see the
264 command -v installkernel && sudo make modules_install install
293 git remote set-branches --add origin linux-6.2.y
299 git fetch --shallow-exclude=v6.0 origin
301 Now switch to the version you are interested in -- but be aware the command
305 git checkout --force --detach origin/master
319 make -j $(nproc --all)
323 command -v installkernel && sudo make modules_install install
335 after its release name -- '6.0.1-foobar' in the following example::
337 sudo rm -rf /lib/modules/6.0.1-foobar
343 command -v kernel-install && sudo kernel-install -v remove 6.0.1-foobar
346 do the same if any files named '*6.0.1-foobar*' remain in /boot/.
352 Did you run into trouble following any of the above steps that is not cleared up
356 Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is vital to
360 Reference section for the step-by-step guide
369 -----------------------
375 -- especially if you fiddle with crucial parts like the kernel of an operating
379 [:ref:`back to step-by-step guide <backup_sbs>`]
384 ----------------------------------------
387 ensure the system will permit your self-compiled kernel to boot later.*
391 default will reject booting self-compiled kernels.
393 You ideally deal with this by making your platform trust your self-built kernels
396 its purpose; 'Documentation/admin-guide/module-signing.rst' and various web
406 initiate this process by running ``mokutil --disable-validation``; this will
407 tell you to create a one-time password, which is safe to write down. Now
408 restart; right after your BIOS performed all self-tests the bootloader Shim will
412 randomly chosen characters from the one-time password specified earlier. Once
416 [:ref:`back to step-by-step guide <secureboot_sbs>`]
421 --------------------------
426 The kernel is pretty stand-alone, but besides tools like the compiler you will
437 pahole perl-base libssl-dev libelf-dev
446 sudo zypper install bc binutils bison dwarves flex gcc git make perl-base \
447 openssl openssl-devel libelf-dev
462 [:ref:`back to step-by-step guide <buildrequires_sbs>`]
467 ------------------
480 [:ref:`back to step-by-step guide <diskspace_sbs>`]
486 --------------------
491 The step-by-step guide outlines how to retrieve Linux' sources using a shallow
495 be wiser to use a proper pre-release than the latest mainline code
501 something like ``O=~/linux-builddir/`` to all make calls; also adjust the path
504 [:ref:`back to step-by-step guide <sources_sbs>`]
511 The step-by-step guide uses a shallow clone, as it is the best solution for most
515 * This document in most places uses ``git fetch`` with ``--shallow-exclude=``
517 tag). You alternatively can use the parameter ``--shallow-since=`` to specify
518 an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to
521 like ``--depth=1``, unless you add branches for stable/longterm kernels.
524 the time you care about, or an explicit depth as shown in the step-by-step
532 you did not need -- or it will discard the sources of older versions, for
533 example in case you want to free up some disk space. The latter will happen
534 automatically when using ``--shallow-since=`` or
535 ``--depth=``.
539 In that case run ``git repack -d`` and try again``
543 objects up to three versions earlier (e.g. 6.0): ``git describe`` will then
546 [:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
554 front-page of https://kernel.org is the best approach to retrieve Linux'
566 you use ``git clone --depth=1`` to create a shallow clone of the latest mainline
568 mainline pre-release (aka 'rc') via the front-page of kernel.org would.
573 during extraction. The rest of the step-by-step guide will work just fine, apart
574 from things that rely on git -- but this mainly concerns the section on
577 [:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
589 curl -L \
591 -o linux-stable.git.bundle
592 git clone linux-stable.git.bundle ~/linux/
593 rm linux-stable.git.bundle
595 git remote set-url origin \
598 git checkout --detach origin/master
600 [:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
604 Proper pre-releases (RCs) vs. latest mainline
609 release or pre-release. This almost always is the code you want when giving
610 mainline a shot: pre-releases like v6.1-rc5 are in no way special, as they do
614 (say v6.1) before its successor's first pre-release (v6.2-rc1) is out. That is
619 [:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
639 git checkout --detach mainline/master
644 [:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
649 ----------------------------
654 This is the point where you might want to patch your kernel -- for example when
655 a developer proposed a fix and asked you to check if it helps. The step-by-step
658 [:ref:`back to step-by-step guide <patching_sbs>`]
663 ------------------------------------------------
673 There are various ways to add such a tag. The step-by-step guide realizes one by
675 build scripts will automatically pick up the tag. You can later change that file
679 [:ref:`back to step-by-step guide <tagging_sbs>`]
684 ----------------------------------------------
704 in /boot/config-6.0.7-250.fc36.x86_64' or 'using config:
705 '/boot/config-6.0.7-250.fc36.x86_64' tells you which file they picked. If
731 As explained briefly in the step-by-step guide already: with localmodconfig it
732 can easily happen that your self-built kernel will lack modules for tasks you
740 additional kernel modules: start a VM, establish VPN connections, loop-mount a
744 is hard to think of everything that might be needed -- even kernel developers
752 But if you plan to build and use self-built kernels regularly, you might want to
754 a few weeks. You can automate this with `modprobed-db
755 <https://github.com/graysky2/modprobed-db>`_. Afterwards use ``LSMOD=<path>`` to
756 point localmodconfig to the list of modules modprobed-db noticed being used::
764 ``lsmod > lsmod_foo-machine`` on it and transfer that file to your build host.
766 LSMOD=~/lsmod_foo-machine localmodconfig``. Note, in this case
770 [:ref:`back to step-by-step guide <configuration_sbs>`]
775 --------------------------
807 ./scripts/config --file .config -d DEBUG_INFO \
808 -d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -d DEBUG_INFO_DWARF4 \
809 -d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE
814 failure messages' in Documentation/admin-guide/tainted-kernels.rst in more
817 ./scripts/config --file .config -d DEBUG_INFO_NONE -e DEBUG_KERNEL
818 -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS -e KALLSYMS_ALL
822 configurations -- make targets like localmodconfig and olddefconfig thus will
823 often pick that setting up.
825 [:ref:`back to step-by-step guide <configmods_sbs>`]
842 ./scripts/config --file .config --set-str SYSTEM_TRUSTED_KEYS ''
846 <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
847 -- or generate your own, as explained in
848 Documentation/admin-guide/module-signing.rst.
850 [:ref:`back to step-by-step guide <configmods_sbs>`]
861 disable certain features using a text-based user interface; to use a graphical
867 [:ref:`back to step-by-step guide <configmods_sbs>`]
872 -----------------
877 yourself. Another subsection explains how to directly package your kernel up as
893 error. To make it easier to spot, this command also omits the ``-j $(nproc
894 --all)`` used earlier to utilize every CPU core in the system for the job -- but
899 for the most important and non-generic section of that line (say 4 to 8 words);
900 avoid or remove anything that looks remotely system-specific, like your username
915 Package your kernel up
918 The step-by-step guide uses the default make targets (e.g. 'bzImage' and
921 and directly package it up by using one of the following targets:
923 * ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package
925 * ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package
927 * ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball
931 ``make -j $(nproc --all)``, as they will pick up everything already built.
934 step-by-step guide's instructions on installing and removing your kernel;
942 [:ref:`back to step-by-step guide <build_sbs>`]
947 -------------------
951 What you need to do after executing the command in the step-by-step guide
956 only part of the job -- and a few lack it completely and leave all the work to
961 On almost all Linux distributions it will store the image as '/boot/vmlinuz-
962 <your kernel's release name>' and put a 'System.map-<your kernel's release
968 hence be sure to keep the order of the two make targets used in the step-by-step
979 sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease)
980 sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease)
986 [:ref:`back to step-by-step guide <install_sbs>`]
991 -------------------
1003 If you created a shallow-clone with git, remember what the :ref:`section that
1008 [:ref:`back to step-by-step guide <another_sbs>`]
1013 --------------------------
1019 distribution's packaging system will totally mess up your machine: all parts of
1032 initramfs generator. On some distributions the ``kernel-install`` command
1033 mentioned in the step-by-step guide will remove all of these files for you --
1037 release name '6.0.1-foobar'::
1039 rm -i /boot/{System.map,vmlinuz}-6.0.1-foobar
1042 ``/boot/initramfs-6.0.1-foobar.img`` or ``/boot/initrd.img-6.0.1-foobar``.
1043 Afterwards check for other files in /boot/ that have '6.0.1-foobar' in their
1051 [:ref:`back to step-by-step guide <uninstall_sbs>`]
1058 Why does this 'how-to' not work on my system?
1059 ---------------------------------------------
1064 on many other setups as well. But trying to cover every possible use-case in one
1072 additional use-case is worth describing, suggest it to the maintainers of this
1077 end-of-content
1082 want to contribute changes to the text -- but for copyright reasons please CC
1083 linux-doc@vger.kernel.org and 'sign-off' your contribution as
1084 Documentation/process/submitting-patches.rst explains in the section 'Sign
1085 your work - the Developer's Certificate of Origin'.
1087 This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
1088 of the file. If you want to distribute this text under CC-BY-4.0 only,
1091 …/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/quickly-build-trimmed-linux.r…
1094 is available under CC-BY-4.0, as versions of this text that were processed