The CL defines this function in remote_access.sh:

# Discover partition numbers from the target.
learn_partition_layout() {
  source <(remote_sh_raw cat /usr/sbin/write_gpt.sh)
  load_base_vars
}

Does that not work for your target? I'm finding it difficult to understand how that's possible

$ cat /usr/sbin/write_gpt.sh | grep PARTITION_NUM

shows nothing.

I'm updating a pretty old image. If that's the only problem, then this is less important. But is it possible we can retain compatibility? Or at least add some error-checking, so it's more obvious the update isn't working.

(Yes, I know 'cat ... | grep ...' is one 'cat' too many.)

I see where the PARTITION_NUM stuff got into write_gpt.sh:

https://chromium-review.googlesource.com/439508

So yes, I guess I need a relatively new image.

I'll rely on your judgement for how important this is, or if we should just close it.
I'm happy to cook up some kind of fix if necessary.

Well, I think at a minimum it would be nice to improve the script so it knows when it's flashing to nowhere. That would have saved me some considerable trouble over the subtle problems of an updated set of modules, with no updated kernel partition. (And no errors; it's perfectly fine to create a new '/dev/mmcblk0p' file.)

Full backward compatibility might be overkill.

Notably, this is still marked 'Available'. I might tackle this myself later in the week if I get time. (Thanks for the pointers so far.)

we should error out when we can't detect the partition, but i don't think we want to add backwards compat code.  ToT is largely meant to be used with ToT-ish systems.

Apparently 'dd ... conv=nocreat' isn't POSIX. Oh well. I've added some error checking here, which we'd want anyway:

https://chromium-review.googlesource.com/537140

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/crosutils/+/9774b0db8b8d69b9bbc36d150a9c6fb1d723999f

commit 9774b0db8b8d69b9bbc36d150a9c6fb1d723999f
Author: Brian Norris <briannorris@chromium.org>
Date: Sat Jun 17 08:12:42 2017

update_kernel: error out if kernel partition isn't found

The kernel partition might not be found for a number of reasons:

 * the '--partition=' argument might be incorrect
 * the DUT might not be compatible with us (e.g., it's using an old
   image, with differences in /usr/sbin/write_gpt.sh)

Currently, rather than noticing this and bailing out, we're happy to
use 'dd' to create a new file instead. That can create unintuitive
behaviors, where the DUT's kernel modules have been updated while the
kernel partition is left unmodified.

Let's detect this situation and error out, instead of leaving the user
to figure out what happened.

BUG= chromium:733028 
TEST=update_kernel on old images (without $PARTITION_NUM... variables)
     and new ones

Change-Id: I47f64ec7fb1175e0e25697a6b55b63366fcc4555
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/537140
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/9774b0db8b8d69b9bbc36d150a9c6fb1d723999f/update_kernel.sh

Didn't "fix" backward compatibility, but at least the script will error out and make this more obvious now.