summaryrefslogtreecommitdiffstats
path: root/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
Commit message (Collapse)AuthorAgeFilesLines
* docs: verify/bisect: remove a level of indentingThorsten Leemhuis2024-03-181-57/+57
| | | | | | | | | Remove a unnecessary level of indenting in some areas of the reference section. No text changes. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <01f1a407e92b92d9f8614bd34882956694bab123.1710750972.git.linux@leemhuis.info>
* docs: verify/bisect: drop 'v' prefix, EOL aspect, and assorted fixesThorsten Leemhuis2024-03-181-55/+62
| | | | | | | | | | | | | | | A bunch of minor fixes and improvements and two other things: - Explain the 'v' version prefix when it's first used, but drop it everywhere in the text for consistency. Also drop single quotes around a few version numbers. - Point out that testing a stable/longterm kernel only makes sense if the series is still supported. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <f13d203d5975419608996300992eaa2e4fcc2dc1.1710750972.git.linux@leemhuis.info>
* docs: verify/bisect: check taint flagThorsten Leemhuis2024-03-181-15/+49
| | | | | | | | | Instruct readers to check the taint flag, as the reason why it's set might directly or indirectly cause the bug or interfere with testing. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <8fcaffa8e85f36d51178d61061355c3c8bc85a0f.1710750972.git.linux@leemhuis.info>
* docs: verify/bisect: improve install instructionsThorsten Leemhuis2024-03-181-65/+57
| | | | | | | | | | | | These changes among others ensure modules will be installed when /sbin/installkernel is missing. Furthermore describe better what tasks the script ideally performs so that users can more easily check if those have been taken care of. In addition to that point to the distro's documentation for further details on installing kernels manually. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <e392bd5eb12654bed635f32b24304a712b0c67d1.1710750972.git.linux@leemhuis.info>
* docs: verify/bisect: fixes, finetuning, and support for ArchThorsten Leemhuis2024-03-071-51/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assorted changes for the recently added document. Improvements: * Add instructions for installing required software on Arch Linux. Fixes: * Move a 'git remote add -t master stable [...]' from a totally wrong to the right place. * Fix two anchors. * Add two required packages to the openSUSE install instructions. Fine tuning: * Improve the reference section about downloading Linux mainline sources to make it more obvious that those are alternatives. * Include the full instructions for git bundles to ensure the remote gets the right name; that way the text also works stand alone. * Install ncurses and qt headers for use of menuconfig and xconfig by default, but tell users that they are free to omit them. * Mention ahead of time which version number are meant as example in commands used during the step-by-step guide. * Mention that 'kernel-install remove' might do a incomplete job. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <6592c9ef4244faa484b4113f088dbc1beca61015.1709716794.git.linux@leemhuis.info>
* docs: new text on bisecting which also covers bug validationThorsten Leemhuis2024-03-031-0/+1919
Add a second document on bisecting regressions explaining the whole process from beginning to end -- while also describing how to validate if a problem is still present in mainline. This "two in one" approach is possible, as checking whenever a bug is in mainline is one of the first steps before performing a bisection anyway and thus needs to be described. Due to this approach the text also works quite nicely in conjunction with Documentation/admin-guide/reporting-issues.rst, as it covers all typical cases where users will need to build a kernel in exactly the same order. The text targets users that normally run kernels from their Linux distributor who might never have compiled their own kernel. This aim is why the first kernel built while following this guide is generated from the latest mainline codebase. This will rule out that the regression (a) was fixed already and (b) is caused by config change a vendor distributor performed; checking mainline will furthermore (c) determine if the issue is something that needs to be reported to the regular developers or the stable team (this is needed even when readers bisect within a stable series). Only then are readers instructed to build their own variant of the 'good' kernel to validate the trimmed .config file created during early in the guide, as performing a bisection with a broken one would be a waste of time. There is a small downside of this order: readers might have to go back to testing mainline, if it turns out there is a problem with their .config. But that should be rare -- and if the regression was already fixed readers might not get to this point anyway. Hence in the end this order should mean that readers built less kernels overall. This sequence allows the text to easily cover the "check if a bug is present in the upstream kernel" case while only making things a tiny bit more complicated. The text tries to prevent readers from running into many mistakes users are known to frequently make. The steps required for this might look superfluous for people that are already familiar with bisections -- but anyone with that knowledge should be able to adapt the instructions to their use-case or will not need this text at all. Style and structure of the text match the one Documentation/admin-guide/quickly-build-trimmed-linux.rst uses. Quite a few paragraphs are even copied from there and not changed at all or only slightly. This will complicate maintenance, as some future changes to one of these documents will have to be replicated in the other. But this is the lesser evil: solutions like "sending readers from one document over to the other" or "extracting the common parts into a separate document" might work in other cases, but would be too confusing here given the topic and the target audience. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> [jc: Undo spurious removal of subsection header line] Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <02b084a06de4ad61ac4ecd92b9265d4df4d03d71.1709282441.git.linux@leemhuis.info>