Lines Matching +full:debian +full:- +full:arm64 +full:- +full:build +full:- +full:test
1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
9 currently supported by developers -- to then explain how to locate the change
22 read and navigate this document -- especially when you want to look something
26 https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
32 over to the* ':ref:`step-by-step guide <introguide_bissbs>`' *below. It utilizes
45 *segment 2*. Then you can submit a preliminary report -- or continue with
47 full-fledged regression report. In the following example 6.0.13 is assumed to be
51 * **Preparations**: set up everything to build your own kernels::
55 # * Ensure Secure Boot permits booting self-compiled Linux kernels.
59 git clone -o mainline --no-checkout \
62 git remote add -t master stable \
64 git switch --detach v6.0
71 ./scripts/config --set-str CONFIG_LOCALVERSION '-local'
72 ./scripts/config -e CONFIG_LOCALVERSION_AUTO
74 ./scripts/config -d DEBUG_INFO_NONE -e KALLSYMS_ALL -e DEBUG_KERNEL \
75 -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS
76 # * Hint: at this point you might want to adjust the build configuration;
77 # you'll have to, if you are running Debian.
79 cp .config ~/kernel-config-working
81 * **Segment 1**: build a kernel from the latest mainline codebase.
90 git switch --discard-changes --detach mainline/master
92 b) Build, install, and boot a kernel::
94 cp ~/kernel-config-working .config
96 make -j $(nproc --all)
98 df -h /boot/ /lib/modules/
101 # job. See the step-by-step guide for further details.
103 command -v installkernel && sudo make install
104 # * Check how much space your self-built kernel actually needs, which
106 du -ch /boot/*$(make -s kernelrelease)* | tail -n 1
107 du -sh /lib/modules/$(make -s kernelrelease)/
110 make -s kernelrelease | tee -a ~/kernels-built
114 tail -n 1 ~/kernels-built
115 uname -r
128 git switch --discard-changes --detach v6.0
130 b) Build, install, and boot a kernel as described earlier in *segment 1,
131 section b* -- just feel free to skip the 'du' commands, as you have a rough
141 git remote set-branches --add stable linux-6.1.y
151 c) Build, install, and boot a kernel as described earlier in *segment 1,
159 All three commands will make Git check out another commit; then re-execute
160 this step (e.g. build, install, boot, and test a kernel to then tell Git
169 git bisect log > ~/bisect-log
170 cp .config ~/bisection-config-culprit
175 git switch --discard-changes --detach mainline/master
176 git revert --no-edit cafec0cacaca0
177 cp ~/kernel-config-working .config
178 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
181 second command worked flawlessly, build, install, and boot one more kernel
191 (Segment 3 c). You can list them in build order using::
193 ls -ltr /lib/modules/*-local*
196 '6.0-rc1-local-gcafec0cacaca0', use this::
198 sudo rm -rf /lib/modules/6.0-rc1-local-gcafec0cacaca0
199 sudo kernel-install -v remove 6.0-rc1-local-gcafec0cacaca0
200 # * Note, on some distributions kernel-install is missing
208 * **Optional task**: test a debug patch or a proposed fix later::
211 git switch --discard-changes --detach mainline/master
212 git apply /tmp/foobars-proposed-fix-v1.patch
213 cp ~/kernel-config-working .config
214 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-foobars-fix-v1'
216 Build, install, and boot a kernel as described in *segment 1, section b* --
217 but this time omit the first command copying the build configuration over,
222 Step-by-step guide on how to verify bugs and bisect regressions
231 set to report the bug -- unless it did not happen with earlier kernel versions,
236 *segment 3* to **perform a bisection** for a full-fledged regression report
239 :ref:`Preparations: set up everything to build your own kernels <introprep_bissbs>`.
243 :ref:`Segment 2: check if the kernels you build work fine <introworkingcheck_bissbs>`.
249 :ref:`Optional tasks: test reverts, patches, or later versions <introoptional_bissbs>`.
254 pitfalls, as well as problems that might occur at the particular step -- and how
258 out Documentation/admin-guide/reporting-issues.rst, which works in conjunction
260 the latest 'mainline' kernel (e.g. versions like 6.0, 6.1-rc1, or 6.1-rc6),
267 as a regression check out Documentation/admin-guide/reporting-regressions.rst.
274 Preparations: set up everything to build your own kernels
275 ---------------------------------------------------------
281 :ref:`Build kernels on a different machine <buildhost_bis>` below.
301 ensure the system will permit your self-compiled kernel to boot. The
305 ``mokutil --disable-validation``.
316 you regularly use currently as 'good' (e.g. 6.0, 6.0.13, or 6.1-rc2).
323 (say 6.0.13) to a newer mainline series (like 6.1-rc7 or 6.1) or a
327 (e.g. 6.1-rc7, 6.1, or 6.1.5). Note, at this point it is merely assumed
331 a later one (like 6.1-rc1) or a stable/longterm release based on it
333 the first broken (e.g. 6.1-rc1 or 6.1.5) as 'bad'.
363 * Install all software required to build a Linux kernel. Often you will need:
386 git clone -o mainline --no-checkout \
389 git remote add -t master stable \
398 to ('linux-6.1.y' in this example)::
400 git remote set-branches --add stable linux-6.1.y
405 * Start preparing a kernel build configuration (the '.config' file).
409 identifier using ``uname -r``.
416 git switch --discard-changes --detach v6.0
418 Now create a build configuration file::
422 The kernel build scripts then will try to locate the build configuration file
429 like 'arch/x86/configs/x86_64_defconfig', then the build infra failed to find
430 the .config file for your running kernel -- in which case you have to put one
434 written to .config'. If that's the case you have a stale build configuration
444 optional, but especially wise for bisections, as it speeds up the build
445 process enormously -- at least unless the .config file picked up in the
460 used occasionally -- like modules for external peripherals not yet connected
470 spending much effort on, as long as it boots and allows to properly test the
477 * Ensure all the kernels you will build are clearly identifiable using a special
480 ./scripts/config --set-str CONFIG_LOCALVERSION '-local'
481 ./scripts/config -e CONFIG_LOCALVERSION_AUTO
493 ./scripts/config -d DEBUG_INFO_NONE -e KALLSYMS_ALL -e DEBUG_KERNEL \
494 -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS
499 ./scripts/config -d DEBUG_INFO -d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \
500 -d DEBUG_INFO_DWARF4 -d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE
509 * Are you running Debian? Then you want to avoid known problems by performing
527 cp .config ~/kernel-config-working
534 ----------------------------------------------------------------
548 latest version ('linux-6.1.y' in the following example)::
551 git switch --discard-changes --detach stable/linux-6.1.y
555 linux-6.2.y) or mainline (see next point) fix the bug.
560 git switch --discard-changes --detach mainline/master
566 * Build the image and the modules of your first kernel using the config file you
569 cp ~/kernel-config-working .config
571 make -j $(nproc --all)
585 df -h /boot/ /lib/modules/
594 command -v installkernel && sudo make install
607 down: if you will build more kernels as described in segment 2 and 3, you will
608 have to perform those again after executing ``command -v installkernel [...]``.
617 du -ch /boot/*$(make -s kernelrelease)* | tail -n 1
618 du -sh /lib/modules/$(make -s kernelrelease)/
629 make -s kernelrelease | tee -a ~/kernels-built
638 tail -n 1 ~/kernels-built
639 uname -r
663 the regression with it? Then you should test the latest mainline codebase as
667 To prepare that test, check out current mainline::
670 git switch --discard-changes --detach mainline/master
672 Now use the checked out code to build and install another kernel using the
675 cp ~/kernel-config-working .config
677 make -j $(nproc --all)
679 df -h /boot/ /lib/modules/
681 command -v installkernel && sudo make install
682 make -s kernelrelease | tee -a ~/kernels-built
688 tail -n 1 ~/kernels-built
689 uname -r
694 stable team. See Documentation/admin-guide/reporting-issues.rst for details.
708 Segment 2: check if the kernels you build work fine
709 ---------------------------------------------------
717 * Build your own variant of the 'working' kernel and check if the feature that
724 git switch --discard-changes --detach v6.0
726 Now use the checked out code to configure, build, and install another kernel
729 cp ~/kernel-config-working .config
731 make -j $(nproc --all)
733 df -h /boot/ /lib/modules/
735 command -v installkernel && sudo make install
736 make -s kernelrelease | tee -a ~/kernels-built
742 tail -n 1 ~/kernels-built
743 uname -r
753 --------------------------------------------------------
756 to begin the bisection. This will make you build quite a few kernels -- usually
758 (say from 6.0.13 to 6.1.5). But do not worry, due to the trimmed build
777 * Now use the code Git checked out to build, install, and boot a kernel using
780 cp ~/kernel-config-working .config
782 make -j $(nproc --all)
784 df -h /boot/ /lib/modules/
786 command -v installkernel && sudo make install
787 make -s kernelrelease | tee -a ~/kernels-built
793 In case you skipped the 'test latest codebase' step in the guide, check its
794 description as for why the 'df [...]' and 'make -s kernelrelease [...]'
798 identifiers that might look odd or wrong to you -- which they are not, as it's
799 totally normal to see release identifiers like '6.0-rc1-local-gcafec0cacaca0'
812 tail -n 1 ~/kernels-built
813 uname -r
828 find and check out another bisection point for you to test. While doing so, it
829 will print something like 'Bisecting: 675 revisions left to test after this
831 tested. Now build and install another kernel using the instructions from the
834 Repeat this again and again until you finish the bisection -- that's the case
840 alternatively, run ``git bisect log > ~/bisection-log``.
850 git bisect log > ~/bisection-log
851 cp .config ~/bisection-config-culprit
875 git switch --discard-changes --detach linux-6.0.y
880 git switch --discard-changes --detach mainline/master
884 commit-id. To do so, use a command like ``git show abcdcafecabcd`` to
887 'Upstream commit cafec0cacaca0'; use that commit-id in the next command
892 git revert --no-edit cafec0cacaca0
898 cp ~/kernel-config-working .config
899 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
901 Build a kernel using the familiar command sequence, just without copying the
905 make -j $(nproc --all)
907 df -h /boot/ /lib/modules/
909 command -v installkernel && sudo make install
910 make -s kernelrelease | tee -a ~/kernels-built
921 -----------------------------------------------------------
930 identifier. This guide stores them in '~/kernels-built', but the following
933 ls -ltr /lib/modules/*-local*
937 beforehand (e.g. to test the latest codebase and the version considered
938 'good') might become handy to verify something later -- thus better keep them
942 '*6.0-rc1-local-gcafec0cacaca0*', start by removing the directory holding its
945 sudo rm -rf /lib/modules/6.0-rc1-local-gcafec0cacaca0
949 sudo kernel-install -v remove 6.0-rc1-local-gcafec0cacaca0
953 distributions kernel-install does not exist or leaves boot-loader entries or
968 for a while, but safely remove all others with a '-local' in the release
971 * Did the bisection end on a merge-commit or seems questionable for other
984 Optional: test reverts, patches, or later versions
985 --------------------------------------------------
988 test reverts, debug patches, proposed fixes, or other versions. In that case
993 * In case you want to test mainline, fetch its latest changes before checking
997 git switch --discard-changes --detach mainline/master
999 * In case you want to test a stable or longterm kernel, first add the branch
1003 git remote set-branches --add stable linux-6.2.y
1009 git switch --discard-changes --detach stable/linux-6.2.y
1011 * Copy your kernel build configuration over::
1013 cp ~/kernel-config-working .config
1017 * In case you just want to test the latest codebase, head to the next step,
1020 * In case you want to test if a revert fixes an issue, revert one or multiple
1023 git revert --no-edit cafec0cacaca0
1028 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
1030 * In case you want to test a patch, store the patch in a file like
1031 '/tmp/foobars-proposed-fix-v1.patch' and apply it like this::
1033 git apply /tmp/foobars-proposed-fix-v1.patch
1040 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-foobars-fix-v1'
1042 * Build a kernel using the familiar commands, just without copying the kernel
1043 build configuration over, as that has been taken care of already::
1046 make -j $(nproc --all)
1048 df -h /boot/ /lib/modules/
1050 command -v installkernel && sudo make install
1051 make -s kernelrelease | tee -a ~/kernels-built
1061 ----------
1063 You have reached the end of the step-by-step guide.
1071 CCing the Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is
1073 will enable more people to master the task described here -- and hopefully also
1077 Reference section for the step-by-step guide
1081 step-by-step guide.
1084 ------------------------------------------
1091 [:ref:`back to step-by-step guide <introprep_bissbs>`].
1102 -- especially if you fiddle with crucial parts like the kernel of an operating
1106 [:ref:`back to step-by-step guide <backup_bissbs>`]
1121 considered 'vanilla' anymore, as Documentation/admin-guide/reporting-issues.rst
1124 [:ref:`back to step-by-step guide <vanilla_bissbs>`]
1132 ensure the system will permit your self-compiled kernel to boot later.*
1136 they reject booting self-compiled kernels by default.
1138 You ideally deal with this by making your platform trust your self-built kernels
1141 its purpose; 'Documentation/admin-guide/module-signing.rst' and various web
1151 initiate this process by running ``mokutil --disable-validation``; this will
1152 tell you to create a one-time password, which is safe to write down. Now
1153 restart; right after your BIOS performed all self-tests the bootloader Shim will
1157 randomly chosen characters from the one-time password specified earlier. Once
1161 [:ref:`back to step-by-step guide <secureboot_bissbs>`]
1174 [:ref:`back to step-by-step guide <bootworking_bissbs>`]
1192 [:ref:`back to step-by-step guide <diskspace_bissbs>`]
1217 [:ref:`back to step-by-step guide <rangecheck_bissbs>`]
1221 Install build requirements
1224 *Install all software required to build a Linux kernel.*
1227 The kernel is pretty stand-alone, but besides tools like the compiler you will
1228 sometimes need a few libraries to build one. How to install everything needed
1230 about to build.
1237 sudo pacman --needed -S bc binutils bison flex gcc git kmod libelf openssl \
1238 pahole perl zlib ncurses qt6-base
1240 * Debian, Ubuntu, and derivatives::
1242 sudo apt install bc binutils bison dwarves flex gcc git kmod libelf-dev \
1243 libssl-dev make openssl pahole perl-base pkg-config zlib1g-dev \
1244 libncurses-dev qt6-base-dev g++
1255 kernel-install-tools libelf-devel make modutils openssl openssl-devel \
1256 perl-base zlib-devel rpm-build ncurses-devel qt6-base-devel
1260 which you will only need in case you later might want to adjust the kernel build
1265 for tasks not covered in this guide -- for example when building utilities from
1268 [:ref:`back to step-by-step guide <buildrequires_bissbs>`]
1278 The step-by-step guide outlines how to download the Linux sources using a full
1280 that -- but there are two alternatives ways to retrieve the sources that might
1298 wget -c \
1300 git clone --no-checkout clone.bundle ~/linux/
1306 git remote add -t master stable \
1309 In case the 'wget' command fails, just re-execute it, it will pick up where
1312 [:ref:`back to step-by-step guide <sources_bissbs>`]
1322 git clone -o mainline --no-checkout --depth 1 -b master \
1325 git remote add -t master stable \
1330 be the first predecessor and 5.18 the second -- hence deepen the history up to
1333 git fetch --shallow-exclude=v5.18 mainline
1336 branches as explained in the step-by-step guide.
1344 releases (like 6.0-rc2 or 5.19-rc3).
1346 * This document in most places uses ``git fetch`` with ``--shallow-exclude=``
1348 tag). You alternatively can use the parameter ``--shallow-since=`` to specify
1349 an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to
1356 In that case run ``git repack -d`` and try again.
1358 [:ref:`back to step-by-step guide <sources_bissbs>`]
1363 Start defining the build configuration for your kernel
1366 *Start preparing a kernel build configuration (the '.config' file).*
1370 build artifacts. The commands used in this guide store them right in the source
1371 tree to keep things simple. In case you prefer storing the build artifacts
1372 separately, create a directory like '~/linux-builddir/' and add the parameter
1373 ``O=~/linux-builddir/`` to all make calls used throughout this guide. You will
1374 have to point other commands there as well -- among them the ``./scripts/config
1375 [...]`` commands, which will require ``--file ~/linux-builddir/.config`` to
1376 locate the right build configuration.*
1380 * The oldconfig target will use a .config file from your build directory, if
1398 Note, the olddefconfig target will set any undefined build options to their
1408 kernel (say 6.1) on an older mainline release -- especially if it is much older
1414 In case you want to build kernels for another machine, locate its kernel build
1415 configuration; usually ``ls /boot/config-$(uname -r)`` will print its name. Copy
1416 that file to the build machine and store it as ~/linux/.config; afterwards run
1419 [:ref:`back to step-by-step guide <oldconfig_bissbs>`]
1423 Trim the build configuration for your kernel
1429 As explained briefly in the step-by-step guide already: with localmodconfig it
1430 can easily happen that your self-built kernels will lack modules for tasks you
1434 kernel the modules will not have been loaded -- and from localmodconfig's point
1439 additional kernel modules: start a VM, establish VPN connections, loop-mount a
1443 is hard to think of everything that might be needed -- even kernel developers
1452 But if you plan to build and use self-built kernels regularly, you might want to
1454 a few weeks. You can automate this with `modprobed-db
1455 <https://github.com/graysky2/modprobed-db>`_. Afterwards use ``LSMOD=<path>`` to
1456 point localmodconfig to the list of modules modprobed-db noticed being used::
1460 That parameter also allows you to build trimmed kernels for another machine in
1462 run ``lsmod > lsmod_foo-machine`` on that system and copy the generated file to
1463 your build's host home directory. Then run these commands instead of the one the
1464 step-by-step guide mentions::
1466 yes '' | make LSMOD=~/lsmod_foo-machine localmodconfig
1468 [:ref:`back to step-by-step guide <localmodconfig_bissbs>`]
1472 Tag the kernels about to be build
1475 *Ensure all the kernels you will build are clearly identifiable using a
1480 '-local' in the name; it also helps picking the right entry in the boot menu and
1484 [:ref:`back to step-by-step guide <tagging_bissbs>`]
1497 quite a bit of space: in late 2022 the build artifacts for a typical x86 kernel
1510 'Decode failure messages' in Documentation/admin-guide/reporting-issues.rst
1513 [:ref:`back to step-by-step guide <debugsymbols_bissbs>`]
1517 Adjust build configuration
1533 The following sections help you to avoid build problems that are known to occur
1536 **Debian:**
1538 * Remove a stale reference to a certificate file that would cause your build to
1541 ./scripts/config --set-str SYSTEM_TRUSTED_KEYS ''
1544 option point to it, as `the Debian handbook explains in more detail
1545 <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
1546 -- or generate your own, as explained in
1547 Documentation/admin-guide/module-signing.rst.
1549 [:ref:`back to step-by-step guide <configmods_bissbs>`]
1560 to enable or disable certain features using a text-based user interface; to use
1566 [:ref:`back to step-by-step guide <configmods_bissbs>`]
1576 Put the .config you prepared aside, as you want to copy it back to the build
1583 [:ref:`back to step-by-step guide <saveconfig_bissbs>`]
1588 -----------------------------------------------------
1605 build configuration between the 'working' and the 'broken' kernel. This for
1609 do -- in which case your problem from the perspective of the Linux kernel
1611 Documentation/admin-guide/reporting-regressions.rst explains in more detail.
1617 often caused by problems in mainline changes that were backported -- in which
1633 Your report might be ignored if you send it to the wrong party -- and even
1637 [:ref:`back to step-by-step guide <introlatestcheck_bissbs>`]
1648 problem, remember to run that ``git fetch --shallow-exclude [...]`` command
1651 [:ref:`back to step-by-step guide <checkoutmaster_bissbs>`]
1655 Build your kernel
1658 *Build the image and the modules of your first kernel using the config file
1665 Dealing with build errors
1668 When a build error occurs, it might be caused by some aspect of your machine's
1672 which of the two it is. To perform such investigation, restart the build
1678 error. To make it easier to spot, this command also omits the ``-j $(nproc
1679 --all)`` used earlier to utilize every CPU core in the system for the job -- but
1682 After a few seconds the build process should run into the error again. Now try
1684 for the most important and non-generic section of that line (say 4 to 8 words);
1685 avoid or remove anything that looks remotely system-specific, like your username
1703 The step-by-step guide uses the default make targets (e.g. 'bzImage' and
1704 'modules' on x86) to build the image and the modules of your kernel, which later
1705 steps of the guide then install. You instead can also directly build everything
1708 * ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package
1710 * ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package
1712 * ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball
1716 ``make -j $(nproc --all)``, as they will pick up everything already built.
1719 step-by-step guide's instructions on installing and removing your kernel;
1721 (e.g. dpkg and rpm) or a package management utility build on top of them (apt,
1727 [:ref:`back to step-by-step guide <build_bissbs>`]
1736 What you need to do after executing the command in the step-by-step guide
1740 If installkernel is found, the kernel's build system will delegate the actual
1745 image in /boot/, usually as '/boot/vmlinuz-<kernelrelease_id>'; often it will
1746 put a 'System.map-<kernelrelease_id>' alongside it.
1750 '/boot/initramfs-<kernelrelease_id>.img' or
1751 '/boot/initrd-<kernelrelease_id>'. Commodity distributions rely on this file
1764 sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease)
1765 sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease)
1770 [:ref:`back to step-by-step guide <install_bissbs>`]
1782 fill up volumes during a bisection -- and due to that even kernels which used to
1786 Note, most of the time the pattern '/boot/*$(make -s kernelrelease)*' used in
1787 the guide will match all files needed to boot your kernel -- but neither the
1791 [:ref:`back to step-by-step guide <storagespace_bissbs>`]
1802 follow-up errors that look totally unrelated. That is why developers might
1803 ignore or react scantly to reports from tainted kernels -- unless of course the
1807 Documentation/admin-guide/tainted-kernels.rst; doing so is also in your own
1810 [:ref:`back to step-by-step guide <tainted_bissbs>`]
1825 * What you suspected to be a regression was caused by a change in the build
1829 the trimmed build configuration, a different setting for debug symbols, the
1836 [:ref:`back to step-by-step guide <recheckbroken_bissbs>`]
1851 [:ref:`back to step-by-step guide <recheckstablebroken_bissbs>`]
1856 ------------------------------------------------
1858 *Check if the kernels you build work fine.*
1865 That is in your own interest, as trimming the configuration is not foolproof --
1867 starting to suspect something might be wrong with the build configuration.
1871 Many readers of this guide normally run kernels that are patched, use add-on
1872 modules, or both. Those kernels thus are not considered 'vanilla' -- therefore
1881 [:ref:`back to step-by-step guide <introworkingcheck_bissbs>`]
1885 Build your own version of the 'good' kernel
1888 *Build your own variant of the working kernel and check if the feature that
1892 self-built kernel, find and resolve the cause before moving on. There are a
1899 test the feature? Then you might want to recreate a .config file based on the
1901 some features in the .config might work as well to reduce the build time.
1911 to build another kernel from the latest codebase, as your earlier tests with
1915 [:ref:`back to step-by-step guide <recheckworking_bissbs>`]
1918 -------------------------------------------
1925 [:ref:`back to step-by-step guide <introbisect_bissbs>`].
1936 check out a commit round about half-way between the 'good' and the 'bad' changes
1937 for you to test.
1939 [:ref:`back to step-by-step guide <bisectstart_bissbs>`]
1943 Build a kernel from the bisection point
1946 *Build, install, and boot a kernel from the code Git checked out using the
1962 base them on a somewhat earlier point like 6.1-rc1 or even 6.0 -- and then
1967 [:ref:`back to step-by-step guide <bisectbuild_bissbs>`]
1981 [:ref:`back to step-by-step guide <bisecttest_bissbs>`]
1994 allow someone to point out where a bisection likely went sideways -- and then
1995 instead of testing ten or more kernels you might only have to build a few to
2001 [:ref:`back to step-by-step guide <bisectlog_bissbs>`]
2016 The step-by-step guide covers everything relevant already except one slightly
2019 try to revert the culprit in the affected stable/longterm series -- and if that
2020 succeeds, test that kernel version instead.
2022 [:ref:`back to step-by-step guide <revert_bissbs>`]
2025 ---------------------------------------------------
2030 The steps in this section describe clean-up procedures.
2032 [:ref:`back to step-by-step guide <introclosure_bissbs>`].
2057 some distributions the ``kernel-install remove...`` command mentioned in the
2058 step-by-step guide will delete all of these files for you while also removing
2062 '6.0-rc1-local-gcafec0cacaca0'::
2064 rm -i /boot/{System.map,vmlinuz,initr}-6.0-rc1-local-gcafec0cacaca0
2067 '6.0-rc1-local-gcafec0cacaca0' in their name and consider deleting them as well.
2075 [:ref:`back to step-by-step guide <makeroom_bissbs>`]
2087 the step-by-step guide might not free as much space as you would like. In that
2088 case consider running ``rm -rf ~/linux/*`` as well now. This will remove the
2089 build artifacts and the Linux sources, but will leave the Git repository
2090 (~/linux/.git/) behind -- a simple ``git reset --hard`` thus will bring the
2094 is a decent chance developers will ask you to build another kernel to
2095 perform additional tests -- like testing a debug patch or a proposed fix.
2097 tasks: test reverts, patches, or later versions <introoptional_bissbs>`.
2100 ~/kernel-config-working file around for a few weeks.
2102 [:ref:`back to step-by-step guide <finishingtouch_bissbs>`]
2106 Test reverts, patches, or later versions
2107 ----------------------------------------
2110 to test reverts, patches, proposed fixes, or other versions.*
2118 [:ref:`back to step-by-step guide <introoptional_bissbs>`].
2126 Build kernels on a different machine
2127 ------------------------------------
2129 To compile kernels on another system, slightly alter the step-by-step guide's
2132 * Start following the guide on the machine where you want to install and test
2137 modules to a file using ``lsmod > ~/test-machine-lsmod``. Then locate the
2138 build configuration for the running kernel (see ':ref:`Start defining the
2139 build configuration for your kernel <oldconfig_bisref>`' for hints on where
2140 to find it) and store it as '~/test-machine-config-working'. Transfer both
2141 files to the home directory of your build host.
2143 * Continue the guide on the build host (e.g. with ':ref:`Ensure to have enough
2146 * When you reach ':ref:`Start preparing a kernel build configuration[...]
2149 test machine's 'working' kernel::
2151 cp ~/test-machine-config-working ~/linux/.config
2156 yes '' | make localmodconfig LSMOD=~/lsmod_foo-machine localmodconfig
2159 install, and reboot into a kernel every time they come up. Instead build
2162 cp ~/kernel-config-working .config
2164 make -j $(nproc --all) targz-pkg
2168 '6.0.0-rc1-local-g928a87efa423' built for x86 machines usually will
2169 be stored as '~/linux/linux-6.0.0-rc1-local-g928a87efa423-x86.tar.gz'.
2171 Copy that file to your test machine's home directory.
2173 * Switch to the test machine to check if you have enough space to hold another
2176 sudo tar -xvzf ~/linux-6.0.0-rc1-local-g928a87efa423-x86.tar.gz -C /
2182 … sudo /sbin/installkernel 6.0.0-rc1-local-g928a87efa423 /boot/vmlinuz-6.0.0-rc1-local-g928a87efa423
2187 cross-compilers and add the appropriate parameters to every invocation of make
2188 (e.g. ``make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- [...]``).
2191 ---------------------------
2193 * The `man page for 'git bisect' <https://git-scm.com/docs/git-bisect>`_ and
2194 `fighting regressions with 'git bisect' <https://git-scm.com/docs/git-bisect-lk2009.html>`_
2196 * `Working with git bisect <https://nathanchance.dev/posts/working-with-git-bisect/>`_
2202 end-of-content
2207 want to contribute changes to the text -- but for copyright reasons please CC
2208 linux-doc@vger.kernel.org and 'sign-off' your contribution as
2209 Documentation/process/submitting-patches.rst explains in the section 'Sign
2210 your work - the Developer's Certificate of Origin'.
2212 This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
2213 of the file. If you want to distribute this text under CC-BY-4.0 only,
2216 …linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/verify-bugs-and-bisect-regress…
2220 is available under CC-BY-4.0, as versions of this text that were processed
2221 (for example by the kernel's build system) might contain content taken from