Lines Matching +full:check +full:- +full:system +full:- +full:opensuse
1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
22 issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
24 mailing list in CC. Check the destination's archives for matching reports;
32 check if backporting is in the works or was discarded; if it's neither, ask
36 ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
44 to pin-point the culprit with a bisection; if you succeed, include its
45 commit-id and CC everyone in the sign-off-by chain.
51 Step-by-step guide how to report issues to the kernel maintainers
58 step-by-step approach. It still tries to be brief for readability and leaves
59 out a lot of details; those are described below the step-by-step guide in a
75 search engine; additionally, check the archives of the `Linux Kernel Mailing
86 * Create a fresh backup and put system repair and restore tools at hand.
88 * Ensure your system does not enhance its kernels by building additional
89 kernel modules on-the-fly, which solutions like DKMS might be doing locally
92 * Check if your kernel was 'tainted' when the issue occurred, as the event
97 work independently on a freshly booted system. That's needed, as each issue
169 --------------------------------------------------------------
178 * Check if the kernel developers still maintain the Linux kernel version
183 * Check the archives of the `Linux stable mailing list
189 problem with a vendor kernel, check a vanilla build of the last version
204 -------------------------------------------------------------
218 * Search the Linux kernel version control system for the change that fixed
222 or peer-review possible fixes; then check the discussions if the fix was
268 <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to ask good
269 questions <https://jvns.ca/blog/good-questions/>`_.
276 ------------------------------------------------
288 sides. That's because almost all Linux-based kernels pre-installed on devices
316 regular Fedora releases, and openSUSE Tumbleweed. But keep in mind, you better
329 --------------------------------------
332 search engine; additionally, check the archives of the Linux Kernel Mailing
338 interest to thoroughly check if somebody reported the issue already. At this
370 reports in different places, as described below in the section "Check where you
372 thus might not even be aware of the bugzilla ticket. Hence, check the ticket if
378 -----------------------
392 Documentation/admin-guide/reporting-regressions.rst explains this in more
398 Documentation/process/security-bugs.rst before proceeding, as it
411 ----------------------------
432 * If you're dealing with a filesystem issue, you might want to check the file
433 system in question with ``fsck``, as it might be damaged in a way that leads
446 -----------------------
448 *Create a fresh backup and put system repair and restore tools at hand.*
452 system. That's what you are about to do in this process. Thus, make sure to
454 reinstall the operating system as well as everything you need to restore the
459 ------------------------------------------
461 *Ensure your system does not enhance its kernels by building additional
462 kernel modules on-the-fly, which solutions like DKMS might be doing locally
467 mechanisms like akmods and DKMS: those build add-on kernel modules
472 Note, you might not be aware that your system is using one of these solutions:
479 Check 'taint' flag
480 ------------------
482 *Check if your kernel was 'tainted' when the issue occurred, as the event
486 lead to follow-up errors that look totally unrelated. The issue you face might
490 install the latest mainline kernel; you will need to check the taint flag again
494 On a running system is easy to check if the kernel tainted itself: if ``cat
499 non-recoverable error before halting operation (a 'kernel panic'). Look near
505 If your kernel is tainted, study Documentation/admin-guide/tainted-kernels.rst
511 point. In that case check your kernel or system log and look for a section
516 That's the first Oops since boot-up, as the '#1' between the brackets shows.
518 follow-up problem to that first Oops, even if both look totally unrelated.
526 2. Your system uses a software that installs its own kernel modules, for
548 -------------------------------
552 work independently on a freshly booted system. That's needed, as each issue
564 you know exactly how to reproduce an issue quickly on a freshly booted system.
569 to ignore this advice if you are experienced enough to tell a one-time error
575 ----------------------------------------
590 Check where you need to report your issue
591 -----------------------------------------
621 Sadly, there is no way to check which code is driving a particular hardware
625 the output of ``lspci -k``, as it lists devices on the PCI/PCIe bus and the
628 [user@something ~]$ lspci -k
637 other internal bus. In those cases you might want to check your WiFi manager or
642 …[user@something ~]$ realpath --relative-to=/sys/module/ /sys/class/net/wlp58s0/device/driver/module
660 Web-page: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
689 (LKML) <linux-kernel@vger.kernel.org> to CC. Don't omit either of the mailing
709 $ ./scripts/get_maintainer.pl -f drivers/net/wireless/ath/ath10k*
713 linux-wireless@vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS))
715 linux-kernel@vger.kernel.org (open list)
721 'ath10k@lists.infradead.org' and 'linux-kernel@vger.kernel.org' in CC.
724 ``get_maintainer.pl`` a second time with ``--git``. The script then will look
729 modified during tree-wide cleanups by developers that do not care about the
734 ---------------------------------------
758 It's also wise to check the internet, LKML and maybe bugzilla.kernel.org again
760 to check the mailing list archives for the subsystem as well, as someone might
771 ----------------------------------
799 It also outlines that using a pre-compiled kernel are fine, but better are
809 mainline, which most of the time will point to a pre-release with a version
810 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
817 suspending the reporting process until the first pre-release of the next
818 version (5.8-rc1) shows up on kernel.org. That's because the Linux development
819 cycle then is in its two-week long 'merge window'. The bulk of the changes and
853 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
855 problem: most of those shipped by distributors or add-on repositories are build
871 document. Also be aware that pre-compiled kernels might lack debug symbols that
881 Those are likely a bit ahead of the latest mainline pre-release. Don't worry
882 about it: they are as reliable as a proper pre-release, unless the kernel's
891 those how-to's that suggest to use ``make localmodconfig``, as that tries to
893 somewhat for your system. That does not make the resulting kernel any better,
910 Check 'taint' flag
911 ------------------
917 something happens that can lead to follow-up errors that look totally
918 unrelated. That's why you need to check if the kernel you just installed does
925 -------------------------------------
931 Check if the issue occurs with the fresh Linux kernel version you just
942 ---------------------------------------
961 -----------------------
978 …[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux
985 [user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh \
986 /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/
995 …[ 68.387301] RIP: 0010:test_module_init (/home/username/linux-5.10.5/test-module/test-module.c:1…
998 '~/linux-5.10.5/test-module/test-module.c' and the error occurred by the
1015 ----------------------------
1031 Documentation/admin-guide/bug-bisect.rst describes in detail. That process
1036 code management system that's causing the regression. Once you find it, search
1041 Note, a bisection needs a bit of know-how, which not everyone has, and quite a
1047 5.7 and 5.8) to check when it first showed up. Unless you're trying to find a
1063 Documentation/admin-guide/reporting-regressions.rst; that document also
1069 -------------------------
1098 and write the detailed report first. ;-)
1104 installed. Try to include the step-by-step instructions you wrote and optimized
1117 "Operating System"``)
1119 * the architecture of the CPU and the operating system (``uname -mi``)
1122 subject and the commit-id of the change that is causing it.
1130 sure that it starts with a line like 'Linux version 5.8-1
1134 ``journalctl -b 0 -k``; alternatively you can also reboot, reproduce the
1152 went out. ;-)
1165 of system you use. If you for example have problems with your graphics card,
1179 libdrm and Mesa; also specify your Wayland compositor or the X-Server and
1181 corresponding filesystem utilities (e2fsprogs, btrfs-progs, xfsprogs, ...).
1184 output from ``lspci -nn`` will for example help others to identify what
1186 make the output from ``sudo lspci -vvv`` available, as that provides
1191 information. One such tool is ``alsa-info.sh`` `which the audio/sound
1192 subsystem developers provide <https://www.alsa-project.org/wiki/AlsaInfo>`_.
1239 and the oldest where the issue occurs (say 5.8-rc1).
1249 author of the culprit to the recipients; also CC everyone in the signed-off-by
1253 short-term risk to other users would arise if details were publicly disclosed.
1272 See Documentation/process/security-bugs.rst for more information.
1276 --------------------------------
1304 mailed reports always use the 'Reply-all' function when replying to any mails
1306 to your report: go to your mail applications 'Sent' folder and use 'reply-all'
1312 There are just two situations where a comment in a bug tracker or a 'Reply-all'
1356 **Proactive testing**: Every time the first pre-release (the 'rc1') of a new
1357 mainline kernel version gets released, go and check if the issue is fixed there
1375 **Check who you deal with**: Most of the time it will be the maintainer or a
1431 mail is shortly after the first pre-release (the 'rc1') of a new Linux kernel
1436 contact a higher-level maintainer asking for advice: even busy maintainers by
1465 ------------------------------------------------------------------------------
1473 *Check if the kernel developers still maintain the Linux kernel version
1481 need to check if the kernel developers still support the version line you care
1486 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
1494 *Check the archives of the Linux stable mailing list for existing reports.*
1508 problem with a vendor kernel, check a vanilla build of the last version
1511 Before investing any more time in this process you want to check if the issue
1519 a recheck. Say something broke when you updated from 5.10.4-vendor.42 to
1520 5.10.5-vendor.43. Then after testing the latest 5.10 release as outlined in
1521 the previous paragraph check if a vanilla build of Linux 5.10.4 works fine as
1523 regression and you need switch back to the main step-by-step guide to report
1548 instructed above go and check the latest kernel from that version line, say
1560 the document Documentation/admin-guide/bug-bisect.rst for details how to
1562 the recipients; also CC everyone in the signed-off-by chain, which you find at
1567 -----------------------------------------------------------------------------
1580 Even small and seemingly obvious code-changes sometimes introduce new and
1583 within rules outlined in Documentation/process/stable-kernel-rules.rst.
1602 * Check if the kernel developers still maintain the Linux kernel version line
1607 * Check with the latest release.
1610 Check code history and search for existing discussions
1613 *Search the Linux kernel version control system for the change that fixed
1617 or peer-review possible fixes; then check the discussions if the fix was
1631 log --grep=<pattern>``.
1650 * If you see a proposed fix, search for it in the version control system as
1653 * Check the discussions for any indicators the fix might be too risky to get
1690 hardware usable on their favorite operating system.
1745 end-of-content
1751 linux-doc@vger.kernel.org and "sign-off" your contribution as
1752 Documentation/process/submitting-patches.rst outlines in the section "Sign
1753 your work - the Developer's Certificate of Origin".
1755 This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
1756 of the file. If you want to distribute this text under CC-BY-4.0 only,
1759 …rg/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
1762 is available under CC-BY-4.0, as versions of this text that were processed
1763 (for example by the kernel's build system) might contain content taken from