Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extend grub boot prompt timeout on platforms with full console access #1236

Closed
dustymabe opened this issue Jun 22, 2022 · 7 comments
Closed

Comments

@dustymabe
Copy link
Member

This issue was broken out from an old coreos-assembler PR that attempted to change the grub timeout to 5 seconds.

A lot of work has happened since that PR so it's worth a reset of the landscape and fresh discussion of the issue. With coreos/coreos-assembler#2400 and coreos/fedora-coreos-config#1781 I think we should now have covered the feature request in #110 such that we can now set the timeout per platform (might require some tweaks, but theoretically possible).

The proposal here is to increase the grub console timeout on platforms where it is possible to have read/write access to a console from 1 second to something larger to improve the user experience of catching the console prompt if needed.

More context exists in coreos/coreos-assembler#1263

@bgilbert
Copy link
Contributor

If we have a tradeoff between a relatively uncommon debugging case and the boot time of every Fedora CoreOS system, I'd lean toward making debugging possible but not necessarily easy. After reading through coreos/coreos-assembler#1263, I'd like to hear more about use cases where this would concretely help. I frequently have to catch the FCOS boot menu on multiple platforms (add rd.break, remove console=ttyS0,115200) and the timeout hasn't generally been an issue. I can think of two cases where it's impractically short: bare metal machines that take 20 minutes to POST, and clouds where you can't start the console until the machine has powered on. In both cases, 5 seconds will probably not be enough.

@dustymabe
Copy link
Member Author

Let's say I'm a user and my system won't boot. It hits the grub prompt and then an error shows on screen. At a 1 second timeout it's impossible for me to read the prompt to know what key to hit. Because of my experience I know I can just hit the arrow key to stop the timeout, but it's not discoverable.

I understand not wanting to increase the boot time for the common case. Maybe bumping to 2 seconds could be a reasonable compromise?

@bgilbert
Copy link
Contributor

Actually it looks like almost any key stops the count, including Escape, Backspace, Delete, any F key, Tab, Space, Ctrl-C, and down arrow.

Also, if a user needs to fix a boot failure, hopefully they'd refer to our docs for troubleshooting steps. Those can include detailed instructions on how to get into the boot menu.

@dustymabe
Copy link
Member Author

Added the meeting label to get more input. I'm 100% fine with leaving it at 1s if no other advocates emerge.

Though, we should consider the flip side, which is: on platforms where it's impossible to get to the console, should we set the timeout to 0?

@dustymabe dustymabe added the meeting topics for meetings label Jun 22, 2022
@cgwalters
Copy link
Member

Does holding down a key work when timeout=0 too? I think there's an argument that if so, we should go to zero and not have a tiny timeout at all.

@bgilbert
Copy link
Contributor

@cgwalters I did a quick test with timeout=0 in qemu and wasn't able to interrupt the boot at all.

@jlebon
Copy link
Member

jlebon commented Jul 13, 2022

This was discussed in today's community meeting:

13:15:42 < jlebon> #info there seems to be insufficient desire for a longer timeout. we will
                   not pursue this for now but may reconsider in the future pending more
                   convincing feedback.

@jlebon jlebon closed this as not planned Won't fix, can't repro, duplicate, stale Jul 13, 2022
@jlebon jlebon removed the meeting topics for meetings label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants