On Sat, 16 Oct 2021 19:48:45 +0200 Michael Schierl <schie...@gmx.de> wrote:
> Glenn Washburn <developm...@efficientek.com> writes: > > Robbie Harwood <rharw...@redhat.com> wrote: > > > > They turn on debug=all because they don't know in what conditional(s) > > would give them useful debug information. This will spew a lot of debug > > messages to the screen, including the messages output by this patch. > > BTDT. > > > message by conditional, allows the user to iteratively pare down debug > > log messages so that the ones of value have a greater likelihood of > > being on the limited screen realestate. This would look like, for > > example: > > > > set debug=all,-gdb,-disk,-lexer,-alloc > > I would second that. Great, I'm not the only one. I'll see about submitting that patch sooner than later then. > > Now the patch as is does not show the file:line prefix, and wouldn't > > show the conditional after my patch. So the user has no way of knowing > > what conditional should be used to disable the gdb output. > > In fact, is there even a sensible scenario where having these messages > included when debug=all is set? I generally use debug=all to get some > first idea about which driver/device may be causing the boot failure, > and module load addresses will never help with that. > > Maybe do not trigger this message on debug=all, or use a completely > different environment variable? I can't say I'm a fan of another special variable, but I'd also be fine with that route. Another route might be a (proc) file, eg. "/gsyms", which outputs add-symbol-file lines for all loaded modules. This could be put in its own module, eg. gdb-syms, which would address the increasing the core image size concern below. > > I am also unaware how exactly to debug grub in gdb on various platforms, > do you need special build flags for it? If yes, this functionality could > be limited to that build flags. Especially since if I did not miss > anything, this patch only provides value for efi platform (in an obscure > edge case, from my point of view), yet increases core image size for all > platforms. > > > On the otherhand, since you're able to copy paste, I'm guessing you're > > on a serial line or VM and not on in the situation I'm describing. In > > which case, without the proposed "\n" modification, having the file:line > > prefix is an extremely minor inconvenience (you'll have to find the > > start of the add-symbol-file, which won't be at the beginning of the > > line). And you can copy-paste, you likely can search that output > > anyway. > > I presume that typical GRUB loads will load dozens of modules, resulting > in dozens of debug outputs, which may often end up on adjacent lines. In > case of a line prefix, you would need to use sed (or some block editor > features) to get rid of the prefixes. In case of a newline after the > debug message, one would need to use grep (or remove every second line > from the output). If I understand this correctly, you're thinking I'm talking about *appending* a new line to the debug message. I'm talking about *prepending*. So we're on the same page, the entire message is formatted currently as "file:line:<debug message>". I'm not sure I understand the last sentence, the debug message as proposed in the patch is already a multi-line message. > > Why do I care? I've been that guy trying to figure out a boot issue > > with too much noise in the debug log messages pushing the messages I > > needed to see off the screen (and the source wasn't readily available). > > And no pager is not always an option if you have hundreds of pages of > > log messages to scroll through, it takes forever. > > As I have been in the same situation before, too, I second that. I would > also like a feature so that debug messages (or all output) get spewn > into a file (overwriting existing bytes similar to how grub_env works, > acting like a ring buffer on the file). So you could boot some recovery > envionment to create a sufficiently large file, set debug=all, let debug > logs write into that file, and then analyze them after another reboot > into said environment. Or when GRUB is booted from a USB key, the file > can be created/analyzed on another machine. Interesting idea. Also, I had thought of having an in memory ring-buffer for playing back debug log on a live grub. > > This may not help if nothing boots on that machine, but in my experience > there is either some non-Linux operating system already installed on > that machine that fails to boot Linux from GRUB, or at least a recovery > environment from another OS can be booted. > > > I don't think we need to agree (that is for you to agree that the issue > > I'm describing is something to be concerned about). However, like I > > said, I think we can both be satisfied by not leaving out the file:line > > and to prepend "\n" to "add-symbol-file" so that it will start on a new > > line. So I'll ask again. Is my proposal an acceptable modification for > > the need that you have? > > Another way (if possible, I don't know GRUB internals enough) would be > to provide a module similar to lsmod that shows this output for all > loaded modules. Users could load it if they want to use gdb and invoke > it during their debug session. Then copy&paste the output in one single > block. That's another idea, a "get-gdb-symbol-file" command. Glenn _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
