Lines Matching +full:fails +full:- +full:without +full:- +full:test +full:- +full:cd
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
55 # * Ensure Secure Boot permits booting self-compiled Linux kernels.
59 git clone -o mainline --no-checkout \
61 cd ~/linux/
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
79 cp .config ~/kernel-config-working
89 cd ~/linux/
90 git switch --discard-changes --detach mainline/master
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
127 cd ~/linux/
128 git switch --discard-changes --detach v6.0
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
146 cd ~/linux/
154 In case building or booting the kernel fails for unrelated reasons, run
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
168 cd ~/linux/
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'
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* --
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
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.
275 ---------------------------------------------------------
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'.
386 git clone -o mainline --no-checkout \
388 cd ~/linux/
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
409 identifier using ``uname -r``.
416 git switch --discard-changes --detach v6.0
430 the .config file for your running kernel -- in which case you have to put one
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
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
527 cp .config ~/kernel-config-working
534 ----------------------------------------------------------------
547 lists a release from that series without an '[EOL]' tag, checkout the series
548 latest version ('linux-6.1.y' in the following example)::
550 cd ~/linux/
551 git switch --discard-changes --detach stable/linux-6.1.y
555 linux-6.2.y) or mainline (see next point) fix the bug.
559 cd ~/linux/
560 git switch --discard-changes --detach mainline/master
569 cp ~/kernel-config-working .config
571 make -j $(nproc --all)
585 df -h /boot/ /lib/modules/
594 command -v installkernel && sudo make install
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::
669 cd ~/linux/
670 git switch --discard-changes --detach mainline/master
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.
709 ---------------------------------------------------
723 cd ~/linux/
724 git switch --discard-changes --detach v6.0
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
768 cd ~/linux/
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
790 If compilation fails for some reason, run ``git bisect skip`` and restart
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'
811 cd ~/linux/
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
834 Repeat this again and again until you finish the bisection -- that's the case
840 alternatively, run ``git bisect log > ~/bisection-log``.
849 cd ~/linux/
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
894 If that fails, give up trying and move on to the next step; if it works,
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
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
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>`]
1227 The kernel is pretty stand-alone, but besides tools like the compiler you will
1237 sudo pacman --needed -S bc binutils bison flex gcc git kmod libelf openssl \
1238 pahole perl zlib ncurses qt6-base
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
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/
1301 cd ~/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 \
1324 cd ~/linux/
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>`]
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
1408 kernel (say 6.1) on an older mainline release -- especially if it is much older
1415 configuration; usually ``ls /boot/config-$(uname -r)`` will print its name. Copy
1419 [:ref:`back to step-by-step guide <oldconfig_bissbs>`]
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 localmodonfig's point
1439 additional kernel modules: start a VM, establish VPN connections, loop-mount a
1440 CD/DVD ISO, mount network shares (CIFS, NFS, ...), and connect all external
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::
1462 run ``lsmod > lsmod_foo-machine`` on that system and copy the generated file to
1464 step-by-step guide mentions::
1466 yes '' | make LSMOD=~/lsmod_foo-machine localmodconfig
1468 [:ref:`back to step-by-step guide <localmodconfig_bissbs>`]
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>`]
1510 'Decode failure messages' in Documentation/admin-guide/reporting-issues.rst
1513 [:ref:`back to step-by-step guide <debugsymbols_bissbs>`]
1541 ./scripts/config --set-str SYSTEM_TRUSTED_KEYS ''
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>`]
1583 [:ref:`back to step-by-step guide <saveconfig_bissbs>`]
1588 -----------------------------------------------------
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>`]
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
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
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;
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
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>`]
1836 [:ref:`back to step-by-step guide <recheckbroken_bissbs>`]
1851 [:ref:`back to step-by-step guide <recheckstablebroken_bissbs>`]
1856 ------------------------------------------------
1865 That is in your own interest, as trimming the configuration is not foolproof --
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>`]
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
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>`]
1962 base them on a somewhat earlier point like 6.1-rc1 or even 6.0 -- and then
1963 get merged for 6.2 without rebasing nor squashing them once 6.1 is out. This
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
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
2090 (~/linux/.git/) behind -- a simple ``git reset --hard`` thus will bring the
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>`].
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
2140 to find it) and store it as '~/test-machine-config-working'. Transfer both
2149 test machine's 'working' kernel::
2151 cp ~/test-machine-config-working ~/linux/.config
2156 yes '' | make localmodconfig LSMOD=~/lsmod_foo-machine localmodconfig
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