Lines Matching full:your
36 aspects, all of which might be essential in your present case.]*
51 * **Preparations**: set up everything to build your own kernels::
58 # * Ensure to have 15 Gigabyte free space in your home directory.
104 # * Check how much space your self-built kernel actually needs, which
139 a) Retrieve the sources for your 'bad' version::
166 d) Once your finished the bisection, put a few things away::
225 This guide describes how to set up your own Linux kernels for investigating bugs
227 depends on your issue:
229 Execute all steps till the end of *segment 1* to **verify if your kernel problem
232 as then your want to at least continue with *segment 2* to **check if the issue
235 report; instead of the latter your could also head straight on and follow
239 :ref:`Preparations: set up everything to build your own kernels <introprep_bissbs>`.
274 Preparations: set up everything to build your own kernels
301 ensure the system will permit your self-compiled kernel to boot. The
325 mainline release your working kernel is based on to be the 'good'
353 * Ensure to have enough free space for building Linux. 15 Gigabyte in your home
428 of your currently working kernel. If the line instead continues with something
430 the .config file for your running kernel -- in which case you have to put one
443 * Disable any kernel modules apparently superfluous for your setup. This is
446 previous step was already tailored to your and your hardware needs, in which
452 trouble since you started the system. Only then trim your .config::
515 your preferred tool. Note, to use make targets like 'menuconfig' or
545 * Are your 'good' and 'bad' versions from the same stable or longterm series?
553 Your series is unsupported, if is not listed or carrying a 'end of life'
566 * Build the image and the modules of your first kernel using the config file you
573 If you want your kernel packaged up as deb, rpm, or tar file, see the
581 * Install your newly built kernel.
588 much your kernels actually require will be determined later during this guide.
591 parallel to the your Linux distribution's kernels::
604 that; your distribution's documentation might help, too.
634 * Reboot into your newly built kernel. To ensure your actually started the one
648 for this might interfere with your testing.
654 * Verify if your bug occurs with the newly built kernel. If it does not, check
656 during your tests.
717 * Build your own variant of the 'working' kernel and check if the feature that
838 description of the change. The latter might fill your terminal screen, so you
858 * Try reverting the culprit on top of latest mainline to see if this fixes your
991 * Update your Git clone and check out the latest code.
1011 * Copy your kernel build configuration over::
1015 * Your next step depends on what you want to do:
1083 Preparations for building your own kernels
1132 ensure the system will permit your self-compiled kernel to boot later.*
1138 You ideally deal with this by making your platform trust your self-built kernels
1144 Temporarily disabling solutions like Secure Boot is another way to make your own
1150 disable all Secure Boot restrictions for your Linux environment. You can
1153 restart; right after your BIOS performed all self-tests the bootloader Shim will
1229 depends on your Linux distribution and the configuration of the kernel you are
1328 Now deepen your clone's history to the second predecessor of the mainline
1329 release of your 'good' version. In case the latter are 6.0 or 6.0.13, 5.19 would
1352 the release of the mainline release your 'good' kernel is based on.
1354 * Be warned, when deepening your clone you might encounter an error like
1363 Start defining the build configuration for your kernel
1380 * The oldconfig target will use a .config file from your build directory, if
1387 * Sometimes olddefconfig is unable to locate the .config file for your running
1389 check if your distribution ships the configuration somewhere and manually put
1423 Trim the build configuration for your kernel
1426 *Disable any kernel modules apparently superfluous for your setup.*
1430 can easily happen that your self-built kernels will lack modules for tasks you
1433 it for the first time. So when you never performed that task since starting your
1453 reduce the risk by recording which modules your system loads over the course of
1463 your build's host home directory. Then run these commands instead of the one the
1478 This allows you to differentiate your distribution's kernels from those created
1493 Having debug symbols available can be important when your kernel throws a
1523 Depending on your needs you at this point might want or have to adjust some
1538 * Remove a stale reference to a certificate file that would cause your build to
1546 -- or generate your own, as explained in
1580 confuse testing or in some cases render the result of your bisection
1594 point, especially if you did that already with a kernel prepared by your
1598 * You will run into any problems caused by your setup before you actually begin
1604 * These steps will rule out if your problem is caused by some change in the
1606 example can happen when your distributor enabled an additional security
1609 do -- in which case your problem from the perspective of the Linux kernel
1612 You thus would waste your time if you'd try to bisect this.
1614 * If the cause for your regression was already fixed in the latest mainline
1633 Your report might be ignored if you send it to the wrong party -- and even
1649 again mentioned earlier to update your local Git repository.
1655 Build your kernel
1658 *Build the image and the modules of your first kernel using the config file
1662 yourself. Another subsection explains how to directly package your kernel up as
1668 When a build error occurs, it might be caused by some aspect of your machine's
1685 avoid or remove anything that looks remotely system-specific, like your username
1686 or local path names like ``/home/username/linux/``. First try your regular
1691 often one of the hits will provide a solution for your problem, too. If you
1692 do not find anything that matches your problem, try again from a different angle
1693 by modifying your search terms or using another line from the error messages.
1696 reported by others already. That includes issues where the cause is not your
1698 a solution (e.g. a patch) or workaround for your issue, too.
1700 Package your kernel up
1704 'modules' on x86) to build the image and the modules of your kernel, which later
1719 step-by-step guide's instructions on installing and removing your kernel;
1724 those formats, they thus will sometimes behave differently than your
1738 executable on your distribution.
1741 installation of your kernel image to this executable, which then performs some
1744 * On almost all Linux distributions installkernel will store your kernel's
1753 as your distribution's initramfs generator otherwise will be unable to find
1756 * On some distributions installkernel will then add an entry for your kernel
1757 to your bootloader's configuration.
1759 You have to take care of some or all of the tasks yourself, if your
1767 Now generate your initramfs using the tools your distribution provides for this
1768 process. Afterwards add your kernel to your bootloader configuration and reboot.
1787 the guide will match all files needed to boot your kernel -- but neither the
1795 Check if your newly built kernel considers itself 'tainted'
1807 Documentation/admin-guide/tainted-kernels.rst; doing so is also in your own
1808 interest, as your testing might be flawed otherwise.
1817 *Verify if your bug occurs with the newly built kernel.*
1820 There are a couple of reasons why your bug or regression might not show up with
1826 configuration the provider of your kernel carried out.
1828 * Your problem might be a race condition that does not show up with your kernel;
1865 That is in your own interest, as trimming the configuration is not foolproof --
1885 Build your own version of the 'good' kernel
1888 *Build your own variant of the working kernel and check if the feature that
1891 In case the feature that broke with newer kernels does not work with your first
1907 * Maybe it was a feature added to your distributor's kernel which vanilla Linux
1911 to build another kernel from the latest codebase, as your earlier tests with
2009 your regression.* [:ref:`... <revert_bissbs>`]
2044 need to worry to mess up your machine when you install a kernel manually (and
2045 thus bypass your distribution's packaging system): all parts of your kernels are
2056 your distribution's installkernel executable and its initramfs generator. On
2059 the menu entry for the kernel from your bootloader configuration. On others you
2068 Now remove the boot entry for the kernel from your bootloader's configuration;
2139 build configuration for your kernel <oldconfig_bisref>`' for hints on where
2141 files to the home directory of your build host.
2148 execute the following command to base your configuration on the one from the
2171 Copy that file to your test machine's home directory.
2178 Afterwards :ref:`generate the initramfs and add the kernel to your boot
2208 linux-doc@vger.kernel.org and 'sign-off' your contribution as
2210 your work - the Developer's Certificate of Origin'.