Comment 20 for bug 1815002

On Thu, Mar 07, 2019 at 05:04:51PM -0000, Felipe Castillo wrote:

> Any news on this issue? The suggested workaround, which is to modify the
> timeout is not even a workaround. It will indeed shorten the boot time,
> but in case of any errors or interruption to booting, I won't be able to
> see the GRUB menu on next boot.

> This is such a regression, for years (as many people mentioned here) I was
> able to boot without delay, and if there were errors, I did see the GRUB
> menu.

The only way this could be true is if your grub root is configured on a
filesystem that grub knows how to write to; and to the best of our knowledge
this is not supported on top of LVM, as described in /etc/grub.d/00_header.
To test whether this is the case, you can do the following from the grub
prompt:

set var_test=value
save_env var_test

You should get an error message:

error: diskfilter writes are not supported

If you find a system where the above command succeeds, but you are seeing
the 30 second boot delay, then that is a bug and we should fix it.

But if the above save_env command fails, then there is no possible way that
you saw the GRUB menu on error on that system with that filesystem
configuration, because there is no possible way for GRUB to detect that
there was an error.

RussianNeuroMancer's argument is different; he argues that using Esc to
access the GRUB menu during UEFI boot DOES work reliably and therefore we
should default to booting fast. So far, I am unable to confirm that it's
reliable; but at best, it would be dependent on the user detecting flickers
of the screen to know when the right moment is to press Esc, which is still
bad UX, especially for the case in which there was actually an error on the
previous boot and the user struggles to figure out how to get to the menu.

The right solution is for us to make sure we always have writable space
where we can store grubenv between boots, so that we don't have to choose
between two suboptimal user experiences.