New issue
Advanced search Search tips

Issue 756022 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

shouldn't "cros flash" obey the .default_board file?

Project Member Reported by semenzato@chromium.org, Aug 16 2017

Issue description

I accidentally passed the wrong IP address to cros flash, and it reflashed someone else's kevin with an old kevin image that I had sitting around in my chroot.  I was trying to reflash my caroline, and my .default_board contained "caroline".  Having a .default_board file should be equivalent to having a --board=<board> option, and cros flash should have errored out instead of reflashing the kevin.

This may be the most practical approach in any case since IP addresses can change and this check would catch most mistakes (we work with enough different boards that the likelihood of hitting the same board type is low).  Conversely, I cannot think of situations in which the current behavior would be critically helpful.
 

Comment 1 by vapier@chromium.org, Aug 16 2017

imo, cros flash is doing the correct thing here.  from the help text:
  --board BOARD         The board to use. By default it is automatically
                        detected. You can override the detected board with
                        this option.

what you're suggesting is that if people have .default_board set and they try to flash a diff board, they'll always have to specify --board to match the remote system.  i don't think that's an improvement.

note that cros flash already respects the default board setting, but only when the target is a USB stick as it makes sense in that scenario -- the USB stick has no sense of a board, so the default is what the user has configured.
Well I thought that the point of having the .default_board file was to spare one from typing --board BOARD every time, therefore I thought that .default_board is equivalent to using that flag (unless overridden by explicit invocation of the flag).

Isn't it the case that for all other tools, if .default_board exists, one has to specify --board if they want something different?  I understand that there is extra information in this case, and one can argue that it's convenient to use it, but I am not seeing that being argued.


Comment 3 by vapier@chromium.org, Aug 16 2017

i get what you're saying, but i think it's more intuitive to have the tools use the correct --board value when it can be calculated (like any tool dealing with a remote device or image) vs the fallback value the dev has set

think of it as a three level system:
(1) if the user specifies --board, use that
(2) if the target of the command declares itself in a way we can discover (e.g. parse /etc/lsb-release), use that
(3) use the .default_board setting if available
FWIW: I'll officially note that I have no opinion here.  I have always refused to use .default_board because it causes me to make too many mistakes as I switch from board to board...  :-/

Status: WontFix (was: Untriaged)
Yes I get what you're saying too, but I would prefer "simpler" to "intuitive" because this intuition is based on knowledge.  Step 2 in the three-level system requires too much knowledge to know if it applies or not.

But maybe not many people use .default_board so this doesn't matter.

Sign in to add a comment