Debian-BTS: #965026
Architecture: x86_64-linux-gnu
Kernel: Debian 4.19.146-1 (2020-09-17)
Version: 2.02+dfsg1-20+deb10u2, but the latest git revision (2df291226638261d50fadcab1f5edb6c12ab6cfd, 2020-07-31) shows exactly the same behaviour (Configured with ./configure --enable-grub-emu-sdl=yes --with-SDL --with-platform=emu and compiled against SDL 1.2.15+dfsg2-4).

Description

A blind user reported that running grub-emu made his braille and speech facilities stop and forced him to reboot.  I tried looking into this, and every time I ran grub-emu as root (which I suspect he did, too) I had to reboot my machine to make it usable again.  Running it under an unprivileged user works fine, but only because the SDL backend is using the X server or (if DISPLAY is unset) reusing the attached terminal (under X the menu is rendered in the xterm, on console it is rendered onto the virtual console, i.e. copying characters with GPM still works).

Reproducer

As root:

grub-menu

Diagnostics

For testing I added this menu stanza at the very beginning (with a 5 second timeout):

menuentry "halt" {
    halt
}

When running unprivileged and not pressing any keys, grub-emu always exitted gracefully and left the computer in a usable state regardless of how it was run.  When run as root, even with this stanza in place and not pressing any keys, the computer would always be rendered unusable until rebooted (with Ctrl+Alt+Del), even though grub-emu exitted with 0 status code.  Neither of the following recovery attempts worked:

• Alt-SysRq-K
• Alt-SysRq-R
• timed restart of the X server (hoping it would unbork the graphics setup)
• fbset with a known-to-work setting

The only diagnostically useful info I could come up with is this strace output of ioctls taken with the "halt" stanza in place:
 

13049 execve("grub-core/grub-emu", ["grub-core/grub-emu"], 0x7ffebe520b78 /* 33 vars */) = 0
13049 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
13049 ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig -icanon -echo ...}) = 0
13049 ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
13049 ioctl(1, TIOCGWINSZ, {ws_row=48, ws_col=170, ws_xpixel=0, ws_ypixel=0}) = 0
13049 ioctl(3, TUNSETIFF, 0x7fff38f678a0) = 0
13049 ioctl(6, FBIOGET_FSCREENINFO, 0x7fff38f673c0) = 0
13049 ioctl(6, FBIOGET_VSCREENINFO, 0x7fff38f67410) = 0
13049 ioctl(6, FBIOPUT_VSCREENINFO, 0x7fff38f67410) = 0
13049 ioctl(6, FBIOPUT_VSCREENINFO, 0x7fff38f67410) = -1 EINVAL (Invalid argument)
13049 ioctl(7, VT_OPENQRY, 0x199e9f0)   = 0
13049 ioctl(8, TIOCNOTTY)               = 0
13049 ioctl(7, KDGKBMODE, 0x7fff38f67344) = 0
13049 ioctl(7, KDGKBENT, 0x7fff38f67344) = 0
13049 ioctl(7, VT_GETSTATE, 0x7fff38f672da) = 0
13049 ioctl(7, VT_ACTIVATE, 0x7)        = 0
13049 ioctl(7, VT_WAITACTIVE, 0x7)      = 0
13049 ioctl(7, TCGETS, {B38400 opost isig icanon echo ...}) = 0
13049 ioctl(7, KDGKBMODE, 0x199e9fc)    = 0
13049 ioctl(7, TCGETS, {B38400 opost isig icanon echo ...}) = 0
13049 ioctl(7, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost -isig -icanon -echo ...}) = 0
13049 ioctl(7, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
13049 ioctl(7, KDSKBMODE, 0x2)          = 0
13049 ioctl(7, KDSETMODE, 0x1)          = 0
13049 ioctl(7, VT_LOCKSWITCH, 0x1)      = 0
13049 ioctl(6, FBIOGET_VSCREENINFO, 0x7fff38f67350) = 0
13049 ioctl(6, FBIOPUT_VSCREENINFO, 0x7fff38f67350) = -1 EINVAL (Invalid argument)
13049 ioctl(6, FBIOPUT_VSCREENINFO, 0x7fff38f67350) = 0
13049 ioctl(6, FBIOGET_FSCREENINFO, 0x7fff38f673f0) = 0
13049 ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
13049 ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
13049 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
13049 exit_group(0)                     = ?
13049 +++ exited with 0 +++

The only thing dubious I can spot here is the VT_LOCKSWITCH call which is missing its corresponding VT_UNLOCKSWITCH call.  I don't know if this happens in SDL or GRUB code.  Grepping for it in the GRUB codebase yielded nothing.

Let me know if I can add anything more.