Comment 3 for bug 1815002

> As discussed in bug #1814403, this is by design.

Disagree. Mathieu mentioned in Comment #31 of bug #1814403:

> When your system doesn't boot correctly through the kernel however, it would likely not show the menu without this fix -- you'd have no way to switch back to a working kernel, because the menu can be hard to reach at all in these setups.

This is not the case for UEFI and / on btrfs (including /boot) as I can't remember any issues with accessing GRUB menu for eight years (since Ubuntu started supporting installation on btrfs). So, if my understanding is correct, quick-boot-lvm.patch fix nothing for this combination while introducing unnecessary timeout on systems that should not have needed quick-boot-lvm.patch workaround.

Mathieu mentioned in Comment #31 of bug #1814403:

> If you still feel your system is showing the menu and timeout at every boot unnecessarily, or if you feel the default timeout is too long, please file a separate bug with the information specific to your system and particular case so we can look into it -- the particularities of the system will be important to include in such a bug report.

Which is what I just did. A bunch of tablets, 2-in-1, embedded boards, etc. load at least two times longer now with no way to skip menu due to lack of keyboard - such behaviour is hardly necessary or expected, as there was no issues with accessing GRUB2 menu before, if keyboard is connected.

So, please reconsider your resolution on this bug, due to two points:

1. Switch back to previous kernels works before for UEFI and / on btrfs, without quick-boot-lvm.patch

2. Tablets, 2-in-1, embedded boards with UEFI and / on btrfs now stuck for 30 seconds on every boot with no way to skip menu.