Automated firmware backup to USB is too inflexible

[Stevie-O]

The automated firmware backup logic appears to makes the following assumptions:

1. That the selected USB drive is not already mounted somewhere else
2. That the USB drive is formatted with a raw filesystem with no partition table (i.e. /dev/sda, not /dev/sda1)

This weekend, I used these scripts for the first time, and was bewildered when it didn't ask me any useful questions beyond "which drive?", but instead simply errored out immediately. Which of course it did, because the only USB stick I had already had a GalliumOS disk image written onto it, so it had /dev/sda1, /dev/sda2, and /dev/sda3. (And even if I had others, many higher-capacity USB devices have a partition table on them.)

Your comment in issue #74 makes it clear that you're worried about people inadvertently storing the backups locally on the device -- not an unreasonable concern -- but to work around this, I had to patch firmware.sh to write to /dev/sda4 (which is a partition I added and formatted with ext4 for the sole purpose of getting the backup done.) And I had to do it with vim, because that was the only editor available from crosh.

I'm still running some tests on how to best address this; I'm posting this message now so it gets out there.

[MrChromebox]

I agree the backup function could be improved. It was written to handle a single/most common use case - backing up the stock firmware from ChromeOS from a VT2 terminal onto a flash drive with a single partition. Whether or not the drive is already mounted isn't relevant, re-mounting at another mount point is harmless. I'll gladly look at any pull requests which improve the function, I just don't have the time to do so myself these days