Glenn Washburn writes:
Robbie Harwood 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.
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 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).
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.
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.
Regards,
Michael
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
