Use the same key to interrupt autoboot under legacy and EFI

[Yang Bai]

We have one change in ubuntu_quick_boot.patch, as:

+if [ "x\${timeout}" != "x-1" ]; then
+ if keystatus; then
+ if keystatus --shift; then
+ set timeout=-1
+ else
+ set timeout=0
+ fi
+ else
+ if sleep$verbose --interruptible 3 ; then
+ set timeout=0
+ fi
+ fi
+fi

This will first try keystatus command then try sleep.

On Legacy system, keystatus is implemented, so it will just detect the status of shift key.
Keystatus is using to detect the status of modify keys. This command is implemented by every term's getkeystatus function. On legacy system, getkeystatus function is implemented by bios_data_area.

On EFI system, keystatus is not implemented, so it will fallback to sleep command.
On EFI system, getkeystatus is not defined. Even we have a patch called ubuntu_sleep_shift, allow shift key to interrupt sleep. But EFI SIMPLE TEXT INPUT PROTOCOL (http://wiki.phoenix.com/wiki/index.php/EFI_SIMPLE_TEXT_INPUT_PROTOCOL) does not provide a way to test the mod key status.

So this will cause different ways to interrupt autoboot on different systems. shift key on legacy and ESC key on EFI.

Easy way to fix this issue is removing the keystatus branch. But this will cause a 3-second addition to boot time.

[Steve Langasek (vorlon)]

Yang Bai, your description of the current status is very accurate. Unfortunately, this description doesn't reveal any solutions that we haven't already thought of.

> Easy way to fix this issue is removing the keystatus branch. But this
> will cause a 3-second addition to boot time.

A 3 second delay on boot on all systems would be contrary to the guidance from Mark and the design team. We will not add an unnecessary boot delay in order to make all systems consistent with those that currently have the poorest boot experience.

The design of the current boot experience is as follows:

 - BIOS:
   - if the last boot failed, display the menu and wait indefinitely for the user to make a selection.
   - if the last boot succeeded, boot the first option immediately without delay.
   - to interrupt the boot, hold down the shift key, which grub will check instantaneously.
 - UEFI:
   - if the last boot failed, display the menu and wait indefinitely for the user to make a selection.
   - if the last boot succeeded, boot to the menu and wait 10 seconds for the user to input a selection before booting.

Is this the boot experience that you are seeing in practice? (If it isn't, that's a bug we should fix.) Assuming it is, do you have any concrete suggestions on what we should do to improve the UEFI boot experience, given that we are not going to slow down the boot for BIOS systems?

[Yang Bai (hamo)]

@Steve,

What about making the sleep waiting second an option in /etc/default/grub? and set to 1?

[Jason Yen (jasonyen)]

To delay one second is just a workaround and also may failed to fix this issue. Asking HWE team to provide the UEFI BIOS experience support to this issue.

[Joey Zheng (jzheng)]

Just an extension from comment#2, we can have this delay as an option in config file and default to be 0. So that our OEM projects can build a package to change this based on requirement.

[Steve Langasek (vorlon)]

There's a lot here that's already configurable, though I don't think it's very well documented. If an OEM wants to consistently wait for 1 second before booting, I believe it's sufficient to set GRUB_HIDDEN_TIMEOUT=1 in /etc/default/grub (or perhaps in a custom /etc/grub.d/00_before_header script). After running 'update-grub', this should give you /boot/grub/grub.cfg with a 1 second timeout everywhere:

if [ "x${timeout}" != "x-1" ]; then
  if sleep --interruptible 1 ; then
    set timeout=0
  fi
fi

Maybe this meets your requirements, without changes to the grub2 package?

[Yang Bai (hamo)]

@Steve,

What we want is getting rid of "keystatus --shift" testing and using only "sleep --interruptible" so on both legacy and UEFI platforms, we can use "ESC" to interrupt auto boot.

I have tested your solution, it really works. Thanks VERY MUCH. On both platforms, there will be only sleep testing now. I will try to fix this issue based on your idea. Thanks again.

[Colin Watson (cjwatson)]

For things like this GRUB_HIDDEN_TIMEOUT customisation, please use files of the form /etc/default/grub.d/<some name>.cfg rather than /etc/grub.d/00_before_header.

[Yang Bai (hamo)]

@Colin,

Setting GRUB_HIDDEN_TIMEOUT will add at least one second time to the boot time. Do you have any better idea to fix this issue?

[Steve Langasek (vorlon)]

On Fri, Nov 29, 2013 at 03:05:14AM -0000, Yang Bai wrote:
> Setting GRUB_HIDDEN_TIMEOUT will add at least one second time to the
> boot time. Do you have any better idea to fix this issue?

If you want consistency between UEFI and BIOS, there's no getting around the
fact that you will have to delay the boot. BIOS allows instantaneous
checking of the modifier key, UEFI does not.

[Ara Pulido (ara)]

Marking as Invalid based on comments