Bug#1041142: closed by Diederik de Haas (Re: Debian's BTS is not for regular user questions)
On 01.08.23 21:08, AlMa wrote: This is a rather naive understanding of how logging is done in practice. The reality is that developers often don't know (and maybe can't know) just how severe an odd condition may be in practice. Unfortunately, neither do I. Though seemingly unrelated journal-visible issues are quite often indeed independent, sometimes unexpected interactions or common root causes occur. Perhaps, there should be a category for tentative errors and/or tentative warnings (i.e., with an unknown (or yet unknown) severity in practice). E.g., dereferencing a zero pointer, or division by zero, or garbled screen output, or the inability to read '/' as the root user, etc. are almost always errors (except when you test error-handling routes themselves; then a division by zero is not a bug but a must). If you say that it is unknown how severe a message such as “ACPI Warning: SystemIO range … conflicts with OpRegion … . lpc_ich: Resource conflict(s) found affecting gpio_ich” really is, it should not be a warning (especially, it should not warn the reader) but be a tentative warning (i.e., it might warn the reader in the future or under particular circumstances). The (new?) colors of the tentative errors and warnings should be clearly stated in the manpages of journalctl.
Bug#1041142: closed by Diederik de Haas (Re: Debian's BTS is not for regular user questions)
This is a rather naive understanding of how logging is done in practice. The reality is that developers often don't know (and maybe can't know) just how severe an odd condition may be in practice. Unfortunately, neither do I. Though seemingly unrelated journal-visible issues are quite often indeed independent, sometimes unexpected interactions or common root causes occur. If there is still an actual problem on this machine (not just warning messages), please open *1* bug report that describes the actual problem and the log messages. If under *actual* you mean *user-disturbing* (“error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways”, a definition from Wikipedia), I've got none for the kernel because the kernel is not visible (nor should it be visible) to users directly. The only (sometimes reproducible) full lock-up (SysRq doesn't seem to work) I saw myself, which might concern the kernel, happened when epiphany-browser loads Google maps directly or embedded into a different Web site; I plan to submit a bug report. As for other high-level problems which are already posted, there are at least two (and more are likely to come). One of them, already resolved recently (though the root cause is still unknown, the intermediate problem is gone) is #1041014. If I had to state the *actual* problem there, it would have been „the machine doesn't boot properly, the screen is black, the keyboard doesn't seem to respond“; such a description would've probably been considered *actual* but pretty useless to the maintainers. Even if it would have been useful to you, then only in the sense that a failure to start a graphical user interface should not prevent text logins from visibly showing up on Ctrl + Alt + F1 … Ctrl + Alt + F6 and that error codes (instead of "ERRNO" and "exit-code") from failed spawns by systemd should be printed. As another big problem on another machine, cf. #1040497. A next step in debugging this could be looking at how /run/gdm3/custom.conf is created, whether the logic in /lib/udev/rules.d/61-gdm.rules is correct, and whether using X.Org (in Debian 12) instead of Wayland (in Debian 11) is really justified on the particular machine (https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/171#note_1403697 doesn't apply in my use case because the onboard graphics chip is usually not connected to a monitor in my setup, except if the monitor connected to the PCIe NVIDIA card happens to fail, which has not yet happened). If this issue involves the kernel at all, then probably the nouveau driver. The details of this issue are beyond my level of expertise, so I'm unsure how much I can really do myself. Gratefully, Alma
Bug#1041142: closed by Diederik de Haas (Re: Debian's BTS is not for regular user questions)
On Tue, 2023-08-01 at 02:49 +0200, AlMa wrote: > On 01.08.23 01:12, Debian Bug Tracking System wrote: > > You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile > > Precision M6700 ... and not once did you say what actual problem you > > experienced?!? > > That's wrong. > Before I posted some (not all) of the bug reports, the Dell laptop > stopped booting properly rather early; the root cause is still unknown > (though an intermediate cause is finally resolved now, the bug report is > already closed). It took me a bit to get a working console, a mouse and > network going so as to simply be able to start debugging. Some other > machines I manage had (and still have) other, less severe symptoms, > e.g., Wayland and programs depending on Wayland (e.g., “foot”) failing > to start after Debian upgrade. > > If your computer doesn't boot properly, you go one by one through every > suspicious message you find. The fact that some messages are shown as > warnings and others as errors is clearly meant to warn whoever reads > them (i.e., the admin) and make him/her concerned. By the definition of > the terms “warning” and “error”! This is a rather naive understanding of how logging is done in practice. The reality is that developers often don't know (and maybe can't know) just how severe an odd condition may be in practice. > If these messages shouldn't make the > admin concerned, well, then the journalctl shouldn't show these messages > as warnings (AFAIK, yellow) and errors (red according to `man > journalctl`). Please don't try to unload on me because of this mess; > I'm just an admin, and not even a developer. > > Therefore, please restore the bug reports you closed. I agree with Diederik's closing these bug reports. We as kernel maintainers have limited time and resources for investigating bugs, and we are certainly not able to provide individual support for users and administrators. Investigating warning messages one by one is not a priority at all. If there is still an actual problem on this machine (not just warning messages), please open *1* bug report that describes the actual problem and the log messages. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Bug#1041142: closed by Diederik de Haas (Re: Debian's BTS is not for regular user questions)
On 01.08.23 01:12, Debian Bug Tracking System wrote: You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile Precision M6700 ... and not once did you say what actual problem you experienced?!? That's wrong. Before I posted some (not all) of the bug reports, the Dell laptop stopped booting properly rather early; the root cause is still unknown (though an intermediate cause is finally resolved now, the bug report is already closed). It took me a bit to get a working console, a mouse and network going so as to simply be able to start debugging. Some other machines I manage had (and still have) other, less severe symptoms, e.g., Wayland and programs depending on Wayland (e.g., “foot”) failing to start after Debian upgrade. If your computer doesn't boot properly, you go one by one through every suspicious message you find. The fact that some messages are shown as warnings and others as errors is clearly meant to warn whoever reads them (i.e., the admin) and make him/her concerned. By the definition of the terms “warning” and “error”! If these messages shouldn't make the admin concerned, well, then the journalctl shouldn't show these messages as warnings (AFAIK, yellow) and errors (red according to `man journalctl`). Please don't try to unload on me because of this mess; I'm just an admin, and not even a developer. Therefore, please restore the bug reports you closed. Gratefully, Alma
