I'm using refind on a headless server (no keyboard, mouse or monitor). Refind is configured to boot into a primary OS by default. It also lets me switch to a secondary OS by either plugging in a keyboard and holding down "2" which booting or editing default_selection in refind.conf before I reboot.
The problem I'm having is if I set "timeout" in refind.conf to -1 and no keyboard is connected then refind displays the menu and waits for input - so effectively the boot process hangs.
The "workaround" I'm using is to set timeout to 1 instead, in which case refind is happy to boot with no keyboard attached.
Is this difference in behaviour intended? In practice adding a 1 second timeout to the boot time is insignificant, but I would have expected that if a default is set refind would boot without a keyboard attached in either case.
Thanks, Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The presence of a keyboard should not be affecting things in this manner, so i would venture that this is not intended.
There was a change to the code after the release of the current v0.13.2 that touched on timeout = -1 which should appear when the next release is issued. You can therefore try building the current codebase to see if it behaves differently.
Alternatively, you can try RefindPlus to see if it behaves differently, as it includes an implementation of the new timeout code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've built from the current code in sourceforge and am still getting the same behaviour - i.e. hangs if no keyboard and timeout = -1. It still works if timeout=1.
I haven't looked at RefindPlus yet.
For now I'll just stick with timeout=1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Comparing the logs with and without a keyboard it turns out WaitForInput isn't being called when a keyboard is attached, so the problem must be before that.
Digging a bit further, it seems the EFI function ReadKeyStroke is returning EFI_DEVICE_ERROR when no keyboard is attached, vs EFI_NOT_READYwhen there is a keyboard but no keypress. At least that's the behaviour on by BIOS.
The code was dealing with this status in a couple of places by setting Timeout=0. Hence the hang waiting for input.
I've submitted a merge request (#42) with the required changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm using refind on a headless server (no keyboard, mouse or monitor). Refind is configured to boot into a primary OS by default. It also lets me switch to a secondary OS by either plugging in a keyboard and holding down "2" which booting or editing default_selection in refind.conf before I reboot.
The problem I'm having is if I set "timeout" in refind.conf to -1 and no keyboard is connected then refind displays the menu and waits for input - so effectively the boot process hangs.
The "workaround" I'm using is to set timeout to 1 instead, in which case refind is happy to boot with no keyboard attached.
Is this difference in behaviour intended? In practice adding a 1 second timeout to the boot time is insignificant, but I would have expected that if a default is set refind would boot without a keyboard attached in either case.
Thanks, Stephen
The presence of a keyboard should not be affecting things in this manner, so i would venture that this is not intended.
There was a change to the code after the release of the current v0.13.2 that touched on
timeout = -1which should appear when the next release is issued. You can therefore try building the current codebase to see if it behaves differently.Alternatively, you can try RefindPlus to see if it behaves differently, as it includes an implementation of the new timeout code.
Thanks for the pointers.
I've built from the current code in sourceforge and am still getting the same behaviour - i.e. hangs if no keyboard and timeout = -1. It still works if timeout=1.
I haven't looked at RefindPlus yet.
For now I'll just stick with timeout=1.
You could activate the logging to see where the hang happens. Might help with a fix.
Sorry about the delay responding to this.
A logfile is attached. This is built from the code in sourceforge and with timeout=-1 and no keyboard initially.
After a delay of several seconds the logfile shows keyboard input - this is when I plugged a keyboard in and pressed Enter to complete the boot.
This was generated using log_level=4. If there's any other setting I should use to get more information please let me know.
It is stuck in the
WaitForInputfunction. Seems something is missing that prevents it exiting that until the keyboard is attached.I can't immediate see why that would be the case but it seems to be.
You can add a few instances of this into that function and build:
LOG(1, LOG_LINE_NORMAL, L"DEBUGPRINT '%d'", 1);
Change "1" as needed to ID the line where is get stuck.
Comparing the logs with and without a keyboard it turns out WaitForInput isn't being called when a keyboard is attached, so the problem must be before that.
Digging a bit further, it seems the EFI function ReadKeyStroke is returning EFI_DEVICE_ERROR when no keyboard is attached, vs EFI_NOT_READYwhen there is a keyboard but no keypress. At least that's the behaviour on by BIOS.
The code was dealing with this status in a couple of places by setting Timeout=0. Hence the hang waiting for input.
I've submitted a merge request (#42) with the required changes.
Makes sense.
I'll update RefindPlus.