New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 857188 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Aug 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

Automatically reboot device without waiting for recovery USB stick to be removed

Reported by tbrindus@chromium.org, Jun 27 2018

Issue description

Currently, after recovery is complete, a message asking the user to remove their recovery media so that their device will restart automatically is displayed on screen. We poll for the status of the media, and once it is removed, we reboot.

For features like https://crbug.com/793878, it would be optimal if the device rebooted automatically under certain circumstances (in that feature, the presence of /mnt/stateful_partition/oobe_auto_config).

We can have a set of circumstances that will trigger an automatic reboot, and if they are fulfilled, display a message to the user that recovery is complete and that their device will automatically reboot in X seconds.
 
Cc: rspangler@chromium.org vapier@chromium.org
Randal, Can you take a look at this and let us know if this makes sense?

The english sentence would be something like:
"Your computer will restart automatically in 10 seconds."

I think a number like 10 should be enough, right?

Comment 2 by vapier@chromium.org, Jun 28 2018

we already have a flag for this ...

# Return the path to the node under /sys/block associated with
# the USB stick.  The existence of that path is used to test whether
# the user has removed the stick and we can reboot.
#
# For certain non-interactive test cases, the stateful partition on
# the USB stick may be flagged to request that we bypass the
# interactive removal of the USB stick.  If we detect that
# condition, we signal it by returning an empty string instead
# of a path.
get_usb_node_dir() {
  local usb_node_dir="/sys/block/$(strip_partition "${REAL_USB_DEV##*/}")"
  if [ "$INTERACTIVE_COMPLETE" = false ]; then   
    usb_node_dir=""
  elif mount -n -o sync,rw "${REAL_USB_DEV%[0-9]*}1" /tmp; then
    if [ -f /tmp/non_interactive ]; then
      usb_node_dir=""
    fi
    umount /tmp
  fi
  echo "$usb_node_dir"
}
That'd be a nicer solution for determining if we should reboot automatically, thanks. In that case, would there be a problem with having the new message be displayed in the current non-interactive case, so that users have an indication that they no longer need to remove the USB?

Comment 4 by vapier@chromium.org, Jun 28 2018

showing a message should be fine
Project Member

Comment 5 by bugdroid1@chromium.org, Jul 2

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/initramfs/+/fb3f927e46830ce93f6fab3bae83070b56c01431

commit fb3f927e46830ce93f6fab3bae83070b56c01431
Author: Tudor Brindus <tbrindus@google.com>
Date: Mon Jul 02 22:32:45 2018

recovery: Add user message and progress bar for noninteractive reboot

This commit adds a UI message when non_interactive exists on the
stateful partition of the recovery media, before it reboots
automatically.

BUG= chromium:857188 
TEST=no errors during recovery both with and without non_interactive;
   correct messages displayed

Change-Id: Ib8969c28197c9f8eb24474ae9e675df930b40f75
Reviewed-on: https://chromium-review.googlesource.com/1117640
Commit-Ready: Tudor Brindus <tbrindus@chromium.org>
Tested-by: Tudor Brindus <tbrindus@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/fb3f927e46830ce93f6fab3bae83070b56c01431/recovery/defaults.sh
[modify] https://crrev.com/fb3f927e46830ce93f6fab3bae83070b56c01431/recovery/messages.sh
[modify] https://crrev.com/fb3f927e46830ce93f6fab3bae83070b56c01431/recovery/recovery_init.sh
[modify] https://crrev.com/fb3f927e46830ce93f6fab3bae83070b56c01431/recovery/localized_text/cros_recovery.grd

Status: Assigned (was: Untriaged)
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
Status: Fixed (was: Assigned)

Sign in to add a comment