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

Issue 897806 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Linux Chrome OS Recovery tool (linux_recovery.sh) has bad UX with WORKDIR handling

Project Member Reported by lee...@google.com, Oct 22

Issue description

I was recovering a Chromebook over the week using the official Linux recovery tool here: https://dl.google.com/dl/edgedl/chromeos/recovery/linux_recovery.sh just on my Ubuntu desktop.

I ran the tool and downloaded the image for my device, turns out my main disk ran out of space during the download and the script told me to try setting WORKDIR 

"Please free up some space on that filesystem, or specify a temporary directory
on the commandline like so: WORKDIR=/path/to/some/dir"

I have an SSD so I just set the WORKDIR to that (seemed like an ok thing to do for some temporary stuff):
# WORKDIR=/media/lee/ssd1 linux_recovery.sh

I downloaded the image and flashed the usb drive. At the end of the process it asked me if I wanted to delete the temporary files:

"Shall I remove the temporary files now? [y/n] "

I just assumed it would remove the recovery image it just downloaded (seems reasonable I think). But instead it erased my entire SSD.

The script does this:
prompt "Shall I remove the temporary files now? [y/n] "
read tmp
case $tmp in
  [Yy]*)
    cd
    \rm -rf ${WORKDIR}
    ;;
esac

So it ran 'rm -rf /media/lee/ssd1' and deleted all my stuff.

Luckily there wasn't too much on that drive except a few android checkouts, but I did lose a few things I would of preferred not to have. I didn't notice to the next day though, so took me a while to work out why my disk was blank!

Anyhow this script seems a little dangerous to me and its definitely not obvious that it will erase everything in WORKDIR and it could of been quite bad. Maybe it should create a temp directory in WORKDIR first and then remove that folder, leaving WORKDIR as is (which is how I assumed it would likely work)
 
Cc: keta...@chromium.org stephenlin@chromium.org bhthompson@chromium.org josa...@chromium.org gkihumba@chromium.org
Owner: josa...@chromium.org
going by //depot/google3/googledata/download/chromeos/OWNERS which is where this script lives
Summary: Linux Chrome OS Recovery tool (linux_recovery.sh) has bad UX with WORKDIR handling (was: Chrome OS Recovery tool erased my desktop's entire hard drive)
Cc: ahass...@chromium.org
Status: Assigned (was: Unconfirmed)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

Sign in to add a comment