Comment 26 for bug 1815002

Hi, my system is affected as well (installed ubuntu as the only system using LVM), so I would like to ask whether my understanding of the problem as follows is correct.
I would also like to know whether bug reports have been filed regarding the 5)a) and 5)b) points, or if there has been any other progress on this bug.

1) Normally, intended behavior of Grub is that if boot of an operating system is unsuccessful, the 'recordfail' variable is set, which causes Grub timeout during the next boot to be GRUB_RECORDFAIL_TIMEOUT instead of GRUB_TIMEOUT, to give the user enough time to boot the recovery environment.

2) Grub normally writes this 'recordfail' variable to the operating system partition, but since Grub lacks the ability to write to BTRFS or any LVM partition, Grub wouldn't be able to set the 'recordfail' variable in the case of unsuccessful boot. This could potentially leave the user needing to boot to recovery, but unable to do it, when GRUB_TIMEOUT is set to 0.

3) Currently implemented workaround for 2) is for the 'recordfail' variable to be set permanently, if Grub is unable to write the variable to disk. This causes Grub to ignore GRUB_TIMEOUT every time and wait for 30 seconds instead, which is the default value of GRUB_RECORDFAIL_TIMEOUT.

4) This happens by default on every EFI system where user chooses to install Ubuntu with LVM partitioning (my case) or (I'm not sure about this one) if user chooses to use BTRFS partition during the install.

5) Possible solutions would be one of the following:

  a) Ubuntu installer should create partitions in such a way that leaves a small separate partition that would be writable by Grub.

  b) Implement ability to store environment variables on the EFI System Partition (ESP) which is FAT32 and already is created by the installer. This has been mentioned in #16 and #17.

  c) Implement functionality to write to LVM, BTRFS, and other possibly affected filesystems. This is not gonna happen due to complexity and unnecessity.

6) Possible workarounds are:

  a) In /etc/default/grub set the variable GRUB_RECORDFAIL_TIMEOUT to small but non-zero amount of seconds. Setting it to zero is strongly discouraged as it could leave system unable to boot to recovery or other entries in case of boot fail, although RussinNeuroMancer describes in #14 that they're able to reliably enter Grub even if this is set to 0.

  b) Manually repartition the system in such a way that Grub's recordfail functionality works. I don't know what exactly is needed for this, though, but I would be tremendously grateful if anyone does this and shares how to do it.