Bug 1672850 - grub menu remains hidden even though boot fails
Summary: grub menu remains hidden even though boot fails
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-06 03:28 UTC by Chris Murphy
Modified: 2019-02-12 06:14 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-02-12 06:14:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
grub.cfg (5.15 KB, text/plain)
2019-02-06 03:33 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2019-02-06 03:28:51 UTC
Description of problem:


Forcing a reboot after GRUB menu, before or just as GDM appears, the subsequent boot does not show the GRUB menu.


Version-Release number of selected component (if applicable):
grub2-common-2.02-68.fc30.noarch
grub2-tools-extra-2.02-68.fc30.x86_64
grub2-tools-minimal-2.02-68.fc30.x86_64
grub2-efi-x64-2.02-68.fc30.x86_64
grub2-pc-2.02-68.fc30.x86_64
grub2-tools-2.02-68.fc30.x86_64
grub2-pc-modules-2.02-68.fc30.noarch


How reproducible:
Always


Steps to Reproduce:
1. Boot
2. Force quit right at or before GDM appears (after GRUB, during gray screen)
3. Boot again

Actual results:

System boots with grub menu hidden.

Expected results:

System should reveal the grub menu since the boot failed.

Additional info:

Reproduce in VM. Host is Fedora 29, guest is Fedora 30 Workstation netinstall, uses UEFI (edk2-ovmf).

Comment 1 Chris Murphy 2019-02-06 03:31:33 UTC
/boot/efi/EFI/fedora/grubenv after forcing quitting during startup.

  fnuc.local  chris  …  test  EFI  fedora  hexdump -C grubenv
00000000  23 20 47 52 55 42 20 45  6e 76 69 72 6f 6e 6d 65  |# GRUB Environme|
00000010  6e 74 20 42 6c 6f 63 6b  0a 73 61 76 65 64 5f 65  |nt Block.saved_e|
00000020  6e 74 72 79 3d 30 0a 6d  65 6e 75 5f 61 75 74 6f  |ntry=0.menu_auto|
00000030  5f 68 69 64 65 3d 31 0a  62 6f 6f 74 5f 73 75 63  |_hide=1.boot_suc|
00000040  63 65 73 73 3d 30 0a 6b  65 72 6e 65 6c 6f 70 74  |cess=0.kernelopt|
00000050  73 3d 72 6f 6f 74 3d 55  55 49 44 3d 65 64 64 30  |s=root=UUID=edd0|
00000060  32 62 38 30 2d 34 39 31  34 2d 34 65 39 37 2d 38  |2b80-4914-4e97-8|
00000070  66 66 66 2d 62 38 33 37  65 65 34 32 37 61 37 31  |fff-b837ee427a71|
00000080  20 72 6f 20 72 65 73 75  6d 65 3d 55 55 49 44 3d  | ro resume=UUID=|
00000090  31 31 34 65 31 31 31 62  2d 37 34 33 30 2d 34 66  |114e111b-7430-4f|
000000a0  33 39 2d 39 66 37 31 2d  64 38 36 64 61 39 34 37  |39-9f71-d86da947|
000000b0  66 33 36 64 20 72 68 67  62 20 71 75 69 65 74 20  |f36d rhgb quiet |
000000c0  0a 62 6f 6f 74 5f 69 6e  64 65 74 65 72 6d 69 6e  |.boot_indetermin|
000000d0  61 74 65 3d 30 0a 23 23  23 23 23 23 23 23 23 23  |ate=0.##########|
000000e0  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  |################|
*
00000400

Comment 2 Chris Murphy 2019-02-06 03:33:31 UTC
Created attachment 1527383 [details]
grub.cfg

Comment 3 Hans de Goede 2019-02-06 13:59:34 UTC
Thank you for the bug report.

Can you attach /etc/grub2-efi.cfg from the non-working installation please ?

Comment 4 Chris Murphy 2019-02-06 19:39:17 UTC
/etc/grub2-efi.cfg is a symlink that points to /boot/efi/EFI/fedora/grub.cfg which is what I attached already.

