On Fri, Jul 12, 2024 at 01:21:41PM -0400, Neal Gompa wrote:
> On Fri, Jul 12, 2024 at 1:12 PM Zbigniew Jędrzejewski-Szmek
> <zbyszek@xxxxxxxxx> wrote:
> >
> > On Fri, Jul 12, 2024 at 05:53:25PM +0100, Aoife Moloney wrote:
> > > In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the
> > > kernel
> >
> > The idea for DRM_PANIC is nice, but I worry about the impact of disabling
> > VT_CONSOLE. Plymouth is not used everywhere, e.g. what about cloud images
> > and such? Also, when debugging boot troubles, removing 'rhbg' and 'quiet'
> > are the often first steps.
> >
> > I cannot actually recall the last time when I had a kernel crash
> > on any of my machines… It seems like we might be sacrificing debugability
> > for a feature which would be used very rarely.
> >
>
> Do we lose the serial console as part of this? Or is there a serial
> console "thing" somewhere still?
I think the serial console is not affected. The kernel Kconfig says:
config VT_CONSOLE
bool "Support for console on virtual terminal" if EXPERT
depends on VT
default y
help
The system console is the device which receives all kernel messages
and warnings and which allows logins in single user mode. If you
answer Y here, a virtual terminal (the device used to interact with
a physical terminal) can be used as system console. This is the most
common mode of operations, so you should say Y here unless you want
the kernel messages be output only to a serial port (in which case
you should say Y to "Console on serial port", below).
If you do say Y here, by default the currently visible virtual
terminal (/dev/tty0) will be used as system console. You can change
that with a kernel command line option such as "console=tty3" which
would use the third virtual terminal as system console. (Try "man
bootparam" or see the documentation of your boot loader (lilo or
loadlin) about how to pass options to the kernel at boot time.)
If unsure, say Y.
Zbyszek
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
