The dry_run was designed to "do most of things and don't really read/write firmware (flashrom)". Unfortunately we've added too many customization in history (including per-board custom scripts) so I won't be surprised if it's broken. Also we didn't find dry_run really helpful...

Feel free to fix it, but it won't be in my priority list :)

The main thing I've found it helpful for is for examining the current and packaged firmware versions. I'd be happy if it just quit after that (what can we expect it do after that anyway?).

If you're fine with that, that'd be an easy patch...

If there is behaviour we care about, please add a test for it too :-)

>  for examining the current and packaged firmware versions

-V tells you packaged versions.

And if you want to know current version, I think Duncan had a way of

 chromeos-firmwareupdate --mode=autoupdate --noupdate_main

Although I don't know if this still works :)

just checked that I think in current version at least you can do

  chromeos-firmwareupdate --mode=startup

which will give you the normal reports and then stop silently on most modern systems.

> -V tells you packaged versions.

Somewhat useful, but not quite the whole picture.

> chromeos-firmwareupdate --mode=startup

OK, that one's pretty good for me. Should it be noted in the README?

https://chromium.googlesource.com/chromiumos/platform/firmware/+/master/README.md

If no one has another good use case, I'd be just as happy to resolve this bug by removing --dry_run.

I'm ok to have --dry_run removed.

Not sure if --mode=startup should be published in README since it's simply happen to be what you want "on most devices". For example, for devices with updater 3, that may trigger EC update.

And I don't think firmware updater should provide a way to "report current firmware" - since the updater may have too many steps you should not execute when just trying to find out current fw version - that may be done by other scripts, for example the machine-info.

See