Comment 5 Hans de Goede 2019-02-06 20:33:33 UTC
(In reply to Chris Murphy from comment #4)
> /etc/grub2-efi.cfg is a symlink that points to /boot/efi/EFI/fedora/grub.cfg
> which is what I attached already.

Ah, sorry I thought you were attaching the grubenv, my bad.

So the grub.cfg looks fine, weird.

Comment 6 Hans de Goede 2019-02-06 21:00:01 UTC
I've installed same grub version as you have and used your grub.cfg, but I cannot reproduce this problem.

So I think there is something special about your system. What is the output of:

mount

sudo ls -l /boot/grub2/grubenv

sudo ls -l /boot/efi/EFI/fedora

ls /sys/firmware/efi/efivars/

?

Comment 7 Chris Murphy 2019-02-06 21:59:33 UTC
Last login: Wed Feb  6 14:56:23 2019 from 192.168.122.1
[chris@localhost ~]$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=990728k,nr_inodes=247682,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,freezer)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,net_cls,net_prio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuset)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/vda3 on / type ext4 (rw,relatime,seclabel)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=44,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15806)
debugfs on /sys/kernel/debug type debugfs (rw,relatime,seclabel)
mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel,pagesize=2M)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel)
/dev/vda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/42 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=201480k,mode=700,uid=42,gid=42)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=201480k,mode=700,uid=1000,gid=1000)
[chris@localhost ~]$ sudo ls -l /boot/grub2/grubenv
[sudo] password for chris: 
lrwxrwxrwx. 1 root root 25 Feb  4 14:40 /boot/grub2/grubenv -> ../efi/EFI/fedora/grubenv
[chris@localhost ~]$ sudo ls -l /boot/efi/EFI/fedora
total 6404
-rwx------. 1 root root     110 Oct  2 12:35 BOOTX64.CSV
drwx------. 2 root root    4096 Feb  4 14:40 fonts
-rwx------. 1 root root    5271 Feb  5 22:02 grub.cfg
-rwx------. 1 root root    1024 Feb  5 21:55 grubenv
-rwx------. 1 root root 1739592 Feb  4 14:40 grubx64.efi
-rwx------. 1 root root 1159560 Oct  2 12:35 mmx64.efi
-rwx------. 1 root root 1210776 Oct  2 12:35 shim.efi
-rwx------. 1 root root 1210776 Oct  2 12:35 shimx64.efi
-rwx------. 1 root root 1204496 Oct  2 12:35 shimx64-fedora.efi
[chris@localhost ~]$ sudo ls /sys/firmware/efi/efivars
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c		ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c	MTC-eb704011-1402-11d3-8e77-00a0c969723b
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c		ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c	OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c		ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c	OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c		ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c	PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0009-8be4df61-93ca-11d2-aa0d-00e098032b8c		ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c	PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c	Key0000-8be4df61-93ca-11d2-aa0d-00e098032b8c	PlatformRecovery0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c	Key0001-8be4df61-93ca-11d2-aa0d-00e098032b8c	Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c		Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c	VarErrorFlag-04b37fe8-f6ae-480b-bdd5-37d98c5e89aa
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c		LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
[chris@localhost ~]$ efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0001,0003,0002,0000,0009
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00005 	PciRoot(0x0)/Pci(0x6,0x0)/Sata(0,65535,0)N.....YM....R,Y.
Boot0002* UEFI Misc Device	PciRoot(0x0)/Pci(0x8,0x0)N.....YM....R,Y.
Boot0003* Fedora	HD(1,GPT,b4218327-0ceb-4cdd-8bf2-dd04d76fdca1,0x800,0x64000)/File(\EFI\fedora\shimx64.efi)
Boot0009* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
[chris@localhost ~]$

Comment 8 Chris Murphy 2019-02-07 00:19:07 UTC
I just did a sanity test on a newly created VM, BIOS, and default/automatic partitioning. Same problem. Instead of the gray screen with three dots on the upper left corner, I see the "charge" theme - but otherwise it's the same behavior.

Also, if I ssh into the VM during startup (within the 2 minute mark successful, without even bothering to login) and issue either 'sudo reboot -f' or 'sudo reboot' - the very next boot I do see the GRUB menu. But if I use virt-manager's "force quit" option during startup, no GRUB menu. I don't have an explanation but it seems like warm boot = grub menu, and cold boot = no grub menu.

Comment 9 Hans de Goede 2019-02-07 08:43:04 UTC
(In reply to Chris Murphy from comment #8)
> I just did a sanity test on a newly created VM, BIOS, and default/automatic
> partitioning. Same problem. Instead of the gray screen with three dots on
> the upper left corner, I see the "charge" theme - but otherwise it's the
> same behavior.
> 
> Also, if I ssh into the VM during startup (within the 2 minute mark
> successful, without even bothering to login) and issue either 'sudo reboot
> -f' or 'sudo reboot' - the very next boot I do see the GRUB menu. But if I
> use virt-manager's "force quit" option during startup, no GRUB menu. I don't
> have an explanation but it seems like warm boot = grub menu, and cold boot =
> no grub menu.

Weird. Can you try running:

sudo grub2-editenv - unset menu_auto_hide

Then you should get the menu *every* boot. If not, then I have the feeling
that virt-manager is maybe directly loading the kernel + initrd at boot
rather then going through grub.

Comment 10 Chris Murphy 2019-02-07 16:54:46 UTC
(In reply to Hans de Goede from comment #9)
> sudo grub2-editenv - unset menu_auto_hide

After this I get it every boot, whether cold boot or warm boot. However, on cold boot it appears almost instantaneously, flash and it's gone.

set menu_auto_hide=1 again -> change /etc/default/grub GRUB_TIMEOUT from the default of 5, to 7 -> grub2-mkconfig -> poweroff -> start VM. OK now I see the grub menu when starting VM following a forced poweroff, but its countdown timer the first time I see it onscreen is 1s and then the menu vanishes. I made a screencast of this and there is no frame prior to the brief 1s remaining. It should at worst say 6s. It's as if the menu is in fact drawn as far as GRUB is concerned but the VM is not displaying it - as if the software is still initializing the cold boot video :P

In the meantime, I need to up the GRUB_TIMEOUT to 10 or I have no chance of seeing and interacting with it; even when holding shift down it's only visible for a brief flash. And yet this doesn't happen with just a reboot. Weird.

Comment 11 Hans de Goede 2019-02-11 09:55:31 UTC
Hi,

Good detective work, thank you for figuring this out.

So I see 2 possible causes for this problem:

1) Grub somehow messes up the timeout on a cold boot, showing the menu for a too short time (unlikely, but possible)
2) For some reason the vm display chain somewhere has a delay updating the shown image after boot.

I think we should investigate 2. first. Are you using spice as display protocol?  Perhaps you can try to reproduce using vnc as display protocol and/or using a different model virtual GPU ?

Regards,

Hans

Comment 12 Chris Murphy 2019-02-12 06:14:02 UTC
Looks like the problem is QXL related. The problem doesn't happen if I switch to virtio video. GRUB itself is working as expected.

Filed bug 1676373.


Note You need to log in before you can comment on or make changes to this bug.