You absolutely can change /etc/grub.d/00_header to change or remove the code. The problem is; I don't think there is a way around us providing a way to reach the menu for the those setups where "recordfail", the feature that lets the boot menu start on failure, doesn't work, while also making it not show every boot.
In other words, your setup works right now, but waits thirty seconds to boot -- that timeout can be adjusted by setting GRUB_RECORDFAIL_TIMEOUT=<some value> in /etc/default/grub. Reducing the timeout value is probably the best solution in all cases, but I do think the default of 30 seconds is reasonable. You get enough time to see the menu and respond, etc. And it doesn't hold up the boot very long in the grand scheme of things. 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 bug was meant to address an issue that caused unnecessary timeouts on systems that should not have needed this workaround, due to some unforeseen limitations in GRUB. We believe it's been addressed appropriately. 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1814403 Title: Latest update causes 30 sec. menu delay timeout To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1814403/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
